Pending Backlog Items Have a Price

For future plans, please don't create one-liner tickets in your backlog.

The only excuse is when you must "proof" some future work. I knew a project manager in an outsourcing project who told business analysts to create 500 Jira issues to showcase to a customer the scope of work for continuing a development team's assignment.

In recent years, I have been dealing with massive backlogs of outdated items written by people no longer around. That has resulted in painful and time-consuming reviews and (re)-negotiations with stakeholders.

If you have such experience at least once, you are likely a fan of focused and precise backlogs like myself.

Missing context

Dealing with the previous mess is an unavoidable necessity. You can't simply say, "Let's abandon the current backlog and come up with the new shiny one." Even though that might be a rational decision, not all stakeholders will like that.

The main issue is the missed context. A few people met on a topic, agreed on a specific outcome, and created a bunch of tickets in Jira with vague descriptions. These are just some improvements for the future, not the priority for the moment. Also, in a good case, there might be an epic, and in a best-case scenario, there might be a follow-up email with meeting notes.

A year or two passed, and the tickets traveled through plans and roadmaps. Now, you are the newly assigned product owner who has to do something with them. No matter what strategy you choose (we'll discuss that later), you spend valuable time on it. You pay the price for mismanaging the backlog.

Here, we return to the original thought: every backlog item has a price, and the longer it exists, the higher that price is.

That price concerns the time and mental effort you and your colleagues spend on revisiting. Processing such a ticket might be painful from the process perspective because, in large enterprises, you must comply with a ticket lifecycle and rules.

It is not a particularly pleasant activity to do during work hours, especially if you have several hundred such items.

I advise you not to create backlog tickets specifying some plans until you are not sure you will work on them next quarter.

I assure you that the only constant with plans is that they change. The business, organizational, and technical environments around your product also change. In the past, I created too many tickets beforehand that I later canceled, and I canceled many more tickets created with good intentions by someone else.

How to prevent that sprawl?

Document such items for the future in business or product requirements documents, keep them in a spreadsheet or create an epic/Uber epic without going to specific task/feature decomposition.

Basically, it is a backlog for the backlog. But it is not so detailed, thus not extensive, and informal, so you should not follow the process compliance burden.

Adding something to Jira may feel like a distant commitment, but it remains a commitment.

Some outside people can create tickets in your backlog. That is fine when the improvement is isolated and specific and can be completed sooner or later. But make it clear that anything more significant and "it-would-be-nice-for-future" must first be defined and processed in a different format than a bunch of tickets.

Please try your best to preserve the context, source, and essential details. Please don't transfer the price to future yourself to others who might eventually continue your job.

How to deal with the existing sprawl?

If you are a new product owner with a vast and unclear product backlog, there is no easy answer. I am sorry.

You need to review the backlog and cut what is not required anymore. You can only choose some extreme strategies or combine them:

Strategy 1: "Total War"

That means you are determined to pay the full price but proceed with the total clean-up. It is complex and requires dedication, setting your soft skills on max. You also need some of your capacity and the capacity of others, also remembering that it is not your primary responsibility.

You will thoroughly address each topic and trace it back to stakeholders with whom you will prioritize an item or make it redundant until the mess is resolved.

The alternative option is to cut what you see as unnecessary and wait if that hurts somewhere. That is quicker but riskier, considering the stakeholders who could be unhappy with such rushed decisions.

Strategy 2: "Don't Touch"

That means you don't do anything specific and transfer the price to a future you or someone else. Understanding the current priorities is enough; you don't need to touch the past backlog items.

If senior stakeholders raise something, then it is a trigger to reconsider it. Until then, keep it in a trash can at the bottom of the backlog.

Even though the approach "not to do anything" has some negative connotations, it is the most cost-effective and common strategy among the PO peers. You are treated by dealing with ongoing priorities and not only how you manage outdated items in the product backlog.

Strategy 3: "Adapt to survive"

It combines the two extremes: You continuously revisit tickets that have been pending for more than one year while being very conscious and taking time to study involved stakeholders.

That means you can renegotiate the closing with some stakeholders with whom you already have established connections and trust. With some, you need patience and several rounds to define the next steps.

Some topics are too politically sensitive, so it is better not to touch them as that might lead to difficult conversations and ego fights. You must navigate your product and team away from uncharted waters and political battles. Usually, there are some topics that are considered relevant by senior management, but downstream teams avoid them like a plague.

Final thought

Cancelling a pending ticket is not the only answer. You can restructure it and incorporate what is really important into the current or short-term priorities. You can also align it with the long-term priorities and keep it on the epic level instead of many items. The top class is to transfer such an item to another team (let someone else pay the price).

But the main idea is to be responsible for a backlog you manage by keeping it focused and preventing it from sprawling. Don't make other people pay the price for your mismanagement.