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.

Don’t Miss Your Opportunity!

Don’t miss your opportunity to become the user story maestro your team needs—register for our “Amazing Stories! 1” today! Amazing Stories 1 is your essential guide to writing effective user stories. This is your golden ticket to mastering the art of writing compelling user stories that drive your Agile projects to unparalleled success!