The Perfect Product Backlog
The perfect product backlog
A healthy product backlog is a necessary requisite to a healthy Scrum team. Rather than focusing only on refining user stories for the upcoming sprint, prudent Scrum teams invest in refining the full product backlog to increase transparency, stay focused on their vision, and keep the full organization aligned. Achieving transparency consists of much more than simply making information available, interested parties have to be able to get the information they're looking for in a matter of seconds.
Have a look at the product backlog below for an example of what I'd consider is the perfect product backlog. This product backlog clearly displays the work for the upcoming sprint, the longer-term product roadmap, key milestone dates and it articulates a vision for the future - all in a single page! Viewing the product backlog in this way allows all stakeholders, customers, team members and executives to quickly digest the state of the product. The most recent retrospective action items are at the top. All user stories are estimated. Regardless of the audience, everyone gets the information they need in less than 30 seconds.
Where user stories go to die
Ever come across a product backlog where the next sprint's user stories are clearly defined at the top and then followed by a whole bunch of unprioritized junk at the bottom? I call this the graveyard backlog. It grows larger over time. There are too many user stories to keep track of so the estimates go stale. This backlog no longer fits into a single screen, so people have stopped reading it - even the Product Owner. Graveyard backlogs breed unhealthy behaviour within and external to the Scrum team. These behaviors appear in a variety of ways; the team starts to have conflicting views about why they're building what they're building, the Product Owner spends time creating PowerPoint versions of the product backlog to communicate status, Stakeholder groups create and maintain their own version of the product backlog for road mapping, each group speaks a different language and conflict arises as interpretations of the product backlog diverge. This anti-pattern, which entrenches silos between business people and Scrum teams, happens when the product backlog becomes a neglected space for dozens of small user stories that will never be worked on and whose value is questionable at best.
Resurrecting the Perfect Product Backlog
So, how might a team go from having a Graveyard Product Backlog to creating the Perfect Product Backlog?
Start by paring your product backlog down if it has more than 20 user stories in it. Twenty is the magic number because it promotes good behaviours. Ever see an episode of Hoarders where an otherwise successful person is unable to part ways with 1000's of pop cans that they've collected over decades? Well, the same thing happens with product backlogs as they grow. We become emotionally attached to user stories when we invest in refining them and it is difficult for us to let them go. There's even a term for it now, FOTO (the fear of throwing out). Overcoming this fear will clarify your vision and allow your team to focus on the future. And hey, throwing stuff out just feels good.
Add your roadmap and vision statement to your product backlog. In my experience, teams that can't see past the next sprint will feel lost, lack inspiration and spend more time worrying about job security than they do about innovating new features.
Merge all roadmaps and backlogs for your product into a single list. Conway's Law warns us that using separate tools for managing work and strategy, like JIRA for product backlogs and Aha! for strategic roadmaps, is a bad idea. Doing so silos business and development organizations. Break down those silos, increase transparency and empower your team with the context they need to build great products by having a single product backlog in one highly-visible place with no more than 20 user stories.
Use the time spent in refinement to invest in building the perfect product backlog, not just to create user stories for the next sprint.
Present your actual product backlog when discussing progress, like at the sprint review, so that your customers and executives become comfortable with it and know where to find it.
Does your product backlog most closely resemble the prefect product backlog or a graveyard? How is that product backlog impacting behaviour and results? What will you do about it?