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.
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.)
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.
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.
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.
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?)
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.