For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.

Executive Summary

In a previous article, I discuss the answer to the question of Why do Product Backlog Refinement?. In this article, I discuss what Product Backlog refinement looks like. The primary benefits of backlog refinement are increased productivity and increased understanding/quality. Backlog refinement can be a little difficult at first when getting started, but the benefits are large and they appear very quickly, usually after just a couple of Sprints of doing it. In my next article I discuss Tips for Effective Backlog Refinement.

Goals of Weekly Backlog Refinement

  • Come out with at least a few backlog items that are well refined
    • I define "well refined" as:
      • getting to an estimate that the dev team is moderately comfortable with.
      • getting to a deep enough understanding of the backlog item so that the dev team could accept it into a sprint with a moment's notice.
        • Do not over-discuss or over-design.
      • splitting the PBI's where the team feels appropriate -- aim for items that are 2-5 person days based on whatever sizing units you use. See User Story Pattern - Micro Stories
    • If this is the last weekly refinement session before the next Sprint, then the goal is to have enough high priority items finely refined to fill about two sprints.
      • The extra is to account for
        • any last minute changes to the backlog (deferring items, removing items, estimate size changes, etc) as well as to have some "on deck" work in case the team needs more work later in the Sprint.
        • discovering unknowns that will need some time before they can be resolved (requirement questions, technology questions, legacy code, external dependencies, etc)
    • Get 90+% of details/acceptance tests(aka story tests) discussed, understood, and lightly documented where necessary,preferably as hand written notes on cards,whiteboards (take a picture), or stickies.

Having met your backlog refinement goals with flying colors, the only thing really remaining to do in the Sprint Planning Meeting is to task out each of the product backlog items and decide which items will be accepted into the sprint. You can also refine any late breaking PBI's.

To learn how to maximize your Backlog Refinement practices, see more info about our Agile Requirements and User Stories Class.

Who takes the lead in Product Backlog Refinement?

In short, mostly the Product Owner(PO). While the PO makes decisions about acceptance tests, logic details, and priority of the items, this does not mean it is solely up to the PO to refine the backlog and record details. Who takes on the legwork of the refinement is completely up to the Scrum Team. Said another way, the PO does have the responsibility to make sure the backlog items are refined, but this doesn't mean that they have to take on all of the legwork of doing so. Many PO's do most of the legwork, but this is not a requirement, and will depend on your team situation. Ideally speaking, the "refinement" is a mostly verbal conversation, with only a few important notes or acceptance tests jotted down for each backlog item.

My rule of thumb is the Product Owner will spend roughly:
  • 1/3 of their time working with stakeholders to create and refine backlog items for the upcoming few sprints.
  • 1/3 of their time leading refinement activities with the development team for items that are in future sprints (focusing ~90% of this time on the *next* sprint).
  • 1/3 of their time working with the development team on backlog items that are being implemented during the current sprint.

How Often and How Long are these meetings?

The Scrum Guide time-box for refinement is 10% of the Sprint (so 1 day for a 2 week Sprint, 2 days for a 4 week Sprint, etc), but most teams I know of generally only spend about 1-2 hours a week once they get used to the practice. If they're just starting out, significantly more time might be needed. Judge how much time your team needs this way: Did your team, in the previous sprint, come out of backlog refinement with enough fine grained PBI's to fill about 2 Sprints worth? If not, then allocate more time next Sprint, but also inspect and adapt about getting more efficient at backlog refinement.

Typical Activities at a Weekly Backlog Refinement meeting

  • Discussing PBI's
    • Creating PBI's in the meeting is ok, but should be extremely rare. We want the PO to show up with at least a first draft with at least a couple of high level acceptance tests for each new item.
  • Splitting PBI's
  • Flushing out and firming up detailed Acceptance Tests for PBI's
  • Estimating PBI's
  • Looking further down the road(just a little down the road...just enough, just in time) from the following perspectives:
    • Identifying/Discussing any needed 'Spike' PBI's
      • We like to identify these sooner rather than later because you generally want to do your 'Spike' PBI one or more Sprints before your "Follow On" PBI.
      • Some of these may involve investigating new technologies that are architecturally risky
    • Identifying/Discussing external dependencies
      • We like to identify these sooner rather than later because they make take multiple Sprints to resolve
      • If the external dependency creates enough estimate uncertainty, you can also create 'Spike' PBI's to get the external dependency resolved in an earlier sprint before the "Follow On" PBI in a later sprint.

To learn how to maximize your Backlog Refinement practices, see more info about our Agile Requirements and User Stories Class.

Where do I go next?

To learn more about product backlog refinement, see Tips for Effective Backlog Refinement.

Related articles on ScrumCrazy

Related articles on the web

Scrum Alliance Blog Post: How to Hold an Effective Backlog Refinement Session