As previously discussed, Backlog Refinement is a workshop held to take large backlog items and slice them down into smaller pieces. More specifically, we discussed the three major goals of Backlog Refinement:
- Estimate backlog items that have no estimate
- Correct estimates that appear to be considerably off target
- Discuss backlog items and divide them into smaller component pieces (slicing).
In this blog post, I want to discuss how we know how small to make our backlog items before we stop refining them and move on to something else. If the backlog item is too large at the beginning of the Sprint, we run the risk of problems during Sprint Planning and during the Sprint. On the other hand, if we slice the item too small, we’re wasting time discussing something that can be easily dealt with in Sprint Planning.
Many experts currently agree that the “right” size for a backlog item is one that 2 or 3 people on your team can complete in less than a week (this concept, getting people working on one backlog item collaboratively is called “swarming”). This maximizes the Scrum team’s flexibility (small backlog items are easier to “fit” into a Sprint should some re-planning be necessary during a Sprint) while still allowing the team to do “functional” slicing during Backlog Refinement (as opposed to solving the backlog item).
So, what’s small enough that 2 or 3 people on your team can finish an item is less than a week? That will have to be up to your team. Every team is different; the best thing to do for a new team is let them make their best guess and then look at how it worked out at Sprint Retrospective (then, you can look at the Sprint Burndown and see how long each backlog item took to complete from the first day to the last). If the backlog items are taking too long, slice them down further. Eventually, the team will get an idea of the proper size based on the story point size they are putting on the backlog items (for example, 5 point items may seem too big – then the team knows to slice to sizes of 1, 2, or 3 story points).
In Backlog Refinement, once a backlog item is refined down to the “ready” range, stop. Don’t refine it further. Any remaining discussion can wait until Sprint Planning. Do not solve or slice the backlog item into tasks. Move on to another backlog item.
In the next installment, we’ll talk about how many backlog items you need to slice before you should stop holding Backlog Refinement meetings during the current Sprint.
More About #Backlogs
What Do You Do With Incomplete Work at the End of the Sprint? #AskArtisan
One of the questions I get asked a lot has to do with when a Sprint ends… what happens with all the work that isn’t finished at the end of the Sprint?
What is Scrum?
The most popular Agile Development framework, Scrum, can be explained in many ways. If you're just trying to understand what Scrum is, this post is for you.
Gearing a Team for Maximum Outcomes
Creating a maximum outcome team is every ScrumMaster’s goal, but you must first understand how great teams form and what YOU need to do to create a great team.
Boosting Work-From-Home Productivity
It's hard to stay productive when working from home, but we've got some tips that will make a real difference in your lives. Share them with your teammates!
It’s All About Value
One small change can make a BIG difference to your Product Owner success. Before worrying about putting value on backlog items, here's some simple tips.
Simplify Your Work by Slicing
When slicing a backlog item, we're taking a complex problem and paring it down into smaller problems, which are easier to solve and build.
Speeding up Your Scrum Teams
Effective Scrum use is more than Sprint Planning, Daily Scrums, and so on. To see a big difference in your team's Sprints, make these workflow changes.
Don’t Waste Time in Sprint “Capacity” Planning
Trying to plan detailed capacity for a Sprint? Thankfully, there are two things we can do to make capacity planning easier (and faster) in Sprint Planning.
DONEness Definitions (DoD)
What's the one thing YOU could do as a Scrum Master to improve your team's reliability, quality, and productivity? Read on and find out!
Leave A Comment