Plenty of Agile teams treat their backlogs as either a first-in-first-out (FIFO) queue, or perhaps a priority queue ordered by the expected revenue of each individual project. It turns out that neither approach is based on sound economics.

Donald Reinertsen knows this, and I won’t attempt to summarise the incredible wealth of valuable insights in his book on the topic. Instead, here’s a short example to illustrate one of the simplest ways teams often get their scheduling wrong: by failing to account for the cost of delay for each project.

Suppose a team is asked to deliver projects A and B, and the cost-benefit suggests that:

• Project A will take 1 month to implement (if the whole team works on it), and the ROI will be $2k per month the project is live for.
• Project B will take 2 months to implement (if the whole team works on it), and the ROI will be $3k per month the project is live for. Here are our options for scheduling the work.

Scenario 1: Prioritise by Revenue

We’ve determined that project B will produce the greatest monthly revenue, so we decide to deliver that first. Here’s a graph showing the total value added over the four month period from when development starts:

The team takes 2 months to deliver B, which then contributes $3k over the following month. Then A is delivered, contributing (with B) a combined $5k over the fourth month. The area under the graph in green shows the aggregate value added over the total time period: a very respectable $8k of added value. Great!

Scenario 2: Schedule according to Economics

Didn’t we already schedule according to economics with our revenue heuristic? Kind of, but there’s another important consideration: the cost of delay. Let’s try delivering the projects in a different order to see what happens:

In this scenario, the team delivers less value at first, but delivers it sooner. Thus, the total value over the timeframe is $9k, which is greater than in scenario 1. This is the correct order to maximise value: the cost of delaying project A (in terms of foregone revenue) is greater than the value of delivering project B sooner.

Scenario 3: Prioritise All The Things

Sometimes management does this:

Both projects are seen as strategic priorities, so the team endeavours to deliver both. But this means that each takes longer, as the team’s time is divided. Here’s what happens:

The team works on both projects for 3 months, delivering both together – which yields approximately half as much value ($5k) as scenario 2 over the same timeframe.

Indeed, the overheads of managing multiple work streams simultaneously will likely be such that the team delivers even less than this. In short: don’t do this.

Minimise the Cost of Delay

It should be clear, but it’s worth highlighting: in each of these three scenarios the team did precisely the same amount of work, but the value added varied substantially. This is why scheduling work according to not only revenue, but also the cost of delay, is incredibly important if you want to maximise the value your team is adding.