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.
6. Talk Less, Spike More – I’ve noticed a very common anti-pattern in many refinement sessions that teams explore each story far too deeply. They wax into conjecture and guessing about design challenges. They debate implementation approaches. They argue estimates on stories that are still quite immature and ill defined. In a word, they talk too much about the stories.
I’d much rather they define a spike, do some research, write some code, talk to a customer, and do whatever it takes to replace “talking” with “real learning and knowledge”. And I don’t think this happens in a roomful of people. It happens individually and more effectively in pairs looking at real prototypes and code.
I have a personal heuristic that up to 20% of the stories in a typical Product Backlog deserve to be spiked. What I more commonly see from most teams is 1-2% of their stories getting spiked. I think most software projects have more complexity than that, which is exactly what a user story - research spike is intended to mitigate.
7. Remember, Refinement is Planning Too! - Backlog refinement goes far beyond requirements definition. It’s also part design, part planning, part strategy, and part risk mitigation within your sprints. This is one of the reasons I prefer that teams sample their stories multiple times and leave a little time between refinement sessions. It allows for “think time” across the team, which leads to better stories, better execution, and more consistent delivery of value.
Another important point is to look beyond the individual stories when you’re refining your backlogs. Instead, ask your Product Owner about features and themes (collections) of stories that they want delivered together or that are related. Here you should be looking at dependencies and risks. But also look for efficiency in implementation. For example, coupling a set of four stories together in priority so that you can do some related refactoring and improve the service API that all four will leverage.
8. Reserve 10% of the Teams Time – Too many teams make the mistake of reserving too little time for backlog refinement. I remember early on in my Scrum journey hearing Ken Schwaber talk about “reserving” 10% of the teams’ time for refinement. You see mention of that in the latest Scrum Guide (above) as well.
That would be 4 hours, per team member, per week. He made the point that it’s that important and the team needs the time to do it well. Fast-forward to today, and most teams might allocate a 1-hour meeting per week to refinement and cancel that if the sprint is running into challenges. Teams need to make a serious commitment to their refinement activity. And remember, it’s not just in meetings. I believe each team member should take some personal time each week to work on improving the backlog. That might be improving the acceptance criteria in a story, or asking targeted questions, or suggesting a story be spiked, by who and for how long, or writing a technical story to clean up some technical debt.
The point is refinement should be a continuous activity by all team members and not something relegated mostly to meetings or to the Product Owner.
9. Never Cancel Refinement, in fact, Do More! – As I alluded to in the last suggestion, it often seems like teams find excuses to defer or cancel backlog refinement whenever possible. But what I’ve found is that this is the last thing you should do if you’re challenged in your sprints. Refinement goes way beyond requirements definition. It’s also part design, part work planning and tasking, part strategy, and part risk mitigation within your sprints. Point being, if you’re struggling, don’t stop planning your work. It will only lead to deeper struggles and missed commitments.
Let me add another heuristic here. If you find your sprint planning meetings going on and on, then you’ve probably been under refining. Conversely, if you are performing sufficient backlog refinement within your team, your sprint planning meetings should be effective, focused, and quite short.
10. Develop & Apply Readiness Criteria – From my perspective, there are very few things worse for an agile team to do than to take an under-cooked story (under refined) into a sprint. Inevitably that story “blows up” into more than the team expected in size, scope, complexity, dependencies, or something else and it causes the sprint to fail.
Beyond the disappointment to the Product Owner and business impact, it causes the team to lose confidence and feel bad. Not only that, the work typically falls to the next sprint to complete, so there is a cascading effect.
I wrote about a method for avoiding this called Readiness Criteria here[3]. I’d strongly recommend you apply this technique. Consider it story exit criteria from your backlog refinement sessions.
11. 3 Levels of Lens OR Change Your Focus – With a new team or project, your backlog refinement clearly needs to focus on the work that you will be tackling in the immediate future (next sprint). But as you continue to sprint and continue to refine, you should be getting ahead in your backlog. When this happens, I like to change the focus a bit in the refinement meetings. I have a 3-lens metaphor for this, in that you should be refining:
- Stories that are “right around the corner” – 1-2 sprints in the future
- Epics, Features, or Stories that are targeted for the next release target
- Epics, Features, or Themes that are targeted for future releases
To keep the refinement meetings interesting, we’ll examine stories through these various lenses—sometimes shifting the view in the same refinement meeting. One advantage is it forces the Product Owner and team to “connect the dots” between the now and the future, both from a functional and architectural perspective. It also motivates the team because they get glimpses of their future work.
12. Anchor Your Sprints with Themes – One of the problems with backlog refinement is that it usually deals with finely grained units of work—call them stories. The refinement then focuses solely on each story. While this is certainly important, I’ve found two problems with many teams handling of this:
- The focus too much on the story and little to no time on the “collections” of stories, the themes, and the workflow from sprint to sprint
- They break the stories down too far, further than they really need to. Sometimes they even break them into tasks, which should be deferred to sprint planning.
In this related article[4], I refer to the notion of creating an anchor story for each sprint. This story would be large and complex, but it would be sized to fit the sprint—in other words, it would be an “executable” story. This story would more heavily influence the sprints theme or goal and other stories would build around and support it.
If you take this anchored view to your backlog, then finding these stories and building content around them would be an aspect of your refinement thinking.
Wrapping Up
There are five-core scrum activities defined in the Agile Atlas [5]as central to your execution of Scrum.
- Sprint Planning
- Daily Scrum
- Sprint Demo
- Sprint Retrospective
- Backlog Refinement
All of them are important and have specific values they add to your agile execution and results as a team. I think of Backlog Refinement as being the “planning” focused ceremony. Not just planning for the sprint, but planning across a multitude of factors that a team needs to keep their “eyes on” to successfully deploy customer solutions. A huge part of it relates to what I call look-ahead.
I hope this article has helped to widen your thinking about Backlog Refinement—the what and the how of it. But at the end of the day, these are simply my thoughts and experiences. Bring yours to bear in your contexts and see what approaches will work for you.
Stay agile my friends,
Bob.
[1] Scrum Product Ownership, 2’nd Edition - http://www.amazon.com/Scrum-Product-Ownership-Balancing-Inside/dp/0988502623/
[2] https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf#zoom=100
[3] http://www.batimes.com/robert-galen/user-stories-ready-set-go.html
[4] http://www.batimes.com/robert-galen/anchoring-your-product-backlogs.html
[5] http://agileatlas.org/atlas/scrum#development
and many thanks to Shirley Ronan for the picture I used for this post - http://tracks.roojoom.com/u/shirly-ronen-harel,60/agile-product-po-backlog-grooming,353