Sunday, March 27, 2011

Using Cost of Delay Functions to Prioritize Product Delivery

Cost of Delay

In many "agile" projects I’ve been a part of my strategy was to break off specific functions / use case / stories / whatever and delivery them mostly whole one piece at a time. IE in iteration 1 go deliver order entry functionality, in iteration 2 go deliver product fulfillment.

Typical Iterative Approach
While this approach help keep delivery efficient by breaking up work into smaller units, it does nothing to help business agility. When delivery a product an agile approach is to look at the product from a truly incremental perspective. What is the minimum that one can deliver right now that would meet some basic objectives of the product, what are the next set that would make the product a little better, and so on until I get that ideal product, one releasable piece at a time.
photo 5
Using this approach means it’s not enough for teams to develop code each iterations that is production worthy. Rather the entire organization needs to think about releasing products to the market in increments.

For this to work the business needs to train them selves to stop asking if they can get the world a year from now, but if they can get a small piece of the world next week.

A colleague of mine, Alexis Hui came up with a very innovative way to manage this approach on a project that we were running. The approach was to extend our Kanban board with a capability and theme map, illustrated below.

Theme Oriented Map
The whiteboard was divided into sections based on major capabilities that the product had to meet. Capabilities were further broken up into major project themes that has numerous theme "attributes". Each attribute could be thought up as a feature that could be revisited numerous times over the lifecyle of the project. Each time the attribute required new work a story would be tagged with the theme and attribute.

As an example the provisioning handset capability might have a theme for voice mail that had an attribute for activation and one for de-activation. An initial story would describe the work necessary to provision voice mail on a cell phone with a very simple set of features, a later story would describe fancier features like visual voice mail.

Each theme/attribute set would act as a persistent queue, where stories could be placed.

We then used a concept known as a Cost of Delay Function to prioritize stories. Think of a Cost Of Delay Function as a simple way to profile the impact of not doing a story on the business, or in this case the project. COD, also known as Opportunity Cost, is often graphed as a line showing the relationship between impact vs time, the steeper the angle of the line, the worse the impact is over time. COD can represent financial, political, moral, or other impact that could adversely impact the organization.

While it can be very hard for an organization to know the exact impact over time for not doing a particular work item, one is frequently able to allocate the COD into a broad category or profile. When using COD I recommend using color, or annotations to tag work on a Kanban board to identify it’s COD profile.

Cost of Delay
Because our project was all about launching a new product, we decided to base our COD profiles loosely on market risk.

Orange tickets represented work items that were necessary to launch the most basic version of the product, the COD on this is represented as a straight vertical line. If we did not deliver these by the target date of the first release then the project would be deemed a failure. These were necessary to enter the market.

Beige tickets represented a second pass at the orange tickets, taking mostly manual bare boned functions and automating them, adding better error handling, and other work to make sure that a fully operational product would support more than a limited pilot. This COD was illustrated as an incremental line starting right way, we were losing money everyday these weren’t implemented, and things would get worse the longer they weren’t delivered. These tickets were necessary to support market growth.

Green tickets represented high end features like customer self care, power tools, customizations features, and market grabbing functions such as keeping a phone number when transferring to the new plan. COD here was illustrated much like the beige tickets, but with a delay before incurring losses, and a more pronounced curve on the line, we didn’t need these features right away, but they were quite valuable later on. These tickets were necessary to steal market share from competitors.

Blue tickets represented longer term investments. Completing a blue ticket did not result in a noticeable business impact. Rather work quality would improve. Architecture work, educating the team on agile practices, refactoring, technical docs, were all profiled as blue tickets. These tickets had a straight horizontal line with a slight upward slope to it, immediate value was not obvious to the business, but not doing them would result in downstream pain. These tickets were necessary to ensure that the IT team could continue to support other market needs at a reasonable pace and price.
Theme Oriented Map 2
The above diagrams shows stories colored by COD. One can easily see which capabilities are more critical to earlier stages of development, and which ones should be done later. It should be noted that prioritization is not as simple as choosing one color, than choosing another, than another. Different business and different projects will choose a different allocation of COD profile tickets depending upon where they are in the product life cycle.

COD allocations are also dependent on the nature of the business they are in, for example start ups will likely face more extinction level events than blue chips, and have more "warm" colored tickets in flight to respond to these events.

It was typical using this approach to revisit an attribute several times. The first story for an attribute may be a blue ticket involving a spike, POC, or actual design. Subsequent stories for the attribute could involve one more orange and beige tickets, depending on the desire for a mostly manual solution or full automation of a component out of the gate. Later stories would often be a series of blue and green tickets necessary to POC new technologies and implement new functionality necessary to support some high end feature.

The one common theme here is that the simple use of color can be used to convey an awful lot of information with deep meaning to the business, helping delivery support real agility.


  1. Jeff,

    Excellent post.

    If the Kanban card contains a target date, to what extent that will implement CoD?


  2. Sameh,

    Thanks! A fixed date would most likely correspond to a COD that is very steep, or even straight vertical line, oe severe impact when the date was missed.

  3. Hello Jeff,

    Your post is very interesting! I've translated it into french : Priorisation des Fonctionnalités par le Coût du Retard


  4. I just checked it out,

    C'est magnifique, merci pour votre travaile!

  5. I think the idea of explicitly saying you'll revisit a feature multiple times is great, since that tends to happen anyway. So how do you use these "persistent queues"? Do you decide which story to pull onto your kanban board from among any of the stories at the top of any attribute queue? Can you give a few more examples of what you'd call a Capability vs Theme vs Attribute (say you're writing a job board, like the example here)?

  6. The theme map wasn't used for FIFO style prioritization, stKeholders had to make intelligent decisions about how to get basic or advanced features across the various themselves and capabilities. Coloring of COD, he led with what was taken from the map and placed into the queue.

    An examp,e of the theme might be order entry for a wireless device, and attribute might be Web Based Order Entry. a story would be the basic capability, then a collection of advanced stories like better back end integration with am order service, and finally premium market grabbing stories like porting numbers from in while ordering

  7. Do you have a picture of this concept in action on a live project? That would be very useful for us to see. Alistair