Product Backlog Management: what must a Product Owner avoid?
The backlog management is a crucial part of any Scrum Team. Therefore, the Product Owner must clearly understand what to do and what NOT to…
The backlog management is a crucial part of any Scrum Team. Therefore, the Product Owner must clearly understand what to do and what NOT to do.

Why is product backlog management so important? Because the Backlog defines the direction of a Scrum Team. Therefore, we must be careful not to fall into some pitfalls while handling this so crucial artifact.
Let’s understand what a Product Backlog is according to the Scrum Guide.
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.
On my journey as a Product Owner, I came across many common misunderstanding of the Product Backlog, in short, these are:
The Product Owner is the only one who can manage the Product Backlog;
The Product Backlog is oversized because of too much plan upfront;
Multiple Product Backlogs, e.g., Feature and Technical;
No frequent maintenance with the Product Backlog;
The Product Backlog Items are over-refined.
Let’s go in more depth with each item.
Only the Product Owner can manage it
Unfortunately, there’s a big misunderstanding among many Product Owners about Backlog Management. A Product Owner is accountable for the Product Backlog, which means Product Owners take responsibility for it. However, it does not mean they are the only ones who can insert new items into the product backlog.

A Product Owner should encourage the Scrum Team and stakeholders to create new Product Backlog Items. The Scrum framework fosters collaboration. Therefore, Product Owners cannot be the only ones who manage the BacklogBacklog. Once new Product Backlog Items come in, we as Product Owners should instead understand, refine, and suitably order them.
Individuals and interactions over processes and tools
The Product Owner background can be the reason for this common misunderstanding. For example, in traditional methodologies, the requirements are not managed collaboratively, mainly the analysts write it down. However, it doesn’t justify the Product Owner not adapting to collaborate more with everyone, so that a better Product Backlog can be established.
There are many different reasons for this myth to come into existence. One common cause is when Product Owners double as (business) analysts or come into the role from this background. From this perspective, it might seem sensible for them to take care of all of the ‘requirements analysis’ that is required to populate a Product Backlog. Often, Development Teams encourage this so they can focus on what they assume is their most important task: write code. But this is not how the roles are intended.
— Christiaan Verwijs, Myth: The Product Backlog is maintained exclusively by the Product Owner
Old Product Backlog Items
A Product Backlog is a living artifact, which means Product Owners must continuously review it. Yet, I have come across scenarios where the Product Backlog has items older than two years. Then I ask:
If the Product Backlog Item is lying in the backlog for two years, what is the value of such item?
I am a firm believer old items should be removed from the Product Backlog to avoid waste. Once we don’t have them, we don’t need to bother. The question is, how can we handle this scenario? I don’t keep items older than three months. I remove from the Product Backlog all items older than this period. Since I started following this approach, I felt we became a more productive and efficient team.
The product backlog contains items that haven’t been touched for six to eight weeks or more. (That is typically the length of two to four sprints. If the product owner is hoarding backlog items, the risk emerges that older items become outdated, thus rendering previously invested work of the scrum team obsolete.)
— Stefan Wolpers, 28 Product Backlog and Refinement Anti-Patterns
Product Backlog items become stale like milk if you keep old items alive. Eventually, you need to talk about them. Most probably, you decide to keep them ordered lower in the Product Backlog. So why not remove it? Don’t get passionate about the Product Backlog Items, remember, Scrum is about inspecting and adapting.
Break into different boundaries
The Scrum Guide emphasizes, the Product Backlog lists everything related to product development; yet, many teams decide to split it up into technical and feature Product Backlog. Dividing the Product Backlog is a massive mistake. There is only one Product Backlog.
Why is multiple Product Backlog is a problem? The collaboration is reduced drastically; silos become a reality. A common problematic scenario is breaking the Product Backlog into Tech and Business. In this case, misalignment is inevitable between the Product Owner and Development team, which brings significant drawbacks to the whole Scrum performance.
There’s only one Scrum Team; they are responsible for everything related to the Product Development. Together they must find a way of managing and ordering the Product Backlog. The Product Owner must provide the product vision, so the team can understand the technical challenges that may come; as a single team, a Product Backlog is built.
Infrequent maintenance
As I mentioned earlier, the Product Backlog is a living artifact. Even though we know the Product Backlog is never complete, I have seen many teams investing not enough time in the refinement of the Product Backlog Items. This approach is an anti-pattern, which we must avoid.
By not doing enough Product Backlog Refinement sessions, the Scrum Team misses a chance of inspecting and adapting. We must accept we don’t know everything to reach our goal; therefore, we need to keep refining the Product Backlog Items, so that we can inspect and adapt as it is required.
The Scrum Guide suggests the Backlog Refinement usually consumes no more than 10% of the Development Team capacity. My approach is, in a two-week Sprint, I invest 1h30min in the Backlog Refinement, it works well, but you should evaluate what fits your scenario best.
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Over refinement
Another anti-pattern is having too many Product Backlog Items refined. It is essential to keep in mind that the Product Backlog is an ordered list, where to top items are more detailed than the lower items.
Once we fall into this trap, we tend to have too much-planned upfront. However, planning too far ahead generates waste, since as we sprint, we learn more, meaning that the lower Product Backlog Items might be refined or even become obsolete. Therefore, we need to refine items on the top; then, as we keep learning, we refine the other items. The lower the item is, the less we know.
Simplicity — the art of maximizing the amount
of work not done — is essential.
A great Product Backlog Item starts a conversation. The goal of this conversation is to establish a common understanding. It is impossible to perfectly describe what you want to build. The best you can do is try to get everyone on the same page and reach consensus in their mind.
— Maarten Dalmijn, Great Product Owners write awful backlog items
Oversized
Some Product Owners transitioning from either traditional methodologies or coming from a Project Management background tend to over plan. In the Waterfall approach, the requirements are all defined up-front. Also, the requirements are characterized generally by a single person or separate team, which means the team is not involved.
In Scrum, we need to accept we do not know our path from the beginning. We know where we want to go, but the path we discover within experience and learning. Remember, Scrum is empirical; the more we walk, the more we know.
Empiricism asserts that knowledge comes from experience and making decisions based on what is known.
Be careful, don’t transform your Scrum into Waterfall!
The scrum team creates a product backlog covering the complete project or product upfront because the scope of the release is limited. (Question: how can you be sure to know today what to deliver in six months from now?)
— Stefan Wolpers, 28 Product Backlog and Refinement Anti-Patterns
Wrap-up
Product Backlog Management is a joint activity, everyone collaborates over it. A successful product backlog management must have the following characteristics:
Product Owners encourage everyone to produce new Product Backlog Items.
The Product Backlog refinement happens as often as it is needed.
Items older than three months are removed without discussion.
There is a single Product Backlog.
Only the items on the top of the Backlog are refined.
There is no up-front planning; we accept we don’t know the whole path.
Do you want to write for Serious Scrum or seriously discuss Scrum?