What's the Right Amount of Backlog Refinement?
Many teams struggle with getting the right level of detail in their backlog. If the backlog is too vaguely defined, then the team picks up stories that aren’t immediately actionable which can slow them down. On the other hand, if the backlog is too well defined then it becomes rigid and fails to evolve as the product takes shape. It can even stifle the creativity of the team as they try to find the best option for achieving each outcome.
So, how do you strike the right balance when creating your own backlog? In his excellent book Scrum Product Ownership, Bob Galen introduced the 20/30/50 Rule for product backlog refinement to address this very problem.
Here’s how it works...
The First 20 Percent
20% of the stories on the backlog should be well refined and ready to be picked up at any time. These are the stories that are immediately actionable that your team can begin work on with little hesitation. You and your team will need to agree on exactly what makes a story actionable for them, but here are a few options to consider as a starting point....
Each story has a stated objective and corresponding business justification. While this is often expressed in the popular format “As a…., I want…., So that…” format, the specific format isn’t important as long as the team knows what they’re trying to accomplish and why they’re trying to do so.
Each story has defined acceptance criteria to give the team a clear and unambiguous picture of what the end state of the story should look like.
Each story meets the agreed to Definition of Ready established by your team. If your team has yet to establish their own, then the INVEST criteria is a good place to start to consider which qualities of stories are important to your team which may not be as important.
The Next 30 Percent
The next 30% of the stories on the backlog aren’t ready to be picked up by your team, but are in a good enough state that you as the Product Owner can have a discussion about these stories with your team and stakeholders to decide when these stories should be worked on...if ever. Expect these stories to contain no more than an objective and business justification and to be sized larger than the first 20%. In fact, it’s not uncommon for many of these stories to simply exist as unrefined epics. The goal for stories in this bucket are to pin a specific idea to the backlog so that it’s not lost as well as to facilitate a discussion around when it would make sense for the team to invest in tackling that story. If the story is not specific then this discussion will meander and won’t be productive, but, if the story has already been too well defined then the creativity that would otherwise emerge from that discussion will be stifled.
The Final 50 Percent
The final 50% of stories are the least refined of them all. These stories tend to be largest stories on the backlog and exist only as vague ideas of things the team would like to consider for the future. If the previous set of stories tend to be at the Epic level, then these items are the Themes of your backlog. These stories are not ready for a team to work on and really aren’t even ready for a team to discuss. Instead, these stories exist as placeholders for the Product Owner to periodically evaluate whether they still make sense for the direction of the product and, if they do, to begin to introduce them to the discussion.
Finding What Works
Structuring your backlog according to these rules of thumb will help you strike the balance between items that your team can be productive with immediately and items that still deserve more refinement.Depending on your team and your product, you may find that you need to tweak the percentages to optimize the backlog for what works best in your organization. You may also find that you need to experiment with whether these numbers correspond to the total remaining story points in your product backlog or to simply the total number of remaining product backlog items. As with most opportunities in agile, experimentation will be the key to finding what works the best for your team.However you decide to implement it, the 20/30/50 rule gives you a nice guideline of how much of your backlog should be ready at any time while keeping the risk of over refinement at bay.