The Product Backlog – “One safe waiting place”

What is a product backlog? What problem is it supposed to solve? What problems sometimes arise when using one? So many questions, and not a lot of guidance out there for Product Managers and Product Owners.

What is a Backlog?

The Agile Alliance’s definition starts off as follows:

“A backlog is a list of features or technical tasks which the team maintains and which, at a given moment, are known to be necessary and sufficient to complete a project or a release”

I suspect this definition was written back in the 1990s. The first sentence reflects a historical view for many organisations. In a world with long-lived stable product teams, the statement “necessary and sufficient to complete a project” is like travelling back in time. Adding “…or a release” is even more anachronistic these days. Unless you’ve been hiding under a rock Continuous Integration and Continuous Delivery makes thinking in “releases” very much an outdated concept. It goes on to say:

“The backlog is the primary point of entry for knowledge about requirements, and the single authoritative source defining the work to be done.”

Where the Agile Alliance does get it right is that the Backlog is the “primary point of entry”, and “the single authoritative source” and that the Backlog contains a list of “things” which the team themselves should be maintaining.

So, let me suggest a rewrite of the Agile Alliance definition, you know, updated for this decade…

A backlog is a dynamic list of potentially valuable options which the team maintains. The currently shared view of the priority order of options should be visible, at least to the team, but also to stakeholders. The backlog, however, is emphatically NOT a commitment.

The priority order should be allowed – encouraged even– to change as the team learns about where the value is, how that value is leaking away over time, and how big and complex the items on the list are likely to be. In this way, the priority order should be dynamic, not static or fixed.

The items on the backlog should vary in size and shape, with the most likely items to be worked on next having been broken down with just enough detail for the team to start work on them – and this should only be done “just-in-time” for the team to work on them.

Lastly, the backlog should be treated as a “safe waiting place” and it should be cheap and fast for potentially valuable ideas to flow to the backlog.”

Why use a Backlog?

The above definition should give you a few hints about this. At its heart though, the Backlog is necessary in Product Development because our capacity to develop is limited, but the things we could use that capacity for is unlimited. These two things will never be in balance. In economic terms, there is a supply and demand imbalance. Believe it or not, this is healthy! A product with a fixed set of ideas about how you might improve it is either dying, or it is sorely lacking in feedback. As a result, our Product Development system needs a safe waiting place.

The other thing to recognise is that new ideas arrive randomly. The most valuable changes you could make could pop into your (or others) head at any time. So a Backlog that is static or fixed is likely to miss out on or at least delay those opportunities. Crucially, the arrival of good ideas is highly unlikely to align with the usual quarterly or annual planning processes. For this reason, the Backlog should act as a way for those late-arriving, really high cost of delay ideas to flow to – without disrupting whatever the team are trying to focus on today.

We often hear people say that the most important word in a Product Manager’s vocabulary is “No.” In our view, this is mostly a distraction. Much better to worry less about saying “No” and instead, try saying “Not yet” – quickly and cheaply placing it some way down the list. And who knows – maybe you’re wrong? Isn’t it possible that you’ll learn something down the road that changes your mind? Instead, make it super fast and really cheap to capture an idea, surfacing assumptions about value and urgency. Then, focus energy on speeding up the fuzzy front end and don’t waste your time trying to say no. Just let the less valuable and urgent options wither and die. As long as there isn’t some activity happening (which there shouldn’t be!) it costs us almost nothing to simply store them.

The other reason not to worry about saying no too much is that you risk someone maintaining their wishlist elsewhere. Going back to the Agile Alliance definition above, what we want is the “single authoritative source”. Without a backlog you may well end up with three or four different lists hidden away somewhere.

One other things that we often hear about: a long backlog is not a bad thing. It tells us that there is plenty of scope to improve a product. Doesn’t at all mean you have to do them all – of course not. A periodic archiving of things that haven’t been pulled into development over the last 13 months gives something a little over a year for any annually recurring issues that might crop up. It costs almost zero to archive. If you need some storage, one of my clients makes extremely large hard drives that they would be willing to sell to you.

#NoBacklogs

Whilst I completely understand much of the angst that the above hashtag is based on, it’s not a very well thought through proposition to just abandon the Backlog. Baby and bathwater. More in this thread for those interested in the more esoteric avenues of this discussion:

Potential problems?

By far the biggest problem we typically observe in how Backlogs are used is when items on the backlog are treated as some sort of commitment. Avoid this at all costs. Be careful not to make promises about when items on a backlog will be done. As a Product Manager, you absolutely should be able to provide a Forecast – but always be super careful to make it clear that the forecast assumes a whole bunch of things, the biggest of which is that nothing changes. That’s rarely true. If stakeholders are uncomfortable with that, they either need some training, or they perhaps they’re just not cut out for the inherent uncertainties involved Product Development.

Second biggest problem is probably the big batch transfer of “requirements” into a backlog. A close cousin of this is the insistence that the whole backlog has to be broken down and refined for delivery. That would be very much premature. Again, avoid!

As mentioned above, don’t be tempted into thinking that everything on the Backlog needs to be refined or groomed to perfection. This comes in two forms: 1) over processing so that everything on the backlog is broken down into nice small “goldilocks” (not too big, not too small) things to be developed. Instead the items on the backlog should be well-refined, and goldilocks sized toward the top, but no more than 1-2 weeks worth of work should be like that. To help distinguish, it sometimes helps to shift items that have been refined like this to a small “buffer”, which is distinct from the Backlog. This is somewhat akin to Scrum’s “Sprint Backlog”, as distinct from the “Product Backlog”.

The second type of overprocessing you often see is the refining, grooming and polishing of items on the backlog to within an inch of their life. If the only discovery left downstream of the backlog is whether the team can copy and paste effectively, you may have gone a little too far. Of course, a team under pressure is likely to complain that “stories aren’t ready!”. The solution there is to lower their WIP and remove any pressure to “deliver” according to some pre-planned velocity figures. (I really wish Velocity would die.) Leave room for the team to collaborate and figure out together the details. It also means you avoid wasted analysis on items that end up either waiting for some time (where the analysis goes stale) or that end up slipping down the list of priorities and not getting developed at all.

I’m probably missing a whole bunch here. I’ll add them in as I spot them – or ping me (twitter is good for that) with suggestions!

References:

How to tilt the innovation playing field

Single Prioritised Backlog – chat with John Cutler

Want more?

If you’re interested in learning more about Backlogs, and a bunch of other essential tools for Product Managers, check out our Product Management training here! If you want to learn more about how to improve prioritisation, make better trade-off decisions and change the focus of conversation in your organisation, we also offer training in Cost of Delay and CD3.