Backlog Management, What Not to Do

Backlog management is a crucial part of any Product Team. Therefore, the Product Manager 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 team. We must be careful not to fall into some pitfalls while handling this so crucial artifact.

On my journey, I came across many common misunderstandings of the Product Backlog. In short, these are:

• The Product Manager is the only one who can manage the Product Backlog
• The Product Backlog is oversized because of too many plans 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 Managers Can Handle?It

Unfortunately, many Product Managers have a big misunderstanding about Backlog Management. A Product Manager is accountable for the outcome of the product. However, it doesn't mean they are the only ones who can insert new items into the product backlog.

A Product Manager should encourage the Product Team and stakeholders to create new Product Backlog Items. Without collaboration, it's just a matter of time for Product Managers to become the bottleneck.

Individuals and interactions over processes and?tools—?Agile Manifesto

The Product Manager's background can be the reason for this common misunderstanding. However, it doesn’t justify Product Managers not adapting to collaborate with everyone to establish a better Product Backlog. For example, in traditional methodologies, the requirements are not managed collaboratively; mainly, requirement engineers write them down.

Old Product Backlog?Items

A Product Backlog is a living artifact, which means Product Managers must continuously review it. Yet, I have encountered 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 believe old items should be removed from the Product Backlog to avoid distractions. 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, we have become 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, Agile is about accelerating the learning time.

Multiple Product Backlogs

Suppose you work with Scrum; then the Product Backlog lists everything related to product development; yet, many teams split it into technical and feature Product Backlog. Dividing the Product Backlog is a massive mistake. There is only one Product Backlog.

More backlogs = more confusion.

Why are multiple Product Backlogs 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 Product Managers and Developers, which brings significant drawbacks to the whole team's performance.

The Product Team is responsible for everything related to Product Development. Together they must find a way of managing and ordering the Product Backlog. Product Managers must provide the product vision to 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 Product Team misses inspecting and adapting. We must accept that we don’t know everything to reach our goal; therefore, we need to keep refining the Product Backlog Items to inspect and adapt as required.

A good rule of thumb is to continuously use no more than 10% of the Product Team capacity to refine the Product Backlog. In a two-week Sprint, I invest 1h30min in the Backlog Refinement, it works well, but you should evaluate what fits your scenario best.

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 we learn more as we sprint, meaning that the lower Product Backlog Items might be refined or become obsolete. The lower the item is, the less we know. Therefore, we need to refine items on the top; then, we refine the other items as we keep learning.

Simplicity — the art of maximizing the amount of work not done — is essential.—?Agile Manifesto

Oversized

Some Product Managers 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 generally characterized by a single person or separate team, which means the team is not involved.

With Agile, we need to accept that we do not know our path. We know where we want to go, but we discover through experience and learning. Remember, Agile is empirical; the more we walk, the more we learn.

Wrap-up

Product Backlog Management is a joint activity. Everyone collaborates over it. A successful product backlog management must have the following characteristics:

• Product Managers 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 don’t know the whole path.