A common question we get from Scrum course participants: “How long should backlog refinement take?”
The latest Scrum Guide says this about backlog refinement: “Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.”
Earlier versions used to say how much time refinement might take. From the 2017 Scrum Guide: “The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.”
Not sure why that guidance went away. Maybe it felt like too much time. Maybe too little. Maybe it was just a move away from any concrete advice.
In any case, we’ve found 5% to be a reasonable rule of thumb. But how is that time structured?
First off, that 5% is in reference to the developer role on a Scrum team, which is to say, all the team members who aren’t the Product Owner or ScrumMaster. The Product Owner spends way more than 5% of their time on backlog refinement—it’s a core part of the job. For a developer, though, 95% of their time should be focused on the current sprint. About 5% should be look-ahead efforts like supporting backlog refinement. For a 2-week sprint, that means about 4 hours per sprint. Build this into your sprint commitment—don’t overcommit.
That 5% is an average across the team. Some team members will spend 8 hours on refinement in a sprint. Others may only spend 1. Like so many things on a self-organizing team, it’s about who can contribute and what fits in with the rest of the team’s commitments.
Backlog refinement shouldn’t be concentrated in one, all-team meeting. Most of it can be done incrementally, in smaller conversations. Coordinate those conversations in the Daily Scrum. The PO might say something like: “I have this new item coming up the backlog. Here’s what it’s about. I think it’s too big and could use some help breaking it down. Who can spend a half hour helping me with that today?” And then the team plans that into their day.
The only thing that really requires the whole team is sizing backlog items. And this can be done incrementally, too, an item or two each day as they’re ready. (By the way, if this sounds impossible, you may have too many backlog items.) Check out our PO Board episode for advice on how to structure your backlog for sustainable, calm refinement.
And while you’re doing backlog refinement, don’t forget that some of that look-ahead time should be from a technical perspective. Don’t build infrastructure you don’t need yet, but do keep an eye on where your product is going and how to incrementally keep your solution high-quality as it grows.
Learn More
Learn how to structure your backlog to have the right detail at the right time and deliver value every day with 80/20 Product Backlog Refinement, a self-guided course from Humanizing Work designed for Product Owners, Managers, and anyone steering the direction of a product.
I originally suggested including “Masterclass” in our new 80/20 Product Backlog Refinement course, and we chose not to because we’ve seen how the term has been overused in marketing—often exaggerating or overhyping what’s offered. But this course really is just that. It’s the masterclass for backlog refinement.
Peter Green
Humanizing Work Co-Founder, Trainer, and Coach
Additional Product Management Training
Last updated