This post was originally published on Mountain Goat Software by Mike Cohn, an experienced Certified Scrum Trainer (CST), author of three popular books, an Agile practitioner and consultant. Mike is also a founder of Mountain Goat Software, an Agile and Scrum training company.
Why is this topic extremely important?
At any given time, an agile product backlog will contain a prioritized list of desired features, each sized differently and written at varying levels of detail. Because the product backlog is prioritized, the smaller, high priority items reside at the top of the list, while the larger, less urgent items fall toward the bottom.
At the top of the product backlog iceberg are the high-priority features the team will implement relatively soon. These items should be small and should contain sufficient detail that each can be programmed, tested, and integrated within a single sprint. As we look further down the product backlog iceberg (and therefore further into the future), items on the backlog become increasingly larger and less detailed as we approach the waterline. Teams and product owners often have only a vague idea of what lurks beneath there; some of those are features are only known in enough detail that each can be estimated approximately and prioritized.
Having an iceberg-shaped product backlog should be a goal for any agile team. If you structure your backlog to have small, ready-to-develop items near the top and larger items with less clarity below you’ll find your team spending less time overall in product backlog refinement. And the time they do spend will be invested in the items considered most important by the product owner.
Why Create a Product Backlog That Evolves Over Time?
It makes some people uncomfortable to have items near the waterline or beneath the surface that aren’t well understood. They’re used to starting a new project by identifying “all” of the requirements. However, those who are well versed in agile know that, because every project has some emergent requirements, you can never define all of the requirements upfront.
A much more agile approach to requirements is to create an iceberg-shaped product backlog that is progressively refined over time. Here’s why:
- Over the course of a project, priorities will shift. Some features that were initially thought to be important will become less so as the system is shown to potential users and customers. Other needs will be discovered and have to be properly prioritized. If we acknowledge that change is inevitable, the advantages of structuring your product backlog like an iceberg become more apparent.
- Software development is the same way. My headlights don’t illuminate everything between me and the horizon because they don’t need to. They light the way far enough for me to see and respond at the speeds my car can safely travel. The iceberg-shaped product backlog works similarly. Enough visibility is provided into upcoming items that teams see far enough into the future to avoid most issues. The faster a team goes, the further ahead in the product backlog it will need to peer.
- Nearly all projects are time-constrained. We want more than will fit in the time allotted. Treating all requirements as equivalent is wasteful. With a limited supply of one of a project’s most critical resources (time), we need to be protective of it. If the team thinks an item further down the product backlog may have an impact on items above it, the team can put some effort into understanding it. This often results in the item being split into multiple, smaller product backlog items.
What happens when a team refines its Backlog?
First, through conversations with the product owner, teams ensure that the items toward the top of the backlog iceberg are well understood, small enough, and sufficiently detailed to be brought into an upcoming sprint.
The team might choose one or two of these items to split into smaller, slightly more detailed stories. The stories that result from this split are likely to still be relatively low in priority, so they don’t need to be sprint-ready, but they do need to contain enough detail that they can be estimated more accurately and perhaps prioritized. A good Scrum team does not need a perfect understanding of a feature before it starts working on it. Rather, at the start of the sprint, the team needs to know they have a reasonably strong chance of finishing each feature during the sprint.
Second, the team and product owner might want to look at some of the lower priority items that have come nearer to the top but are still several sprints out. These items might need to be split, rewritten, or even discarded based on what the team has learned in previous sprints.
Lastly, the team might choose one or two of these items to split into smaller, slightly more detailed stories. The stories that result from this split are likely to still be relatively low in priority, so they don’t need to be sprint-ready, but they do need to contain enough detail that they can be estimated more accurately and perhaps prioritized.
Tell us about your experience, what’s your product backlog look like? Share your thoughts about this topic. 😊
