In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition[1]. In both books I took on the topic of Backlog Grooming.

As it turns out the term “grooming” is losing its luster in the community and terms like maintenance and refinement are replacing it. I believe the latest copy of the Scrum Guide uses the term refinement. So I will try to start using Backlog Refinement consistently throughout this article. That being said, I really, really like the implications of the term grooming.

Backlogs & Refinement

Why don’t we first start with a definition of Product Backlog. From the July 2013 Scrum Guide[2], I’ve captured the following:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. 


A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists. 


The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value.

And because this article is about Backlog Refinement, let’s see what the Scrum Guide has to say about it as well:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

Now that we’ve explored what a Product Backlog and Refinement is, by process definition, let me share some of my experiences around effective refinement.

12 Tips for Effective Backlog Refinement

1. Regularly Scheduled Refinement Meetings – I’m a big fan of creating a tempo of regularly scheduled Backlog Refinement meetings within your teams. I usually schedule 1-2 of them a week for an hour each. The entire team is invited and expected to attend. I want everyone to come to the meeting “backlog aware”, that is, they’ve looked at likely refinement candidates before the meeting AND they have thoughts surrounding (size, ordering, design, dependencies, strategy, quality, risks, and optimal flow).

I also recommend that a team member take detailed notes that capture the valuable discussions and next-step decisions that are made. This is invaluable information and you don’t want to lose it. I normally ask members to round-robin note keeping, which helps to keep everyone engaged in the meeting, and in the backlog.

2. Rigorous Prioritization – You must truly reinforce the notion of order or priority in your backlogs. I think of the Highlander movies and the phrase – “There can be only One” in this regard, so please don’t overload priorities.

From my perspective there are a variety of factors that should influence priority:

• Customer value (right problem solved)
• Business value (revenue generated)
• Technical value (fosters learning, reduces risk, solid solutions, intelligent workflow)
• Quality value (mitigated risk or improves quality)

And I look for the team to consider and balance against all of these variables when setting priority. For example, it should never be the case that customer value always drives prioritization without consideration of technically sound solutions.

3. Examine Your Stories Frequently – I often encounter teams who only refine their stories once. In that context they write them, refine the wording, write acceptance tests, estimate them, and order them – all at the same time. I could see doing that for trivial or straightforward stories, but never for complex ones.

I much prefer an approach where the team “samples” the stories over several refinement meetings. Taking the story from concept or idea (Epic) and methodically breaking it down into refined and executable stories. I sometimes recommend to teams that—a “good story” should be refined a minimum of 3-4 times during its evolutionary lifetime. And this includes sufficient space in between refinement discussions so that the team has time to think about the story in relation to all of their other work and the project and product goals.

4. Egg Timer – I usually recommend that teams stay aware of their story refinement velocity, that is, how many stories do they discuss in a 1-hour meeting. I often see velocities of 1-2-3 stories, which to me implies over –discussion. I prefer the team have a goal of “advancing” stories in their refinement meetings and not necessarily complete them in one sitting.

The real point of a backlog refinement meeting is not to complete stories as quickly as possible, but to advance the understanding and clarity around the stories. As long as the team makes progress, and keeps chipping away at the stories, I’m happy with their progress. You might ask, what is a fair or rough velocity goal? I’m not sure there’s a magic number, but refining a story every 5-6 minutes might be a reasonable goal—so perhaps 10-12 per 1-hour meeting.

5. The Estimates are NOT the most important thing – We’re in the middle of a refinement meeting and leveraging Planning Poker as a means of collaborative estimation. In one case, 2 developers have been debating whether the story is 5 or 8 points in size for the last 30 minutes. Eventually, the Scrum Master has to move on and the team still hasn’t agreed on the estimate. In another case, the testers on the team think a story is 13 points, but the developers strongly disagree. And the story ends up being estimated at 3 points. After this happens a few times, the testers disengage in the estimation and simply acquiesce to the developers on all estimates.

In both cases, the estimates (numbers) have been the focus point of the team. I strongly would argue that the estimates are much less valuable than the DISCUSSION that the process of Planning Poker estimate enables.

Who cares if it’s a 5 vs. an 8? At the end of the day, pick a reasonable, relative value and move on. BUT, have rich, deep, collaborative discussions across the team about the story. Hear everyone’s experience. Hear their concerns. Listen to what’s said and unsaid. And as a team, come to a fair and balanced relative estimate for “all the work” to move the story to meet your Definition of Done. That’s the value that the estimates drive.

Wrapping Up

I hope I’ve established some baseline thinking on your part regarding the practice of Backlog Refinement. From my perspective, it’s much more than simply developing agile requirement lists. It’s also the planning and strategy part of agile execution and it makes all the difference in how well your sprints are delivered.

In the next post, I’ll finish delivering tips 6-12 and wrap-up this topic. I hope you “tune in” for the remaining tips, until then…

Stay agile my friends,

Bob.