transitional object

At the first Agile on the Beach in 2011, I had dinner with Mary and Tom Poppendieck. As we talked about the conference, agile, lean and everything else I distinctly remember Mary saying “From a lean point of view backlogs are a problem. In a lean environment when you have a backlog you want to eliminate it.” (Postscript: Mary has spoken about her views publicly “Why You Should Just Burn Your Backlog“.)

Just then, I was then working with a client with a runaway backlog. I had calculated the backlog growth and found it was regularly greater than the work done “velocity.” It was like a mortgage were the monthly payments didn’t even cover the interest. If I remember correctly, backlog growth, interest, averaged 8.5% per month. I suggested to the client and their supplier that they throw the backlog away. They, not for the first time, thought I was mad. Since then I’ve voiced the same opinion with other clients and got the same response. But the opinion is gaining ground and I’ve even encountered a couple of places were they have moved away from the backlog.

To be fair, backlogs are useful – they can have a useful role to play but that role is akin to a child’s comfort blanket. There comes a time to say goodbye to childish things.

(By the way, I’m really discussing what Scrum calls “the product backlog” rather than the ever changing “sprint backlog.” So I mean: the stuff we might work on in future and not: the stuff we are working on this week, and next.)

I’m not, yet, ready to join Vasco Duarte in declaring #NoBacklogs but my “nuke the backlog” comment in a podcast with Jenny Herald said pretty much the same thing. That comment has attracted a lot of attention and seeded good discussions. I like those discussions and thats why I resist about #NoBacklog. When we started using #NoProjects it was good for conversation, but then a few people drowned out the discussions with calls of “You are mad”, they never considered our arguments and closed down discussion for others.

So what is the backlog problem?

First, as the graph above shows: backlogs don’t “burn down” they tend to grow, and often grow faster than work is done. That becomes a problem because many people expect the backlog to reduce to zero over time and organizations consider success (“Mission accomplished”) to be a completed backlog. The cost of adding something to the backlog is near zero, but the cost, to the product owner and/or team, of refusing a backlog item can be high – all the time spent explaining why something won’t be included.

The desire to “do the backlog” leads to the second problem: an emphasis on doing backlog over delivering value. It becomes more important to do backlog items (output quantity) then deliver benefits (outcomes.)

That, combined with the ever increasing number of items, leads to problem three: a loss of strategy and sense of purpose. This is classic “can’t see the wood for the trees.” There are simply so many backlog items to do it is hard to see what should be done. (The whole “twice the work in half the time” idea that surrounds Scrum makes this worse still. Raising the outcome over output question will also get you called mad.)

Along the way a lot of stakeholder problems get created because people believe that an item in the backlog is in some way promised when it isn’t. Product Owners and Teams accept items into the backlog for an easy life even when they know it is unlikely to ever get done. This stores up future problems because stakeholders start complaining when they fail to get their items. That damages trust in the team and a vicious circle ensues.

It gets more and more difficult to prioritise anything: more items to consider, more stakeholders to placate, more promises to (pretend to) keep. This makes it increasingly difficult to follow the benefit and change course and act on product feedback.

One of the reasons I came to like OKRs, despite my initial scepticism, was that they provided a means to think about the backlog and eventually move away from it. Another reason why I am avoiding #NoBacklog is because I want to be able to offer an alternative rather than just rubbish the backlog. At the moment I think OKRs are that alternative but I’m a little bit reluctant to force OKR Kool-Aid on people.

I tell a story in Succeeding with OKRs in Agile about a little experiment I conducted with another agile coach. The question was “Are OKRs written based on the backlog you intend to do in the next quarter? Or, are OKRs set in respect of business strategy and product priorities and backlog items selected, or even created, to meet the OKR?”. The experiment showed us that OKRs should come first and the backlog was secondary.

Perhaps backlogs are, as I think Vasco thinks, a hang over from the project days. A similar point is hiding inside Project Myopia: in the project model success is doing all the backlog, but if you prioritise by business value, if you are responsive to customers, if you are practicing dual-track agile and product discovery then you may well find that not everything in the backlog is valuable or even wanted by customers.

Increasingly I view Product Backlogs as comfort blankets – what psychologists call transitional objects. Like children’s toys they help us move from one view of the world to another. When starting with an agile style of working backlogs provide comfort by mapping work to the traditional (project) model, but in time, as you become better at listening to customers and responding they are a hinderance.

I’ll be talking more about backlogs and comfort blankets in an online presentation next week to Berlin Product People, join me there to hear more. (5 September 2022).

---

Subscribe to my blog newsletter and get Continuous Digital for free