The Product Backlog provides a transparent view of what is planned for the Product. The Product Goal, a commitment to the Product Backlog, describes the direction of the changes. The Product Backlog is for everyone interested in the Product. The Scrum Team uses it to plan, Stakeholders view it to see what is happening and what decisions have been made about the Product, and the Product Owner uses it to structure what they think. Other teams can view the Product Backlog to uncover dependencies. The idea is simple, and if done well, a Product Backlog can be very liberating for everyone involved.
However, for many, a Product Backlog becomes a nightmare. It becomes:
- A list of promises that will never be met
- A confusing set of contradictions and ideas
- A series of incomplete thoughts that are encouraging but never finished
- A group of expectations that are impossible to deliver on
- A description of old problems and issues that are no longer relevant
- A collection of very different things that do not hang together
- A waste of time reading because the Scrum Team decides to do something different every Sprint
Product Backlogs can become unmanageable and weight for everyone involved. But no one wants their Product Backlog to become a nightmare. So, what key indicators are your Product Backlog getting out of control?
It's on the Backlog (but I do not plan on doing it).
Indeed, things added to the Product Backlog might not be delivered. Items are added when they come up, and the Product evolves, which might remove the need for that Product Backlog Item to be valuable. Also, no Scrum Team(s) have infinite capacity, so choices may lead teams to not deliver on valuable items because more valuable items are present. However, using the Product Backlog to avoid saying no is never a good strategy.
Everyone has ideas for where the Product should go next. Those ideas range from detailed feature requests to larger strategic directions. Many are fascinating, and some are valuable. The product owner's number one responsibility is to ensure that the Product delivers value in the right order for the organization and its stakeholders. They should never be the only person good ideas come from, but they should be the person who decides if these ideas are entered into the Product Backlog. However, saying no to an idea is sometimes much more complicated than saying no now. I have been guilty of adding items to the Product Backlog to avoid conflict. This is bad because:
- Saying no can lead to a deeper understanding of the idea and ultimately result in a better, more refined idea that does add value to the Product Backlog.
- If an idea is not added to the Product Backlog, expectations are set. Many people assume that if an item is added to the Product Backlog, it will be delivered. This creates an expectation that ultimately is not realized. Trust is built on expectations. When you do not deliver on an expectation, you eventually erode trust, which is never good.
- The Product Owners' authority is connected to how others perceive them. By always saying yes, that authority can be negated, and everyone thinks that the Product Owner is an order taker rather than an owner of the Product.
Some items are so old no one can remember adding them.
I recently discovered a notebook from when I joined Scrum.org over seven years ago. In that notebook is a to-do list of things that would be important for me to accomplish in the first 90 days. Four of the twenty items are ticked. As I read the list, I was shocked by how irrelevant some things were. I was also surprised by how valuable some items I never got around to are still today. A good Product Backlog is a living document. It changes to reflect the changing ideas about the Product. But items that have not been updated become less and less relevant and valuable. Reviewing all the backlog items frequently is essential, ensuring they are still relevant and helpful. So good practices for this review include:
- Add two date fields that show when the item was created and last updated. This can provide excellent visibility to the Scrum Team about how old these items are. Adding an aging field can also be valuable.
- Run regular backlog reviews where the whole team can reflect on the value of each backlog item and its relevance. If the backlog is big the review date may be captured, allowing you to work through the backlog in multiple meetings. Invite Stakeholders to this meeting to ensure that a broader point of view is considered.
- The Product Goal should shape the Product Backlog. For any complex and interesting Product, the team could always work on many things. But the Product Goal helps shape what the team focuses on. This means that the Product Backlog should reflect how the Scrum Team will deliver on that goal and not include items that do not reflect that goal. Of course, future ideas are great and should be captured, but not in the Product Backlog.
- Ensure the team knows and understands that Product Backlog Items can be deleted. This might include a practice where those items are moved into another area with comments about why they were moved. This can be useful when looking at future work and strategy.
Every Backlog Item is very different.
When the Product Backlog is new, for a new product, the items describe aspirations and features that will deliver on the product's vision. As time progresses and the Product is launched, the backlog starts to include other items, such as bugs and new ideas for the Product. These items can describe large or small things. The volume of these items grows over time, so it is tough for the team to get an idea of what the roadmap looks like because of the sheer volume of these items. Some things are tiny, some very big, but they all take up valuable real estate. When dealing with a large but valuable Product Backlog:
- Add tags to the Backlog Items that allow you to view the Roadmap versus bugs and maintenance-type work.
- Spend time refining like items into a smaller number. There might be some patterns or natural groupings to the Product Backlog Items that enable you to reduce the number of the items.
Product Backlogs are like Gardens.
Investing time in the Product Backlog has a great return. There will, however, be times when the focus is on other things and, like a garden, you have to tidy up. Involving the whole Scrum Team in keeping the Product Backlog tidy ensures that this crucial artifact is valuable and everyone gains some ownership and connection to its contents. Product Backlogs that are only worked on by the Product Owner tend not to be as good as ones where the whole team is involved.
Like a garden, perfection is not possible. When you see a perfect Product Backlog, it is likely that it does not reflect the situation of the Product but is some ‘show’ backlog to ensure that stakeholders or the process police are happy. Product Backlogs are always a little messy, with new items being added, things changing, and items being removed as the Scrum Team wrestles with the complexity of the problem they are trying to solve. The larger the complexity, the more fluid and dynamic the Product Backlog is.