In many forms of creative work, bigger requirements equate to more complex requirements. More complex requirements equates to greater risk. Greater risk equates with more cost, more waste, or both. In creative work (like information technology work), bigger requirements means risk and waste. Or in other words, bigger is DEFINITELY not better.

In Scrum, we form our requirements in terms of product backlog items (PBIs). Since many folks write PBIs in the form of user stories, the term “user stories” is often used in a way that is synonymous with “product backlog item.” PBIs (or user stories, if you prefer) are not limited in size. They can be really small (e.g., correct a spelling error) or really big (e.g., allow a customer to create a new account). Big user stories are frequently called “epics.”

While Scrum doesn’t discuss the appropriate size of a PBI, the concept of “ backlog grooming” (also often called “ backlog refinement”) has existed for a very long time. Some of you might remember when backlog grooming was actually called “Pre-Sprint Analysis” (pre-2005). Whatever it is you remember, the most common activity performed in backlog grooming is the decomposition (slicing) of large PBIs into small PBIs (note: there are many other useful activities that can be performed during grooming, including estimation and analysis, but we’ll keep our focus on decomposition for now).

Backlog Grooming is often looked at as a way to ensure that the Scrum team can successfully plan a Sprint by ensuring that all high priority PBIs were already small enough to fit into the Sprint.

At Artisan, we suggest that “small enough to fit in the Sprint” is still too big. At a size greater than four days, a PBI is more than likely to result in one or more defects that will surface after the PBI is considered complete. Even if the defects are identified immediately, large PBIs often result in Scrum teams opening defect reports instead of, correctly, simply calling the PBI not done and returning it to the Product Backlog during Sprint Review. In other words, larger items threaten quality. Fundamentally, bigger means more complex. More complex means more possibility for error.

We recommend that you reduce your PBIs to a size that will allow it to be completely finished (DONE) within a period of three days, no more. At three days, the likelihood of a defect drops significantly (though still a possibility). This means that your team will have to get some experience at decomposing PBIs into very small version of themselves. It’s not always easy, but the benefits derived from working on smaller PBIs is well worth it.



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

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.

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!