How to deal with an absolute unit of a Product Backlog?
When you don’t manage your gargantuan Product Backlog, it manages you
I remember thinking: “How the hell did we end up in this tremendous mess? I did not sign up for this.”
Regret instantly kicked in. After studying the various Jira projects and support boards I would be overseeing for only a few minutes, my mind drifted away. I wondered what kind of dysfunctions could be at the core of this scandalous amount of clutter.
The day I started as a Product Owner for three new teams, I inherited an extraordinary legacy from my predecessors:
- A support board with 80 issues, some of them older than a year. Despite having ironclad SLAs (Service Level Agreements) in place that were not being met.
- A Product Backlog containing more than 500 items, many with angry comments from stakeholders asking why their requests hadn’t been picked up yet.
- Hundreds of Product Backlog Items with only a title. When opening them, I often could see lengthy conversations with different stakeholders about how vital this Product Backlog Item was for them.
After becoming the proud owner of this magnificent pile of junk, I remember thinking of what Tyler Durden said in the movie Fight Club:
“The things you own end up owning you.”
— Tyler Durden, Fight Club by Chuck Palahniuk
When you rephrase this to fit with the world of Product Management and Scrum:
“When you don’t own your Product Backlog, it owns you.”
Aware of my unfortunate situation, it took me a few days to accept my fate. I started thinking about how to best deal with it.
In other words: how could I escape death by Product Backlog?
Escaping death by Product Backlog
I was buried to the neck in Backlog Items and support tickets. Unless I fixed this first, failure was guaranteed. My Product Backlog would end up owning me, making me unable to do my actual job: delivering value to our customers and the business.
My first priority was to claw my way out of this towering garbage heap. Otherwise, stakeholder harassment and disappointment were unavoidable. Irritated stakeholder: “Why isn’t my ticket done yet?”, fingers drumming on their desk. Me with a puzzled look on my face: Uh…which one in the giant pile are you talking about exactly?”
I decided it was better to take matters into my own hands and control the pending disappointment. I realized there was no way I could prevent making them unhappy. Their disappointment was inevitable. I only had control over the exact moment when it would happen: It could either be instant or a delayed affair.
I weighed the different options at my disposal with a sense of impending doom. I could ignore the mess, try to do my job, and inevitably fail. Alternatively, I could say no and be perceived as a failure from the get-go.
I decided to take control by immediately saying, “No.” Taking matters into my own hands was the only way I would have an opportunity to make a difference for our customers and the business. Hopping on the existing Product Backlog train would be the easiest. But the easy path would lead to the worst results in the long run.
I wrote a Jira query to retrieve all open Backlog Items that hadn’t seen any activity for more than three months. I bulk-closed all of them with sweaty hands and left the following comment:
“I’m the new Product Owner and I’m cleaning up the Product Backlog. I’m closing this issue because it hasn’t seen any activity for more than 3 months, and there are hundreds of issues like this one. My assumption, therefore, is that it isn’t that important or valuable. Otherwise, why didn’t we move it along already?
This assumption could be wrong. If you believe I’m making a mistake, then please don’t hesitate to reach out to me so we can talk about it.”
I ruthlessly closed 423 issues that hadn’t seen any activity in the past three months. It felt great, like popping a giant zit. Ahhh! Much better.
Until the angry e-mails started pouring in. “Why did you close my request? I had been waiting for this for more than three years already.”
That’s when I realized: oh man, this is going to be difficult.
Deciding on the right strategy to handle my different stakeholders
Many promises had been made to stakeholders, and countless vows had been broken. If my experience had not taught me better, I would have attempted to honor whatever promises had been made in a futile attempt to please everyone.
I was not assigned to these teams to uphold a suboptimal status quo. I wanted to make a difference. To deliver the best results, you need to make tough calls and face difficult situations.
I decided to reconsider and reevaluate everything promised by the previous Product Owners. I reasoned because of the mess they left — and were working in and encumbered by — it didn’t make much sense to act under the assumption they made the right decisions.
But how could I explain this in a way to stakeholders that they’d agree and not end up hating me?
Fortunately, we had recently decided to build a new platform. So the timing was good to reexamine the prior promises with the new platform in mind. All past decisions weren’t necessarily still the right thing to do.
Building something on our existing platform means we will discard it in the near future. So we had to be careful about what we decide to pick up. You don’t want to waste months building something you will throw away only a few months later.
I decided to face the issue head-on and planned a one-on-one meeting with each of my stakeholders. I followed a ‘divide and conquer’ strategy. Meeting them all at once would guarantee a massacre, with me at both the losing and receiving end. Better to pick and fight only one battle at a time.
Holding initial conversations with stakeholders
As I met with each stakeholder, I explained the situation had changed. As we are rebuilding the platform, everything needs to be reevaluated in this new light. This new perspective made the stakeholders uncomfortable and argumentative. They wanted the promises made by my predecessors to be upheld. They had already been waiting for years, after all.
I argued that my default stance was not to honor any commitments my predecessors had made. Those commitments were made by my predecessors and not by me. I didn’t take on this position to blindly execute their legacy.
Simply honoring a commitment because someone else made it before you doesn’t make sense. We now had better and more information at our disposal than when those commitments were made. Why not make use of these learnings and insights? It would be best for the company to reconsider what made the most sense to be doing now.
I asked every stakeholder how many promised commitments had actually been delivered. They admitted they rarely got what they wanted. I explained how a large Product Backlog means you will not get what you want by default. The illusion of progress, chucking something on top of the Product Backlog, isn’t the same as actual progress.
Adding it to the Product Backlog, knowing fully well it will never be worked on, is the sign of a weak Product Owner who can’t say no. My predecessors were implicitly saying no. Creating a Product Backlog Item and never getting back to you is what we call the ‘Soft no’.
I say no explicitly. When I do say “Yes,” you can expect me to deliver unless there is new information that makes the work unimportant or obsolete. In that case, I’ll let you know.
Luckily, but grumpily, my stakeholders agreed in the end and accepted my reasoning. I was able to start with a clean slate only a few weeks in.
What would have happened if I was unable to pull off this extensive and elaborate cleansing?
A stale and long backlog weakens the ability to deliver value
As a Product Owner, you must keep your Product Backlog short and fresh. When you do your job well, you’re constantly learning every Sprint about your customer, the business, and technical hurdles. A large backlog would have to be thrown out when you learn a better path. All that time creating your big backlog would be effort wasted.
When your Product Backlog is short, every item will contain the latest and best information at your disposal. You won’t waste valuable time reworking, polishing, or discarding Product Backlog Items. Whatever you don’t create can’t come back to haunt you later.
In the wise words of Bruce Lee:
“Running water never grows stale. You have to keep on flowing.” — Bruce Lee
Your Product Backlog should ebb and flow. It should be in a constant state of flux. The moment the Product Backlog grows too big, items are old and unchanging, then it will inevitably become stale. Even water becomes stale. You will be effectively wasting effort dealing with rotten Product Backlog Items with diminished value.
To better understand the impact of Product Backlog Items that linger, let’s talk about fire sprinklers. The water in fire sprinklers never flows unless there is a fire.
A lesser-known fact about fire sprinklers is that the water inside them, because it never flows, becomes a pungent and putrid slurry over time.
Here’s what fire sprinkler water appears like in movies:
In movies, it looks like there are many showerheads in the ceiling with clear water coming out. Instead, here’s what fire sprinkler water looks like in the real world:
I bet it doesn’t nearly look as nice as you expected. It looks nauseating and hideous, right? The next time you are watching a movie and see people dancing in water coming from fire sprinklers, you can be assured that this isn’t something that happens in the real world.
A pretty, detailed, estimated, and exhaustive Product Backlog may be an impressive sight to behold. You might look at it with pride and feel the urge to do a little dance of joy. But that’s all in your imagination — like fire sprinkler systems with clear and fresh water coming out of them.
In the real world, that beautiful, long Product Backlog is actually a sludge bucket. Just like water in a sprinkler system, over time, it turns into an unsightly and smelly ooze.
How can Product Backlog Items become stale?
There are many reasons for Product Backlog Items to become stale:
- The work is no longer important due to a change of direction in the company.
- It was already fixed as part of another issue, either accidentally or on purpose.
- It will become obsolete due to another feature we will work on in the near future.
- The solution direction of the feature is no longer applicable due to architectural changes. The whole Product Backlog item needs to be reworked and re-estimated.
- Due to new insights, we know the Product Backlog Item will actually not solve the problem it intends to solve.
The list of reasons I provided is not exhaustive. There are many more reasons that can cause a Product Backlog Item to go stale.
The best way to prevent a Product Backlog from going stale is by keeping it small and fresh. This way, Product Backlog Items are finished before they have a chance to become stale.
Keep your Product Backlog small and fresh
By keeping your Product Backlog short, you prevent the following forms of waste, as they are known in Lean:
- Waste of overproduction. Refining a lot more than what needs to be refined. Just refine what you need now. Who knows what the future brings?
- Waste of stock at hand. A long backlog usually contains a lot of noise, which drowns out the signal of the actually valuable items. A long Product Backlog distracts from what is actually valuable to do next.
To express it in more simple terms, by keeping your backlog short, you ensure:
- Product Backlog Items are based on the latest and greatest insights.
- Less rework will be necessary to keep backlog items fresh.
- You will discuss fewer things you will never work on.
By keeping your Product Backlog fresh, you make everybody’s life easier. Don’t be a hoarder. Get rid of what you do not need. Or as expressed in a much nicer way:
“The ability to simplify means to eliminate the unnecessary so that the necessary may speak.” — Hans Hoffman
Remove the unnecessary so the necessary may speak. By saying no, you say yes to what really matters. You need courage and excellent stakeholders skills to make this happen. You need to be willing to have tough conversations and hard negotiations with stakeholders who are often far more senior to you without putting your job at risk.
Few Product Owners are capable of pulling this off. A large Product Backlog is usually the symptom of a weak Product Owner who cannot handle or include their stakeholders.
In the Scrum Guide, it says the following about the Product Backlog
“The Product Backlog is an emergent, ordered list of what is needed to improve the product” — Scrum Guide 2020
Only add things to the Product Backlog if you are reasonably confident you’ll need them. Don’t be too eager to add new things there. The Product Backlog isn’t your list of ideas or a place to store customer feedback. The Product Backlog should be a highly visible list of what you intend to work on in the near future.
Keep your Product Backlog flowing so you don’t end up with a bucket of foul and rancid slurry that will come back to haunt you — both in your nightmares and in the real world.
Do you want to write for Serious Scrum or seriously discuss Scrum?
