I’ve been creating a product backlog for a new initiative recently and the exercise got me thinking about how you assess how good it is. After all, a product backlog isn’t a static set of requirements in the traditional sense. No, a product backlog is more of a dynamic “stream” of requirements originating from business needs and flowing through the Product Owner to the Developers who ultimately deliver completed work.
Since the product backlog is a key component of making the switch to Scrum successful, we ought to be able to assess what exactly constitutes a healthy product backlog. This article identifies four factors for consideration:
Factor 1: Are there enough backlog items to support the next sprint planning meeting?
This is easily determined by taking the velocity, which is the average number of story points completed in previous sprints, and comparing it against the points of Sprint Ready items. It will be quite apparent if there’s enough work or not ready for the next Sprint Planning meeting. Consider this example:
If the Developers’ velocity is less than 30, then the Product Owner needn’t worry because enough backlog items are Sprint Ready and available for selection during the next Sprint Planning meeting. If the velocity is 35, the team will need to select backlog items that haven’t yet been reviewed and could spend much more time in the Sprint Planning meeting working through the details. This isn’t a terrible situation but it may require the Product Owner to scramble and answer questions before the sprint work actually starts.
Ideally there should be two sprints worth of backlog items in the Sprint Ready stage. Assuming a velocity of 25, then having 50 points worth of items would create a nice buffer in the event the Developers want to select additional work for the sprint.
Factor 2: Are the individual backlog items actively maintained?
The product backlog is a repository for all sorts of product ideas. Some ideas will represent small enhancements and others will describe large scale efforts. The Product Owner must continually maintain, or “groom”, backlog items with the goal of making them as refined as possible so they can be selected into a sprint.
When a product backlog is first created, the ratio of general to refined backlog items will be high:
The Product Owner will need to spend significant time decomposing those general ideas into properly formatted backlog items. As items are previewed by the Developers during Story Time meetings and feedback is given, the items will be refined further still and become Sprint Ready. At this stage the Developers can select them into a sprint and be confident they know enough about the requirements to complete the work.
Factor 3: Are the individual backlog items ordered according to business priority?
When adding items into the product backlog, it’s good practice to place any new backlog item in the approximate position that represents their business priority. This is true even if the newest entry is only a placeholder.
Once backlog items are refined enough, their placement in the order needs to be more certain. Now, the good news is that the entire product backlog doesn’t have to be perfectly ordered but as the items get closer to the top, they should be so they are ready for the next Sprint Planning meeting. In this example the green backlog items are considered Sprint Ready and have been purposely ordered by the Product Owner.
You may have noticed there are two items with a “3” label. That’s because sometimes there’s just no easy way to decide which one is more important than the other but as long as they’re together and placed relative to all the other items that works just fine. At the next Sprint Planning meeting it may become obvious which is the best for third place but before then there’s little point in solving this puzzle.
The orange colored items aren’t in the final order but are close enough while the Product Owner continues to work on refining them and making them ready for the Developers to review.
Factor 4: Is the minimum marketable feature set clearly defined?
A product backlog will grow over time with the addition of new backlog items but not all are necessary for a specific release. Assuming the product backlog is ordered according to business priority, the Product Owner should designate which items are part of the minimum marketable feature set or MMF for short.
The MMF can include any type of backlog item from those that are Sprint Ready to the most vaguely written but what’s important is that the set is clearly defined. While this designation seems arbitrary, it serves to inform others about what will be included in the release and helps keep the Product Owner focused on what the Developers should be working on in order to finish the release. There will be constant temptation to add enhancements to the release but each one can expand the scope and that may push the release date out.
The MMF serves as a test where the Product Owner asks themselves the question: “Is adding this backlog item worth pushing the release date out?” If the answer isn’t yes, the latest item should be left out of the MMF and included in the next release.
Summary of the factors for a healthy product backlog:
- There are enough backlog items to support the next sprint and ideally two sprints.
- The backlog items are actively updated and refined by the Product Owner.
- The product backlog is ordered according to business priority.
- A minimum marketable feature set (MMF) is defined.
© 2012 William Patrick Swisher