Do you know this? A product backlog with over 500 entries. Every idea, every request, every email has found its way there. The product backlog is supposed to provide orientation - but in reality it often looks like an overflowing basement room: full of things that could be used at some point.
The product backlog thus becomes a wish list. No one in the team has an overview of why there is which entry, which are duplicates, which are outdated. Planning with such a product backlog is impossible. Prioritization is arbitrary, there is no strategy for what belongs in which release and the actual product development loses focus. The Product Owner (PO) only manages and the Scrum Master does not fulfill his leadership role of coaching the PO in this phenomenon. I keep seeing three typical problems:
Product backlogs are too large
A product backlog is not a wish list. Nevertheless, many people use it as such. The result: hundreds of items that are never implemented. It's unclear who is supposed to make sense of it all. Tickets are sometimes created twice, there is a fear of deleting entries, and often anyone in the organization can easily create product backlog entries. Often, too many item types in JIRA lead to Erics, requirements, user stories, bugs, tasks, etc. Translated with DeepL.com (free version)
My tip: Be brave when sorting out.
Anything that is not clearly related to the product strategy is removed. Ideas can go on a separate list. But the backlog? That remains lean, clear and reduced to the essentials.
Prioritization in the backlog: stakeholder volume instead of customer benefit
The order in the backlog is often more of a coincidence than a strategy. More powerful stakeholders often prevail - and therefore not necessarily the best ideas for customers. Teams notice this immediately: the work feels arbitrary, the common thread is missing. Sprint goals cannot be achieved in this way. Work is not done incrementally because the team feels that every topic has already been started.
My tip: Make customer benefits visible.
Use simple models such as "cost of delay" or story mapping The important thing is not the tool, but the attitude: customer benefit before stakeholder volume. This makes prioritization comprehensible and transparent.
No estimation, and therefore no risk management and no release planning
I often hear "estimating is a waste of time" or "it's too big, we can't estimate like that". The result: backlogs full of unclear entries. Without estimates, however, there is no real risk management and no optimal resource planning. Without an estimate, the PO can't see whether they might need more budget and need to strengthen the team, for example, what exactly is missing from the description or what can be delivered when.
My tip: A rough estimate is enough. But estimate!
Estimate epics roughly, estimate stories on a more detailed level. Don't have too many product backlog entry types, such as requirements, epics, tasks, and user stories. This creates a picture that you can use to plan. It's not a crystal ball, but it's a much better basis than pure gut feeling. You can create forecasts, plan releases, and check how many developers are needed..
The product owner needs active time for backlog maintenance
A product backlog is not a folder. It is a strategic tool.
And like any tool, it only works if it is looked after:
- Keep it small.
- Prioritize based on benefits.
- Estimating to make risks and planning tangible.
But precisely these things do not happen on their own. They only happen if a product owner actively takes time - for strategy, for prioritization, for maintaining the backlog. This is not a minor matter, but a core task. And the job of a Scrum Master is to enable the PO to do this.
This turns a cluttered basement room back into what it should be: the heart of agile product development.
Write a comment