Agile Product Management with Scrum : Chapter 3 : Product backlog
In which I summarize and discuss chapter 3 of Roman Pichler’s book on the Scrum product owner role.
Summary of Chapter 3
The product backlog is a beautifully simple prioritized queue of user stories.
The DEEP qualities of the product backlog
Detailed appropriately
The highest priority items have the most detail so that they are the most concretely ready for action. The lower priority items have much less detail because there’s no credible threat that the team would act on them and by the time they would rise to the top of the backlog their details would have changed anyway. (Detail the entries as they rise.)
Estimated
Product backlog entries are estimated in a coarse-grained way, in terms of story points or ideal days or so.
Emergent
The product backlog is continually updated and its content, details, and priorities emerge from the work of the team and the feedback on the product.
Prioritized
The product backlog is strictly linearly prioritized, top to bottom.
Grooming the product backlog
Continually:
- New items are added
- Existing items are revised
- Obviated items are removed
- All items are prioritized
- The highest priority items are detailed, decomposed, and refined
- The team estimates the highest priority backlog entries
Grooming is a collaborative process, with Scrum allocating team time for this grooming.
The product owner is responsible for the health of the product backlog and is the authority over its content and priority, but grooming is nonetheless a shared activity significantly involving the entire team.
Requirements are no longer handed off to the team; the team members coauthor them.
Pichler recommends paper cards to support grooming activities, even when what is learned from the grooming activities is to be entered back into an electronic product backlog tracking system.
Discovering and describing items
Discovering items is best done collaboratively, with a focus on discovering the minimum necessary product.
Treat requirements as suspect and a liability. A requirement is probably wrong and not needed anyway, until it proves out as necessary and correct.
Items are best described as user stories, with supplemental artifacts only where they help.
Epics are helpful for organizing and staking out themes.
Prioritizing
Prioritize themes or epics first.
If it’s not essential to the next release of the product, it’s not a priority.
Be bold about deleting non-priorities outright. If they are important, they will re-emerge. (Personally, this is advice I struggle with mightily — I am a product backlog entry hoarder.)
If the next release could ship without it, it is not a priority.
If the next release cannot ship without it, is there a simpler and cheaper way to fulfill the user story well enough for the next release? If so, prioritize that instead.
When in doubt, it is not a priority; ship without it and respond to feedback.
Risk
Uncertain and risky items should be prioritized and tackled first.
This maximizes learning and digs into areas of risk soonest. If the project is destined to fail because an area of risk cannot be resolved, it is best to discover this soonest so as to minimize wasted effort. If the project is destined to overcome the risk, it is very likely that something important will be learned from this that will affect other things the team does (and would have done not informed by this learning if overcoming the risk had been deferred.)
Releasability
Release early and often, so prioritize those stories that will result in software you are willing to release. If you are not willing to release a solution, there’s no need to have developed that solution yet; instead focus on building something you are willing to release.
Dependencies
Minimize and resolve dependencies where possible, but dependencies are a fact of life. Some product backlog items are going to depend upon others.
Combining stories or changing the way they are split can help reduce inter-dependency.
If stuff farther down the backlog seems to depend upon stuff much earlier in the backlog, this may not be any kind of problem, since there is little credible threat that the team would soon undertake things farther down the backlog anyway.
Preparing for sprint planning
Sprint planning goes much better with preparation.
Have a sprint goal
The sprint goal summarizes the purpose of the sprint, how the sprint will move the product closer to a release.
Goals help to focus the sprint, hone the backlog priorities, and ease communication about what the team is accomplishing.
Prepare just enough items just in time
The next sprint or two worth of product backlog items should be well-groomed, with sub-tasks identified, sizing estimates attached, and details about supporting resources, ideas for implementing, constraints and dependencies, all documented into the product backlog entries.
Beyond that there’s little benefit to such detail.
Decompose items
Break stories into smaller stories as they reach the top of the backlog so that bite-sized, achievable stories are drawn into sprints.
Ensure that stories are clear, testable, and feasible.
Estimate items
Use story points; play planning poker.
Nonfunctional requirements
Express them as constraints.
Global nonfunctional requirements go into the definition of done (constraints on what work the team considers “done”.)
Local nonfunctional requirements go onto the story (constraints on what will be accepted as a solution for that particular story, that is, acceptance criteria or conditions of satisfaction).
Common mistakes
Anti-pattern: Disguised requirements specification
In this anti-pattern an excessively complete and detailed product backlog gets in the way of emergent insights about how the product should evolve.
Scrap the product backlog and emerge a new one from a quality vision. You do have a quality vision, don’t you? If not, start there.
Anti-pattern: Wish list for Santa
In this anti-pattern there’s no discrimination about what stories make it into the backlog - the backlog contains everything anyone has ever thought of, unrefined and un-reflected-upon. So it is a difficult-to-prioritize difficult-to-understand pile of crud.
Scrap the product backlog and emerge a new one from a quality vision.
Anti-pattern: Requirements push
In this anti-pattern the product owner writes the backlog items alone without involving the team and then hands them off to the team. This misses opportunities to benefit from the team’s expertise and to naturally share understanding of product backlog entries through authoring them together.
Make sure the product owner always involves fellow Scrum team members in the grooming work. Set up one or more grooming workshops each sprint…
Anti-pattern: Grooming neglect
In this anti-pattern the product backlog is not groomed in advance of sprint planning, making the sprint planning a miserable way to plan the wrong sprint.
Undertaking a sprint under conditions of neglected grooming can yield negative value. The magic of Scrum ensues when the team is focused on building the most urgent product towards the soonest release with the best support. Building unimportant or outright wrong product too soon without good support is a way to bury the product in cruft, technical debt, and distractors from what most needs addressed for that soonest release.
If the product backlog is not groomed, the sprint cannot be planned. If this happens more than occasionally, you need to more effectively attend to the product owner role.
This post is part of a series
I have summary posts for each chapter of the book:
-
Chapter 3 : product backlog (this post)
Read the book
It's a good book; you should read it.
While I hope my summary is helpful, the book has more nuance, detail, and examples.
Acknowledgements
Cover photo : Stanley Steamer Car via CC-NC-ND-2.0.