Order out of Chaos

Putting your Product Backlog in order – what should you work on first?

Suppose you’re a Product Owner and you have a few items in your Product Backlog. How would you advise the Development Team on what to start working on first? Should you even care at all? What difference would it make if you were a bit deliberate about the order in which work items get tackled?

The tale of the two leaky barrels

To explore answers to these questions, let’s consider the story of two leaky barrels. Imagine we run a bar and have two troublesome barrels. One holds whisky, the other holds beer. Both are leaking right now, losing us money. Every minute that passes, we loose about $50 worth of whisky and $10 worth of beer.

Based on this information, which one should we fix first? A natural impulse would be to start working on the whiskey barrel. After all, we’re losing five times as much money each minute from it. So far, so good.

Imagine that we resist that temptation briefly enough to get curious about how long it would take to repair the barrels. Let’s further suppose that our investigation turns out that it would take a minute to fix the beer barrel and about ten minutes to fix the whiskey barrel. Armed with this new information, is it still a safe bet to fix the whiskey barrel first? Oops. Not so much anymore.

Sure, in the minute we’d take to fix the beer barrel, we’d lose $50 worth of whiskey. But if we took the ten minutes to fix the whiskey barrel, we’d lose $100 worth of beer. Ouch.

Cost of Delay or Speed to Value?

We can think of the $10/minute beer loss as a cost of delay (see Don Reinertsen’s work). Seen from this perspective, it shows us how much would it cost us if we delay the repair by a minute. However, we can also think of it as a speed to value. In this interpretation, if it took a minute to achieve, we’d get a $50 value saving from the whisky barrel and just $10 from the beer one.

Thinking of it as a speed to value has another benefit. In physics, when we divide speed by time we get acceleration. Therefore, when we divide the speed to value by the duration estimate, we end up with acceleration to value. In our example, $10/minute divided by 1 minute gives us a value of 10, whereas the whisky $50/minute divided by 10 gives us a value of 5. The higher value for the acceleration to value is a simple and reliable indicator that that initiative should be undertaken first. In my experience, thinking of acceleration to value is a lot easier to wrap your mind around than "Cost of Delay Divided by Duration" (or CD3 as it's sometimes referred to).

In this manner, you can develop a cunning practice of ordering your Product Backlog in such a way as to maximise the acceleration to value. Items with the highest acceleration to value would be worked on first.

The Scientific Method to the rescue!

This economic assessment is equivalent to using the scientific method: making a theory, running some experiments, assessing the results, then improving the theory. First, we make a theory of which items are most important to work on – the value model, speed to value and acceleration to value concepts are elements of this theory. Then, we run some experiments by creating items in the order suggested by the theory, and assess the outcomes. Based on the findings, we can then decide to continue to use our theory as-is, or adjust its elements to improve its predictive ability.

It’s conceivable that in some cases dependencies across items may sometimes drag items with smaller accelerations to value closer to the top of the backlog. However it would only happen if it enables the creation of an item with acceleration higher than everything else.

The Quality of Order - What's "good enough"?

The quality of the order of the items in the backlog is driven by the accuracy of the value model used to determine speed to value. The result is further influenced by the accuracy of the effort estimates. Overall, it’s good to remember you don’t need a “perfect” model. You just need something “good enough” to give you a promising order to experiment with. Having a system to create and assess value is far more effective than just random decisions.

The overall intention is to figure out how soon it’s a good idea to stop. Your development team will have a known burn rate.  You’ll want to stop work on this product as soon as the value of the items you’re trying to build is lower than the cost of production over the same duration.