Scrum in practice: Managing the product backlog

The backlog refinement meeting isn’t mentioned in the official Scrum Guide — the guide recognises the activity of refinement but does not specify exactly how this should be achieved — but it is so frequently a fixture of a Scrum team’s schedule that many sources refer to it as part of the canon.

The backlog refinement meeting

The purpose of the backlog refinement meeting is to decompose the highest priority items in the product backlog into user stories which are suitable for inclusion in the next sprint.

The backlog refinement meeting (or backlog management meeting, or backlog grooming session) usually takes place towards the end of the current sprint. Attendance varies but certainly includes the product owner and the meeting is often facilitated by the Scrum master. What’s important is that representation of what is feasible, valuable and a good user experience is present. It is time boxed, usually to no more than two hours for a two week sprint.

The benefits of having a separate backlog management meeting are threefold: it reduces the need for a long sprint planning meeting which can be hard to schedule (especially in large organisations where team members have other commitments outside of Scrum) and which can tax even the longest of attention spans. It also gives the team a chance to reflect on the backlog items discussed in the meeting before committing to the sprint backlog and sprint goal. And it offers greater flexibility to look a little further ahead.

Refining the backlog

A product backlog might include several types of items:

• User stories

• EPICS — larger features that need to be broken down into user stories

• Bugs

• Spikes — tasks which don’t directly generate value like research

The process of backlog refinement takes the items at top of the ordered product backlog and decomposes them into ‘good’ user stories. See my previous post for a reminder of what makes a good user story. Essentially they should be small enough to fit comfortably in the sprint and represent a vertical slice through a feature (i.e. they should deliver value).

Large bugs or clusters of bugs might also be broken down into constituent elements.

During the backlog management meeting, the team looks at each item in turn and discusses whether it’s feasible to include in the next sprint or if it needs further decomposition. (See the same post for advice on how to split large user stories into smaller ones.)

This process continues until there are at least enough stories to populate the next sprint backlog. Often the group will also discuss the sequencing of stories and alternative options for achieving an outcome.

To estimate or not to estimate?

The Scrum Guide doesn’t explicitly state that you should estimate the relative sizes of stories but most organisations find it useful for tracking the velocity of Scrum teams (and using these average values to plan ahead).

But should estimation take place in the backlog refinement meeting, in sprint planning, or in an entirely separate meeting dedicated solely to estimation?

In my view, it often depends upon the maturity of the team, the amount of change in the backlog and what the data is needed for. Some teams now focus on writing stories that are of similar size, removing the need to estimate.

Dedicated estimation sessions provide focus but also eat into development time. When it comes to deciding between the two remaining options — estimating in the backlog refinement meeting or in sprint planning — it comes down to personal taste. Estimating in the refinement meeting leaves the team free in sprint planning to focus on how the work will get done. (This approach does require full attendance so that the team owns the estimates.)

On the other hand, estimating in sprint planning keeps the team keenly aware of how much work they’re taking on and reduces the risk that they’ll over or under commit.

Whichever approach is taken it’s important that everyone accepts that estimates are exactly that: the best guess of the relative size of a piece of work.

And it’s also important to remember not to get locked into patterns and processes — use the sprint retrospective to regularly review how well your backlog works for you and be prepared to change things up.