Deleting the Product Backlog Is Your Salvation to Be Agile
Once the old goes away, the door opens for the new.
Once the old goes away, the door opens for the new.
Before I start telling you why deleting your Product Backlog is your key to freedom, let me ask you some questions:
How many items do you have in your Product Backlog?
When did you create your oldest Product Backlog Item?
How often do you refine something with your Scrum Team that never makes it to a Sprint but still has a safe place in your Product Backlog?
Please, take your time to reflect on these questions. It’s important to be brutally honest. Once I asked the same questions to myself, and I got the following:
450 Product Backlog Items.
Three years and seven months was my oldest Product Backlog Item.
At least 100 items were refined, estimated, and never made to a Sprint.
When I reflected on this situation, I was sure of only one thing:
I missed the mark of what being Agile means.
Now let me share with you why deleting your Product Backlog might be your salvation for being Agile.
An Extensive Product Backlog Is a Strong Enemy for Agility
Do you know what the meaning of being Agile is? I guess nowadays, everyone has a different interpretation of it. I need to share what I understand Agile to be for this post’s purpose: delivering value to end-users and businesses faster.
The challenge is that value is abstract and often interpreted differently. For me, delivering value means helping people progress on their challenges while generating something in return to the business.
Being comfortable with the unknown is key to being Agile.
I believe everything boils down to embracing learning. We should simply create assumptions, validate them, learn something, inspect, and adapt. It doesn’t seem complicated, but somehow I’ve observed many people making it incredibly complex, including me.
For me, an extensive Product Backlog is precisely the opposite of Agile. You may say you are Agile, yet you:
Let items rot in your Product Backlog for years.
Don’t dare to delete a Product Backlog Item because it’d piss off a critical stakeholder.
Waste developers’ time by refining something that will never make it to a Sprint.
I perceive any Product Backlog with more than three Sprints of work as extensive. Let’s be honest, are we trying to do Scrum or Waterfall? If a Product Backlog has more items than the Scrum team can take in a couple of Sprints, it’s a symptom that planning is more important than learning.
To deliver value, you’ve got to keep a lean Product Backlog. Don’t let the illusion of a plan fool you.
Be Bold And Delete Your Product Backlog
A few things make me panic more than an extensive Product Backlog. The reason is simple; I perceive that as a political approach. Let’s compare the Product Backlog with a political campaign.
A candidate will promise the world to the potential voters; everything is possible during the campaign.
Once elected, the candidate will fail to keep more than half of the promises and will have to work on excuses to keep the voters calm.
The promises remain unattended until the end of the mandate, and voters will feel fooled.
Do you see the similarities between politicians and an extensive Product Backlog? It’s a massive list of vast promises that will NEVER be matched. That’s an unsustainable way of managing your Product Backlog.
Don’t fool your stakeholders by putting their wishes into the Product Backlog.
I’ve been a Product Owner in several places until now, and for a long time, I took an unproductive and pointless approach during my first months. I used to do the following:
Read the whole Product Backlog.
Approach key stakeholders to understand the needs behind each item.
Enrich the Product Backlog Items based on my exchanges with Stakeholders.
Prioritize the Product Backlog.
Do you know which results I got? A lot of wasted time and more pressure from many different stakeholders. Everyone wanted something urgently, and nobody was willing to accept removing their items from the Product Backlog. My mistake was a common one:
I let stakeholders drive the car instead of taking the driving seat.
Currently, the first thing I do is the following:
Understand the Product Strategy.
Delete the Product Backlog.
Define assumptions to validate.
Create Product Backlog Items related to the strategy.
You may be thinking now; it’s too radical to delete the Product Backlog. And you’re right. However, to deliver value faster, you’ve got to be extreme. Until you can remove all the noise, you won’t have any time left to do what matters most.
Do stakeholders get mad when I delete their precious items? Yes, they do. But they get even crazier when they realize the product doesn’t reach the expected outcome.
A solid Product Owner does what it takes to deliver value.
Let me tell you a secret: once, I deleted around five hundred Product Backlog Items. Guess how many stakeholders approached me about it. Only two. All the others didn’t raise a single concern. My learning, if you ask for permission, you have a greater chance of getting a rejection, but if you are willing to take risks, the results may surprise you.
Without Conflicts, Agile Is Dead
Pissing people off is the hardest part of doing what is right for the product. You cannot find ways of delivering value faster by pleasing everyone. That means conflicts, and consequently, stress. Your ability to handle conflicts will define how successful you can be as a Product Owner.
Like with everything in life, short-term benefits will guarantee long-term frustrations.
If your Product Backlog reflects perfectly the wishes of your stakeholders, they will be happy in the beginning and lately frustrated once you fail to match all of their expectations. Yet, if you take the hard way and embrace conflicts to reach commitment, you can lead the Scrum Team to deliver value instead of falling into a WaterScrumFall pattern.
To ensure you are not falling into an illusion validity trap, delete your Product Backlog every three months. Create space for the new and let the noise disappear. Give the Scrum team time to reflect on the learnings, evaluate what makes sense for this moment, and have a fresh start.
“Finally, the illusions of validity and skill are supported by a powerful professional culture. We know that people can maintain an unshakable faith in any proposition, however absurd, when they are sustained by a community of like-minded believers.”
― Daniel Kahneman, Thinking, Fast and Slow
