Using Cost of Delay Functions to Prioritize Product Delivery

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.

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.

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.


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.


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.

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.