Single Prioritised Backlog – chat with John Cutler

Had an interesting conversation with John Cutler yesterday to discuss the idea of having a single prioritised Backlog for an organisation.

The genesis for the chat came from a tweet that John posted, to which I responded:

So, we had a nice chat to discuss this – and a bunch of related topics…

Our takeaway/summary in a single tweet:

Some notes I made:

Q: What problems might a single prioritised backlog improve?

Q: What problems might a single prioritised backlog make worse? Unintended consequences.

Q: What alternatives exist that address the former with less of the latter?

Why might you choose a Single Prioritised Backlog?

Works well in single product, small orgs. Where any team can work on anything.

Why might you not choose a Single Prioritised Backlog?

All prioritisation is local!
Disenfranchisement of teams that aren’t working on one of the top 3-5? Not important? Not valued?
In larger orgs, or with complex customer problems and customer bases, a single prioritised list doesn’t work well.
e.g. booking vs disrupts? Both!
Creates false dichotomies, sometimes it’s both.
From my experience using CD3, some of the most valuable things are small. Tiny even.
And: some of the most valuable things don’t come from Strategy.

What alternative is there, that might work better?

How can we get clarity, focus, alignment without the unintended consequences that in some contexts surface? Well, I would recommend more of a combination of a few things:

  1. Quantify the Cost of Delay at the Outcome level, especially for strategic initiatives. (If you really can’t quantify the value and urgency of the outcome, maybe it’s not as urgent or valuable as you think?) Whether you present those in an “ordered list” or not doesn’t really matter, since you have no sense of what it takes to achieve those outcomes yet!
  2. Allow each team to figure out how they might contribute toward one or more of those high-level outcomes. This might be a set of features, small experiments, stories or small changes. Product Manager and team together figure out a rough idea of what the % contribution for each of those might be. You could use this Qualitative Cost of Delay approach for this, but I’d still recommend you tie it back to a rough % contribution of the Outcome – that way you have the numerator of CD3.
  3. Have the teams do a rough T-shirt size or relative estimate of how long each of the the various options is likely to block the pipeline for. If they’re all roughly the same size then doing this step doesn’t harm anything! Take the Cost of Delay % and divide by the duration and you have a CD3 ranking that makes sense at the local level, but is still clearly connected to the higher-level Outcomes and their Cost of Delay.

Using this approach, each team can be focused on their own CD3-ranked outcomes that suits their skills and capabilities. If there’s tonnes of dependencies, then try to break those where possible, or at least surface them as part of a regular (say quarterly) lookahead, where you get all the teams in a room together AKA, Big Room Planning.

There’s still an important role for the Product Manager to ensure alignment across the org, but the crux of this approach is that you are transmitting the information to make better decisions at the level where those tradeoffs and prioritisation decisions are actually being made, day in day out.

As for mixing in the Technical Debt prioritisation decisions, at the end of the day, I’d leave that up to the team, with appropriate monitoring and visualisation of problems as they arise.

Ultimately, technical debt tends to manifest as elongating cycletimes. Shortening cycletimes and in particular speeding the speed and SNR of various nested feedback loops should be something that every team is looking after. (This is what I was droning on about when we started talking about retrospectives, and giving teams clear direction around three principles and related measures that they own as a team.

© 2022, Written with ❤️ and built with Gatsby by J