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 refinement.

In part one of this post, I set the stage for what backlog refinement was by referencing the Scrum Guide. Then we explored 5 of 12 overall refinement tips. I’ll continue with the remaining seven tips here:

12 Tips for Effective Backlog Refinement

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[2]. 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[3], 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 [4]as central to your execution of Scrum.

1. Sprint Planning
2. Daily Scrum
3. Sprint Demo
4. Sprint Retrospective
5. 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.