Product Backlog Management
How do great product owners manage their Product Backlogs ?
Here are some common patterns we usually observe in well-managed products. The rules change according to the context but some constants emerge as patterns of good practices. Here they are.
1.Product Backlog is the single source of truth for the product.
The keyword here is "single" and, since we are doing Scrum, we have to be transparent: no "second secret feature list" can be hidden somewhere far from the users' prying eyes. The Product Backlog holds the work that is planned for the product but it is not a "laundry list" with all requests because too much information reduces transparency. The Product Backlog must be kept lean & clean. This is why it is also not a new, agile form of Product Requirement Document (PRD) that was usually handed to developers at the start to serve as guideline.
The Product Backlog (PB) is dynamic, it keeps evolving as new features emerge while old ideas are left behind. PBs are dynamic while PRDs are static. PBs are managed by the Product Owner on a daily basis, PRDs are conceived by department committees and delivered upon formal acceptance ceremonies (not Scrum rituals) after inscrutable contracts are signed.
Product owners need to find ways to incorporate requests and requirements in the Product Backlog transparently. After a MoSCoW (Must have, Should have, Could have and Won't have) filtering and classification session, you can use colors.
Colors help. I use red for the hot topics, those the team is working on, orange for the next-to-be-hot topics and yellow for the yet-to-be-considered ones. This classification is the direct outcome of the grooming process, that is the Product Owner's main responsibility but can be done by the team when more technical details are needed. Finally I use the color blue to classify uncertain or low probability features that we can't yet discard (see the box below). Be ready to explain the color choice and keep a healthy dialog with the stakeholders that don't agree with the current classification.
A colorful snapshot
Hot, warm and cold entries in the Product Backlog can be intuitively represented by a simple color palette. Epics and user stories evolve: they are better understood and more detailed to move up and get closer to execution.
The Product Backlog is transparent so every stakeholder can see what is under work. This opens up space for feedback and criticisms: "why is my request at the bottom of the pile?" I heard more than once. Be ready to explain that beyond understanding the features requested, the team needs time to work on dependencies.
As an expectation management device, the Product Backlog has proven to be an effective tool to reduce confusion and increase focus. The Product Owner must be prepared to defend the order of items as well as avoid new items coming in without serious considerations. The Product Backlog must be protected as we use to protect Scope in projects.
2.Product Owners connect with the users in the market
Good Product Owners listen frequently and pay attention to what users do and how they work, more than what they say they need or want. To connect is to go beyond words and observe behaviors and action. What are the true obstacles ? Should we improve the interface to add another (cluttering) control or can we simply develop a clever algorithm ? Look for new users as advisors on yet unexplored possibilities: what can I learn with this (potential) user today ? Small teachings are valid rewards for our diligent efforts. Empathy is hard, we all have our beliefs and desires, consider others in front of ours is not trivial, yet that is what you must do.
3.Scrum Masters are key to improve the Product Backlog
Teaching someone to fish is the best way to avoid hunger in the future. That is what Scrum Masters do for Product Owners: they prepare them for the future while finding ways to satisfy stakeholders and protect the Product Backlog from "scope creep". Focus is an elusive target when our emotions and fears play on us, that's when the Scrum Master has to put on her oxygen mask before helping the Product Owner with hers. Education goes beyond tools and techniques, it involves keeping cool under fire and marching on, straight into the next Sprint Review.
4.Grooming the Product Backlog is an ongoing task
Coming from a waterfall projects culture, new Product Owners may have the illusion that once the backlog is "complete" the ball is with the team. The backlog is never complete for living products: there will always be someone, somewhere wishing for a different, better way to do things. The ball analogy is not good because there is more than one ball at any given time: the team has theirs (usually more than one) while the Product Owner keeps listening to stakeholders (users and executives) and mulling over new requirements, playing with her own ball. During the product development game, keep calm and carry on, listening to the users, grooming your backlog and sharing it with your team.
Conclusion
The Product Backlog is the travel map in the product journey. Half military, half diplomat, half artist, the Product Owner is the pivot of any product strategy. It's a position that requires an open mind to listen and a solid ground to protect the backlog from "urgent and very important" last minute changes to the plan. The backlog is the travel map to be changed only by a respectful Product Owner: this is the secret of any good product journey.