Backlog Refinement is the work of refining, estimating, and ordering items in the product backlog. As a product manager, I used to spend about a quarter of my time working on my backlog. The Scrum Guide suggests that the development team also spend up to 10% of their capacity supporting backlog refinement. This usually happens in regularly scheduled events such as backlog refinement and sprint planning, but also occurs ad hoc such as in a parking lot discussion after the daily Scrum.

Although Backlog Refinement isn’t an official event in the Scrum Guide, I’ve never met a Scrum Master or coach who didn’t advocate strongly for teams making it one.

The biggest reason for this is to reduce risk: if your team can’t clarify an item’s requirements during Sprint Planning, it won’t be ready to pull into the sprint and will likely have to wait for the next one. If the product owner attempts to force it into the sprint anyway, the team’s sprint forecast won’t be very accurate. However, if you hold a backlog refinement event a few days in advance of sprint planning and the team discovers an issue, you’ll have time before the sprint starts to do more research. Besides, every hour your team spends in Backlog Refinement is at least an hour your team won’t spend in Sprint Planning.

Before you start, I suggest having the product owner communicate a proposed list of items for refinement to the team, at least a few hours before the event. This gives the team a chance to look at the stories earlier. If the product owner and Scrum Master are willing to conclude the event when all of these items have been refined—rather than move on to new topics—it can also be highly motivating for the team.

To begin, Gather the whole team and and start discussing your highest-ranked backlog item. Remember the phrase “card, conversation, confirmation?” The card is the index card, sticky note, or JIRA entry that acts as the token for our discussion. Our discussion is the conversation. The updates we make to the card—especially the acceptance criteria—lead to the confirmation. What’s in scope? Out of scope? Dependencies? Target ship date?

Keep talking about and updating each backlog item until it meets your team’s Definition of Ready, then estimate. If you’re using Planning Poker to estimate items, do so immediately following the discussion so that it’s still fresh in your mind. If you’re using Affinity Estimating, you can place the item in its correct relative location immediately after discussing it, or wait until you’ve discussed everything to sort them. Once the user story is ready and estimated, mark it as ready. I like to prefix the item’s title with an asterisk to indicate that it’s ready – this works great when you’ve got several pro-forma sprints lined up following a release planning session. If you don’t do release planning, you can simply create a psuedo-sprint called “Ready” and place items in that sprint.

Schedule your Backlog Refinement events as your team sees fit. I generally suggest one shorter Backlog Refinement per week, lasting about an hour for mature teams and products. Some teams like one longer session per sprint. If your sprint planning events seem to take forever, you probably need to spend more time doing refinement. This especially common for new teams or products.