aka “Honey, I shrunk the backlog”
A few years ago, I was consulting with an airline that had a major web project going on. The engineering team was delivering around 100 story points a month, which sounded quite good — although if you know story points, you know they can be misleading. I calculated the velocity in percentage terms: 7%. The team was doing 7% of the backlog a month. So the forecast would suggest the team would take 14 months to do it all. But…
Backlogs grow. So, I calculated the rate of change. The backlog was growing at something like 7.5% per month. In other words, the backlog was growing faster than it was being done. It was like a mortgage where your monthly payments don’t even cover the interest.
Last week I delivered “Honey, I Shrunk the backlog” at Agile on the Beach. I had a great audience, engaged, lots of good questions and they laughed at all my jokes. The recording will be published soon and the slides are available now, I thought I’d also write up the main message for those of you who prefer the written form.
In the old world, we attempted to freeze requests, but agile people welcome changing requirements, well, kind of. On the one hand, we “Welcome changing requirements, even late in development,” and I have long argued that changing requirements is a sign of success: it demonstrates that people are interested in your product.
On the other hand, success criteria are still tied to “doing all the backlog.” People still use burn-down charts and are still taught to aim for zero, an empty backlog. Some electronic tools conveniently draw a 45-degree “guilt line” — I’ve never seen anyone perform at or above that line, but I know plenty of people who feel guilty not meeting it.
The truth is many teams are still expected to deliver stuff, user stories, product backlog items, and features — call them what you will. Such teams are often characterised as “Feature Factories” — or worse.
Backlogs have become bottomless pits of features. When someone says, “I have a great idea for your product,” the product owner normally takes the easiest course of action and adds the idea to the backlog. That costs very little time and money. Saying, “Great idea, doesn’t really fit with our strategy,” is expensive. Saying, “Thanks, I like the idea. However, we have lots of other really high-value work to do, and it is unlikely to get done” takes time. It probably creates a discussion (and argument!), and if the other person doesn’t like the answer, they may well escalate to get their idea added to the backlog.
Once added, expectations are raised. The PO may well know the feature won’t ever get done. Six months later, if asked, “Have you done my feature yet?” will make a plausible excuse (“Sorry, other priorities”) while they are actually thinking, “If it hasn’t made it in six months, it will probably never make it.” Worse still, this approach undermines trust in the team and the process.
The backlog becomes irrelevant, and teams lose sight of the real goals — which should be more than just “do product backlog items.”
This is where I say, “Nuke the backlog.” Throw it away. Wipe the slate clean.
Every ten weeks or so, revisit your goals, company strategy, product vision, and everything else. Set some goals for the next ten weeks. Only once your goals are set will you start to think about what you need to build, i.e., the backlog.
This approach isn’t that new. Some teams do it already. Amazon talks about “Day 1 thinking.” Companies sometimes use “zero-based budgeting” to rethink costs. In ancient times, a Jubilee year saw debts written off, sins forgiven, and land left fallow.
And in democracies, the whole country gets a vote every few years on who should be in government. New governments walk away from past policies and chart a new direction. Democracy allows us to wipe the slate clean and change the leaders we can adapt.
Nor is focusing on the bigger goal of technology teams. Marty Cagan talks about “The Product Model,” Jeff Gothelf and Mike Burrows talk about outcome-focused work and plans, and so on. The idea is to a) think bigger than stories, b) think about the world you want to create, not the pieces.
So, replace your backlog with a Just-In-Time story generator. Feed it with goals — I recommend OKRs, but you can use product goals, True North, BHAGs, MTPs, or another fuel. Every time you need to know what to work on next, power up the generator and create some small stories to work on, just in time. This is the basis of what I’m calling this Objective-Driven Agile.
Backlogs work in the small spaces — for the team, for the coming week, or the next few sprints, but they don’t scale. The longer-term backlogs — “product backlog” in Scrum terminology — were good initially. But, like children’s comfort blankets and soft toys, they are transient objects which help us grow up. Bcklogs helped us move away from everything-upfront to complete the journey we need to move on. The time has come to leave childish things behind.
Nuke your backlog. You have nothing to lose but your burn-down charts.
Nuke the Backlog was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.