Skip to main content

Selecting Backlog Items By Cost of Delay

Selecting the right items for an agile project to work on next is vital to ensure your team is delivering the maximum value possible to the business. Rather than "MoSCoW" (see recent post) or similar prioritisation schemes, +David Anderson's Kanban book recommends using the opportunity-cost of delay as the way to decide which items to pull next (or which items to put into the next sprint if you're using Scrum). He suggests 4 archetypes for categorising what the cost of delay might look like, when the impact (opportunity cost) is plotted against the time of release:

Expedite items have a high and immediate cost of delay. They should be started at once and given priority over other items. Fixed date items have a high cost of delay once a threshold is passed. They should be started before there is a significant risk this date will not be met. Standard items' cost of delay follows a fairly shallow S-curve, in other words, there is no reason to expedite them - they should be handled normally. Intangible items apparently have no immediate cost of delay, though it is expected to rise at some more distant point in the future. Such items are useful background tasks to be handled when there are no more urgent tasks.

At a recent Kanban Masterclass I attended, David introduced an example to demonstrate the difference between Fixed Date Items and Standard Items:
A hotel/resort site wishes to offer two special promotions: one for the Spring/Easter holiday; one for Valentine's Day. Because people tend to book much later for Valentine's Day, the opportunity-cost of delay is likely to be much "steeper" - more like the Fixed Date case, compared to a more "Standard" shape for the other promotion.

This led to consideration of what the revenue projections for different release dates might be in these 2 cases, so I undertook to produce some sample data for discussion. Here they are.

The graph above shows the imagined additional sales generated by launching the Easter promotion on the dates shown. There's no point in launching before Christmas and New Year are over (zero cost of delay), so the first release date is January 1st. There's an initial bump when the first ads go out, then a growth in revenue, and in this case a rapid drop off when it is anticipated all places will be sold. Later releases follow a similar pattern but after 5 or 6 weeks' delay the cost in lost sales becomes much higher as sales go to the competition or simply have insufficient time to close.

The graph above plots the loss of revenue of the early February release (5 weeks delay) compared to 1st January release. Sales are always behind - even after the slight recovery in the period after the January release has sold-out.

Taking all the potential release dates and plotting the opportunity-cost for each delay produces the graph above - an S-curve showing little impact initially, rising more rapidly after the first couple of weeks.

Let's compare that with the simulated data for the Valentine's promotion.

In this case we are expecting nearly all the sales to be made in the last couple of weeks before the event. It really doesn't help to launch early because people won't book early any way!

So plotting the cost of delay in this case we get a curve which is much closer to the archetypal step function of the Fixed Date items. If there are items with higher opportunity cost of delay early on in the year, it is more beneficial to do these items, provided we don't miss the late January release for the Valentine's promotion, i.e. the point where the curve hits the "hockey stick" upwards.

Hopefully these examples help the understanding of the concept of using cost of delay for deciding which item an agile team should do next. Let us know if you have any real data examples to demonstrate this concept. I'd be most interested to hear about them.

Post a Comment

Popular posts from this blog

Does your Definition of Done allow known defects?

Is it just me or do you also find it odd that some teams have clauses like this in their definition of done (DoD)?
... the Story will contain defects of level 3 severity or less only ... Of course they don't mean you have to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "Done"if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.

Let's look at the consequences of this policy. 

Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in…

"Plan of Intent" and "Plan of Record"

Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many successful ventures and in a number of SIGs and conferences in which he is active. In spite of knowing Ron by correspondence over a long period of time it was only at JavaOne this year that we finally got together and I'm very glad we did.

Ron wrote to me after our meeting:

I told a number of people later at JavaOne, and even later that evening at the Software Engineering Management SIG, about xProcess. It really looks good. A question came up: It's a common technique in large organizations to keep a "Plan of Intent" and a "Plan of Record" - to have two project plans, one for the business partners and boss, one you actually execute to. Any support for that in xProcess?

Good question! Here's my reply...

There is support in xProcess for an arbitrary number of target levels through what we call (in the process definitions) P…

Understanding Cost of Delay and its Use in Kanban

Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - as is often the case - estimating it quantitatively may be difficult or even impossible. Analysing Cost of Delay (even if done qualitatively) is important because it focuses on the business value of work items and how that value changes over time. An understanding of Cost of Delay is essential if you want to maximise the flow of value to your customers.

Don Reinertsen in his book Flow [1] has shown that, if you want to deliver the maximum business value with a given size team, you give the highest priority, not to the most valuable work items in your "pool of ideas," not even to the most urgent items (those whose business value decays at the fastest rate), nor to your smallest items. Rather you should prioritise those items with the highest value of urgency (or CoD) divided by the time taken to implement them. Reinertsen called this appro…