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

Note that the term "Backlog Grooming" has been changed to "Backlog Refinement" in the 2013 Scrum Guide. The text below has not yet been updated to reflect that, so please remember this while reading.


Who likes long meetings? As a Scrum Coach, I ask this question of teams new to Scrum. I ask it mostly in jest, but also as an inoculation against people who will inevitably complain about lengthy Scrum meetings when first implementing Scrum. Obviously I turn it around on them. "I hate long meetings too, why do you think we have such long meetings? What could we do better?" Sprint Planning and Sprint Retrospective meetings can drag on and on and on unless they’re executed well. In addition, the ROI or value of these meetings can be horrible if they are not well structured. In this article, I attempt to make the case that Product Backlog Refinement can greatly enhance the value of your Sprint Planning Meetings, as well as keep them short and sweet.

Some of the best Scrum advice I've ever seen/given

One of the best ways I’ve found to greatly increase the value of Sprint Planning Meetings is to do Weekly Team Product Backlog Refinement. Because backlog refinement is not mentioned a lot in the Scrum Guide, and frankly not mentioned a lot anywhere else, teams have to come up with their own way of doing it. Below is my opinion based on my experiences coaching Scrum teams.

The biggest reasons to do Product Backlog Refinement are:
  • Increases efficiency of the team by greatly reducing uncertainty and unknowns.
    • Better refined stories are more accurately estimated, more accurately tested, and more accurately implemented
    • Delays related to external dependencies and larger efforts (architecture, analysis) are discovered sooner -- thus allowing for the proper runway time without delaying the Scrum Team.
  • Increases efficiency of the team due to the benefit of shared knowledge gained by the entire Scrum team being in the refinement.
  • Allows the team to maintain a sustainable, higher pace.
  • When done well, refinement greatly reduces the time required for a Sprint Planning meeting.
    • There are already a lot of Scrum ceremonies(Review, Retrospective, etc) around the time of a Sprint Planning meeting, so team members greatly appreciate having a shorter Sprint Planning meeting.

Be sure and see what the Scrum Guide says about Product Backlog refinement

Some Assumptions of this article

  • There are several kinds of Product Backlog refinement, but in this article, I will focus almost exclusively on Weekly Team Product Backlog Refinement, except as otherwise noted.
  • I use Scrum terminology and a 2 week Sprint cycle in this article, but you can translate these concepts to other software approaches and iteration lengths.
  • I will use the more generic Product Backlog Item(PBI) term here, except where I make special mention of User Stories. Pretty much everything in this article also applies to User Stories.
  • Synonyms for Product Backlog Refinement: backlog grooming, sprint preview meeting, user story grooming, detailing user stories, user story conversations, etc
  • Any time I mention "backlog", "backlog item" or "item" in this article, I'm referring to the Product Backlog and *not* referring to the Sprint Backlog.

What is Product Backlog Refinement?

In my experience, there are essentially three kinds of product backlog refinement.
  • Stakeholder Product Backlog Refinement
    • The Product Owner(PO) collaborates and converses with stakeholders to refine requirements for backlog items(usually focusing on ones that will be implemented soon, just in time) and to adjust backlog order according to business value.
      • How far the Product Owner gets into detail is team, product, and stakeholder dependent.
      • Often times a PO will bring along a development team member or two to assist.
        • The development team member can provide insight into already existing system logic, as well as relative effort of backlog items, though she should refrain from making estimating comments for backlog items that have not already been estimated by the entire development team.
  • Informal Product Backlog Refinement
    • The Product Owner will work with zero or more dev team members or stakeholders to refine stories and their order in the backlog. Said another way, this is a lighter more informal way to refine the items in much the same way the refinement is done in the Weekly Team Backlog Refinement. This kind of informal refinement should be a daily, if not hourly, occurrence for the Product Owner.
      • When the PO gets together with development team members (early collaborators), she should strongly consider making sure that the three amigos are there.
        • Also feel free to bring stakeholders in to discuss.
      • Development team members should feel free to discuss relative sizes with the PO, but I encourage teams to wait to record any estimate until the entire team has estimated the item first. Said another way, the early collaborators should try to avoid skewing or anchoring the entire Dev Team's estimates.

  • Weekly Team Product Backlog Refinement
    • The Product Owner holds a roughly weekly standing meeting to refine backlog items.
      • Generally speaking, about 90% of this meeting is usually spent refining the items for the next sprint.

The focus of this article is on Weekly Team Product Backlog Refinement, though I will often just refer to it as "backlog refinement".

What does Weekly Product Backlog Refinement look like?

The weekly backlog refinement meeting is run just like the first part of any normal Sprint Planning Meeting. The Product Owner presents the backlog items, the team asks questions, and the team estimates them. Sometimes the items need to be split and re-estimated and that's perfectly ok and even encouraged.

One important note here is that a backlog item is always open for re-estimation until it is accepted into a particular sprint. As such, if some information changes about a backlog item between the backlog refinement and the Sprint Planning Meeting, the team is allowed to re-estimate if they so desire. The same goes for the PO re-ordering backlog items between the weekly backlog refinement and the Sprint Planning Meeting. I’ve found this to happen in only about 5% of the cases, so it’s not a big risk. Besides, you’d rather these changes happen a few days *before* the next sprint than a few minutes *into* the next sprint!

For more info on what Product Backlog Refinement looks like, see What does Product Backlog Grooming Look Like?


  • More time before the sprint actually starts to:
    • let the new backlog items "sink in" before final estimating and implementation.
    • optimize design, test, etc (i.e. team members pondering the issues in their spare moments for a few days before the sprint begins).
    • explore and resolve external dependencies
    • research/study up on
      • any technology hurdles.
      • any estimate risks like legacy code or code that hasn't been touched in a while
      • requirement hurdles like requirement holes, ambiguous requirements, validating acceptance tests, etc.
  • The refinement forces the Product Owner to be well prepared for the next sprint and helps prevent a "Product Owner Bottleneck," which is a worst practice.
    • The PO can then re-order items, queue up new items instead, etc


  • If the Product Owner discovers something in presenting new stories that inclines them to reorder the backlog, the team might feel like time was wasted or feel stressed due to the change. While we like front loading risk and knowing these things sooner rather than later, the team may feel a bit frustrated at times. However, that same frustration grows exponentially the longer the change is delayed, so this is definitely a desired disadvantage. It's a good idea to remind the team that the pain now is smaller than it would be if we found out about it later.
  • It can be hard, at first, for some team members to "switch gears" at a time when they're rockin and rolling on sprint N, to start thinking about sprint N+1.
    • It can take a while to get used to this type of cycle, but all of the teams I worked with liked it much better than a Sprint Planning Meeting that dragged on and on or didn’t provide enough value to the team.

Where do I go from here?


Related Articles