Note: This is PART TWO of a six-part series on Backlog Refinement.

<< Go Back to Part 1
Skip Ahead to Part 3 >>

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:

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.

Continue to part three of this blog post!

Note: This is PART TWO of a six-part series on Backlog Refinement.

<< Go Back to Part 1
Skip Ahead to Part 3 >>

FEATURED RESOURCE:

FEATURED RESOURCE:

Backlog Refinement Reference

Download Now!

Swipe this FREE DOWNLOAD to supercharge your PBI refinement.

Normally available ONLY to Artisan students, we’re offering this handy guide to you for a limited time!

More About #Backlogs

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.

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.

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!

Keep Your Eyes on the Sprint Goal

In this article, we'll discuss how a team bares responsibility for the Sprint and what should be done if they can’t get everything done they committed to.

Plan Only Small Backlog Items

Bigger requirements are more complex, which typically have greater risk, which leads to more cost and/or waste. In other words, bigger is DEFINITELY not better!