Backlog Grooming is a regular meeting of the team, including Product Owner, Engineers, QA, and BA, to review the backlog. The purpose is to ensure that the backlog – the team’s source of work in upcoming sprints – is healthy.
At this meeting the team will do some or all of the following:
- Write new stories
- Remove old stories that are no longer valid
- Add acceptance criteria to stories
- Update stories to reflect new learnings
- Split out big stories into smaller ones that are easier to estimate and deliver
- Estimate stories
- Update estimates to reflect new learnings
- Re-order stories to reflect changes in priority
The tasks performed will vary depending on the state of the backlog.
How big should the backlog be?
One of the biggest challenges that teams face is keeping the backlog full enough that it’s ready to supply the next sprint, but small enough that things that go into it can also get into production quickly – in 1 or 2 sprints, or at most 3. A backlog that has 5 or more sprints worth of work in it is becoming a parking lot – either things are just sitting there and not moving, or everything is taking a long time to get done. A “healthy” backlog:
- Has enough work in it for about 2 sprints
- Only has enough work in it for about 2 sprints (3 at the outside)
- Has enough ready stories for at least 1 sprint
- Only has things in it that we’re going to work on fairly soon
If there are too many stories in the backlog, it may be time to reboot – move all of the stories to the Icebox, and then move the most important stories back in until you have 2 sprints worth.
When is a story “ready”?
- Have a clear description that includes the outcome, the recipient and the reason why the story is needed
- Have acceptance criteria so we know when we’re done
- Have an estimate so we know how big it is
- Has no external dependencies (ideally – we’re always going to have some things with dependencies, but we should strive to avoid them)
Ideally, stories represent a single feature – one thing, rather than multiple things – that can be delivered in a few days. Keeping stories small helps us move faster, and provides us with more feedback more quickly.
The basic algorithm
- Do we have enough stories? If not, we need to add some.
- Are our stories in rough priority order? If not, we should sort the important stuff to the top.
- Are the stories at the top of the backlog “ready”? If not, then add description, acceptance criteria and estimates to get them ready.
- As we’re updating stories, if they’re really big, break them up into smaller pieces.
- Check each of the stories in the backlog, starting at the top – are they still valid? Do they need to be updated?
- If the backlog is more than ~3 sprints long, move things out to some other list.
Adjust this to suit your team’s needs.