Friday, May 12, 2017

Time is an Asset - Delay is a Cost

Cost of Delay is a vital concept for management teams to understand and use. It enables better decision-making concerning investments and cost-saving, and is the basis of a coherent economic framework for considering the trade-offs management are responsible for, when deciding for example, whether to focus on reducing cost, or on investments that might reduce costs or increase value in the future.

After over a year of blogging and conference presentations on the topic - much of which has focused on the technical rather than practical explanations - I want to draw these to a close here with some straightforward summaries for managers of agile teams. While I think most managers will benefit from looking more deeply at why this advice applies (and its limits based on the assumptions underlying it), I'm also clear that a summary of what to do is the most helpful.

My thinking has evolved over the year, since the preparation and publication of the Kanban guide to Kanban - Essential Kanban Condensed (downloadable here). I started this series of blogs in April 2016 to provide more details on the subject than was possible to include in the condensed guide, and since that time I've had the good fortune to discuss Cost of Delay in some depth with some key thinkers on the subject. For this I'm particularly grateful to Don Reinertsen, David Anderson, Joshua Arnold, Chris Matts and Dave Snowden, who have taken the time at various points this year to teach, cajole, contradict or endorse various things that I was saying. While it is certainly not possible to reconcile all the thoughts and published works of the authors who have used and modified Don Reinertsen's original work on the subject - it is now at least possible to summarise my own (interim) conclusions!

Firstly here is the list and links to each of the previous articles:

Part 1: Understanding Cost of Delay and its Use in Kanban
Part 2: 
Delay Cost and Urgency Profiles
Part 3: 
How to Calculate WSJF
Part 4: 
WSJF - Should you divide by Lead Time or Size?
Part 5: A "Qualitative" Formula for WSJF?

Part 6: Time is an Asset - Delay is a Cost (this article)

In this article I look first at some key terms we have used. I then ask, and hopefully answer, "why is Cost of Delay important?"; "can Cost of Delay be quantified?"; "when could we use WSJF?"; and finally "what next?".


Three useful terms...

Unfortunately there is not unanimity on terminology but these ones are important. The first 2 terms below follow Don Reinertsen's work. The third, a term Joshua Arnold used when correcting the dimensionality of SAFe's use of Cost of Delay, was discussed in the previous blog. (Other terms are introduced in the previous blogs and are available in the glossary of Essential Kanban Condensed.)

Cost of Delay (CoD) - the rate of decay of value per period of delay. Units for example could be dollars per week. Due to the confusion possible with the next term in this list, I frequently use Urgency (U) as a synonym for CoD.

Delay Cost - the total loss of value due to a delay of known duration. For example, "The release was delayed by 7 weeks, which resulted in a Delay Cost of $150,000".

Time Criticality - a relative measure of how quickly all the value of an item would be lost. Units are the reciprocal of time. Usually this is used as an informal and relative term. It is useful though to compare the concepts of Time Criticality (which is independent of value) with CoD/Urgency, which quantifies value lost per time. For example eating the lettuce approaching its use-by date in the fridge may have the same Time Criticality, but very different Urgency, compared to paying the final demand on the mortgage on the house!

Three useful graphs:

Benefit Profiles - these show the benefit accrual rate expected from a defined piece of work, plotted against date, for example net pre-tax profits expected per week. There is not unanimity concerning this term. David Anderson frequently refers to these plots as "adoption curves" since for product releases the benefit accrual rate follows the adoption of the product by customers. Joshua Arnold often calls these graphs "urgency profiles", which unfortunately clashes with the definition below. (Since the graphs do not actually reveal urgency - this can only be determined by comparing one benefit profile with a subsequent one incorporating a delay - I would discourage this usage.)

Delay Cost Profiles - these are plots of delay cost against the delay (or release date, if you prefer). The gradient (first derivative) of these curves shows the CoD or Urgency.

Urgency (or CoD) Profiles - these plots should how the Cost of Delay is expected to vary over time. Of particular importance is: where there is a spike in CoD (as for example occurs if there is an external deadline); or where there is a continuing change in CoD (as for example occurs when there is expected loss of market share as well as loss of earning period due to the delay); or where step changes occur (as happens at the start and end of expected earning periods).

See the first blog in this series for examples of these three types of graph.

Why is Cost of Delay Important?

Traditional business cases for new work use estimates of cost and benefit to derive Return on Investment (yield) and a pay-back schedule (duration). However the rate at which value is lost due to delays is not  taken into account. As a result we live with the consequences: arbitrary cost cutting by activity type (such as travel bans and contractor “holidays”), a failure to invest to reduce lead time, and an inability to trade-off cost for time. It also means the choice of initiatives undertaken, and the order they are implemented when they cannot or should not be carried out in parallel, is poorly informed. These discussions need accountants and software managers to share vocabulary (and goals)… and ultimately to evolve policies that improve outcomes. Cost of Delay needs to become part of the every day discussions of management.

Can Cost of Delay be Quantified?

My short answer to this is "yes, but it cannot be measured" (apologies to Don Hubbard, who I'm sure would correct my definition of measured and say yes it can). The point is that Cost of Delay is the difference between: something that cannot be measured until after the project has finished (life-time benefits for the work); and something that cannot be measured at all since it relates to something that will never occur (life-time benefits of the work if it had been released on a different date). Since we are estimating CoD it is worth having this in mind - not to prevent its use but to realise its limitations.

However, the estimates of CoD do not have to be perfect, they just have to be better than the alternative. That is why it is useful. The alternatives are very often even poorer quantifications or merely vague assertions.

One further word of caution. Don Reinertsen applied CoD to sizeable initiatives such as new product launches and significant projects. Applying the same technique (Weighted Shortest Job First, or WSJF) to small items such as "epics" or even user stories may be a stretch. The uncertainties involved in estimating value and the rate of loss of value, when considering the life-time benefits of these small items, are likely to result in inaccuracies that invalidate the results.

So when could we use WSJF

If you have read the preceding articles to this blog carefully, you will have noted a number of key assumptions that relate to the validity of the WSJF formula (Cost of Delay Divided by Duration, or CD3). Some of these make WSJF inapplicable for some processes. An example might be where, by continual monitoring of expected delivery dates against the delay cost profile, we can readily and dynamically reorder work schedules to preserve maximum value-delivery. Balancing the right types of work and managing risk by monitoring "last responsible moments" is a way of using CoD without using the WSJF formula, which does not account for variable CoD. Other aspects (such as difficulty in predicting value realization) make the technique inapplicable at smaller scales (for example small work items).

Another aspect which affects the applicability of WSJF, is the nature of the domain where we are seeking to order work. Chris Matts has certainly influenced my thinking in this area. Referencing Dave Snowden's Cynefin model, Chris points out that in "complex" domains results are not predictable or plannable. Safe-to-fail experiments lead to better outcomes than pre-planned actions (though not necessarily the "best" outcome, which is unknowable in such domains). So rather than preceding delivery with long periods of analysis and estimation, it is better to deliver smaller items and then choose subsequent items based on customer outcomes. This is an important observation, and coincides of course with many other ways of looking at the problem. Reducing the size of value-bearing work items, and reducing the lead times, so that feedback and response can happen quickly, is the right way to proceed in such domains. To summarise this advice with regards WSJF - don't use it in complex (or unplannable) domains! This just not just applicable to WSJF of course. If you are doing lots of up front planning any way, maybe your domain is not "complex" in this sense - or maybe you should question other practices as well!

So when can we use WSJF? Well not all domains are "unplannable", even domains where continuous feedback and adjustment are required. Not all work items are so small that estimating value and the decay of value is futile or too time-consuming. The most obvious place to look is where Don Reinertsen originally proposed the technique. For sequencing larger plannable items, which due to resource constraints or other reasons, follow each other in sequence. Not only is the WSJF formula useful in such discussions, it provides a means to discuss and manage portfolios of work using financial criteria that our accountants can understand and validate. We need accountants to be involved in this discussion, not least because it the surest way to move management decision making in the direction of greater business agility.

Where next?

WSJF of course is only one aspect of the application of Cost of Delay. The wider use of Cost of Delay in business, including the involvement of accountants in developing sound ways to apply its quantification, will in the end result in better business decisions and improved value delivery. While the minutiae of formulae and assumption validity, and the difficulty of estimating value-delivery and its decay, are certainly roadblocks in improving our understanding and good business practice in this area, the stakes are too high not to persevere towards robust solutions.

If you have persevered through the machinations of this series of blogs, I thank you - and look forward to hearing your feedback and experience reports. The next generation of managers needs clearer explanations of these concepts so they become as well understood as pre-tax profits and balance sheets in driving correct business actions. Accountants and agile managers need to join together to develop the mechanisms and standards that will augment current accounting practice and produce the environment for better business decision making.

Thursday, January 05, 2017

A "Qualitative" Formula for WSJF?

In this series of blogs we have been examining the use of Cost of Delay as a way of understanding ordering work - either from a quantitative approach using estimates for value, urgency, duration and/or size, or from a qualitative approach, such as the use of Delay Cost Profiles [1], Risk Profiles [2,3] or Value Size matrices [4]. The SAFe definition of WSJF is something of a hybrid, since it uses a formula, but a formula that has only "qualitative" value at best. Here is their definition [5]:

The 4 terms are determined by Planning Poker estimation using a Fibonacci scale (usually 1 to 20). The work items are ordered according to the formula following an estimation workshop. While this formula cannot provide a true quantitative analysis for ordering items to maximise value, some consultants using it have said that is a useful technique for the discussion it engenders among stakeholders. Once the numbers have been generated the items ordered, re-ordering to a better order is straightforward because of all the discussion that has preceded this point. Needless to say, I strongly disagree with this. While the discussion is necessary for a quantitative or qualitative approach, creating a spurious anchor from numbers which cannot be meaningful will lead to cognitive bias rather than better ordering.

Why can't the above formula provide meaningful answers? For 2 reasons:
  1. Dimensionally the formula is inconsistent
  2. The terms are not estimated on a proportional scale
These problems were addressed in Joshua Arnold's proposed modification to the formula [4] which rearranged the terms as follows:

"WSJF" = Time Criticality x (User-Business Value + Risk Reduction | Opportunity Enablement) / Size

Dimensionality is addressed, subject to the following assumptions:
  1. Time Criticality, τ, has units of the reciprocal of time (e.g. days-1). In other words an option expiring in 2 months would have double the τ of one expiring in 4 months.
  2. User-Business Value and Risk Reduction | Opportunity Enablement are measured in consistent units, possibly using a weighting factor to translate the intangible values to the units of the tangible values
  3. Size is proportional to the blocking time caused by implementing the item. This term may in such a case be used as a proxy for duration measured in units of time. This issue has been addressed in this series here: WSJF - Should you divide by Lead Time or Size? which also identifies additional assumptions required for this to be true.
  4. WSJF itself is used consistently with its intended dimensions, which are value/time2
Proportionality must also be addressed. The scale used in estimating must be proportional (including 0 and not limiting maximum range) not just ordinal as would occur if the items with minimum and maximum value are set at say 1 and 20 respectively. The use of a weighting term to ensure the tangible and intangible business value terms are appropriately scaled relative to each other which is also required for proportionality.

The modified SAFe formula suggests a more general expression for WSJF using the weighting factors for a set of "business value types", v, and "exchange rates" that convert the values to a common "currency" of value:

WSJF = τΣ(vn Xn) / D

τ (tau) is time criticality, vn is the nth business value, Xn is the exchange rate for this business value type, D is duration, for which Size may be a proxy subject to the assumptions discussed above.

This blog has not addressed the issue of when quantitative or qualitative approaches should be used. As well as having formulae that are coherent, the work of estimating to provide numbers for the formulae must be worthwhile and comprehensible to the business doing such estimation. In many cases it is not - for example where the domain or context in inherently "non-plannable". The concept of cost of delay is still important, but we should for different techniques for ordering work. Further discussion of this must wait for the next article in the series.

Previous blogs:

Part 1: Understanding Cost of Delay and its Use in Kanban 
Part 2: 
Delay Cost and Urgency Profiles
Part 3: 
How to Calculate WSJF
Part 4: 
WSJF - Should you divide by Lead Time or Size?
Part 5: A "Qualitative" Formula for WSJF? (this article)

Part 6: Time is an Asset - Delay is a Cost


[1] David J. Anderson and Andy Carmichael, Essential Kanban Condensed. (United States: Lean Kanban University Press. 2016)
[2] Anderson, David. 2015. ESP: Scaling the benefits of Kanban. Slides 45-49. April 23. (January 5, 2017).
[3] Sharvari, Sawant. 2016. "SwiftKanban help - risk module.". 5, 2017).
[4] Magennis, Troy. 2016. Better Backlog Prioritization (from random to lifetime cost of delay).
[5] Agile, Scaled. 2016. "WSJF – scaled agile framework.". wsjf/ (January 5, 2017).

Friday, April 29, 2016

WSJF - Should you divide by Lead Time or Size?

Understanding Cost of Delay (Part 4): WSJF - the "divisor"

This article is the fourth in a series of blogs on Cost of Delay (CoD) and Weighted Shortest Job First (WSJF).

Note: terms in boldface are defined in the Glossary of  Essential Kanban Condensed which is available here. To get the background to this piece check out these previous posts:
Part 1: Understanding Cost of Delay and its Use in Kanban
Part 2: 
Delay Cost and Urgency Profiles
Part 3: 
How to Calculate WSJF
Part 4: 
WSJF - Should you divide by Lead Time or Size? (this article)
Part 5: A "Qualitative" Formula for WSJF?

Part 6: Time is an Asset - Delay is a Cost
In Part 3 we established why the factor used for prioritising work items is urgency divided by the development delay (U/D). The item to be done first should have the highest value for this term (sometimes referred to as the "wisjif" or CD3). Urgency is the rate of decay of the business value (the Delay Cost per week) and we must estimate both the business value and Delay Cost Profile to derive this. In this post however we focus on the other variable. What is the appropriate value to use for D?

OK I'm going to tell you my conclusion before looking at why. It's a surprising conclusion (at least for me). My conclusion is that you should use "size", or a proxy for size like the estimated number of "user stories" in the work item, rather that the period of time before the item is released (Customer Lead Time). Mmm... if that's surprising to you (or if you've no idea why it might be surprising) read on!

Why use "size" rather than Customer Lead Time in WSJF?

To me the "first-glance" obvious answer to the question "What is D?" is Customer Lead Time. The business value is not realised until the item is delivered and "live". So the delay we are talking about is the time from the decision to implement (known as the commitment point in Kanban) to the release date; in other words, the Customer Lead Time. Some people have suggested that an estimate of the "size" of the item in some units (such as number of stories or story points) is an effective proxy for Lead Time. In fact it is a very poor proxy for this. (See for example Ian Carroll's blog [6] looking at correlation between size and Lead Time. The correlation is very weak, possibly non-existent.) The reason for this is low Flow Efficiency - the ratio of time working on an item to elapsed time. If Flow Efficiency is in single figures (typical for many teams) it is not surprising that size does not correlate well with Lead Time. Therefore we can't use size as a proxy for Lead Time. So why did I conclude that size is the correct divisor for wisjif?

Let's go back to the derivation of WSJF in the previous article (How to Calculate WSJF). The assumptions we used were that: the urgency was constant over the period of interest; and importantly, that the team's WiP limit was 1. Basically we assumed the second feature had to wait until the first feature had been delivered before we started on the next feature. In these circumstances the delay, is equal to Customer Lead Time - both for the wait until benefit occurs and for how long the previous item holds up the product team before it can start the next item. In reality these are two different wait times - provided that the WiP limit is allowed to be greater than one. The delay before benefit occurs is still the Customer Lead Time (let's call this T), but the team is held up by less that the Customer Lead Time - they can work on another work item while the first item is held up by a blocker or waiting for release. This is a much more realistic assumption than WiP=1 provided what we are talking about is a product feature, not a project.

This change in assumption changes the equation for the value realised by implementing item 1 followed by item 2. In the previous article we found this to be:

Now we are considering that the time during which the team is held up, is a different and shorter time than the time before the value is realised. Let's say the teams working on this product have capacity to deliver "stories" at an average rate of C stories per week. and that the estimated number of stories in the two work items are sand s2

So the amount of time that the second item is held up by the first item is s1/C. The rest of the Customer Lead Time, T, is waiting time - let's call that w. So...
The value realised from item 1 followed by item 2 is now seen to be:
Again subtracting this same formula with the order of the items reversed (and seeing most of the terms cancel out), gives us the difference in value between the alternative orderings, as:
We can see from this formula that it is the term urgency divided by size for the 2 items (U/s) that determines which order is best. We do not need estimates of lead times for the items to find the optimum order for the work items.

See important note on assumptions below.

What if the "urgency" is not a constant?

What about the other important assumption in the simple WSJF formula - that the Urgency (Delay Cost per week) is a constant? In general, Urgency is not constant for work items over the whole period that there is still value in implementing them. However this does not matter if the Urgency is constant during the period that the competing items to be ordered will be implemented. In this case we can just go ahead and use the formula. 

For "Fixed Date" items the formula is not appropriate. The determinant for when Fixed Date items should be started is the "last responsible moment", taking into account uncertainty in Customer Lead Time, and the degree of risk that is acceptable to the customer. The determinant for whether Fixed Date items should be started is the total value of the item, compared with the loss of value that occurs by delaying the next highest item to be prioritised. Usually we can just start Expedite items immediately and Fixed Date items before the last responsible moment without the need for estimation or calculation, making WSJF important only for the ordering of Standard items. 

Intangible items would not be selected at all if we only applied the WSJF formula, since their immediate urgency is low. Nevertheless it is helpful to always include some Intangible items in the schedule for flexibility (if customer SLAa are threatened), and for preparation for future events. Policies around the use of Intangible items can be tuned to the business context and strategy.

In the next blog in this series we will consider some conclusions from this analysis of Cost of Delay and WSJF. Why is it important? When is it applicable? What to do when it is not applicable or not calculable?

Important Note on Assumptions (continuous delivery or batch)

The algebra above assumes that the waiting time part of the delay (w) does not vary for a given work item, regardless of whether it is implemented before or after another item. This is probably a reasonable assumption if these are "features" which are released as soon as they are completed, in some kind of continuous delivery process. If a batch delivery process is used (e.g. a release every 2 months), the delay is identical for features in the same batch. It would be wasteful to use WSJF for features within the same batch. The issue is which batch the feature is put in and this analysis probably needs to be more sophisticated (or simply qualitative rather than quantitative - see for example [7]) - to ensure items are in the right batch.

Wednesday, April 27, 2016

How to calculate WSJF

Understanding Cost of Delay (Part 3): Calculating WSJF

In part one of this series of blogs on Understanding Cost of Delay and its Use in Kanban, we considered the meaning and difference between Delay Cost and Urgency (or Cost of Delay). In part two we looked at different Delay Cost and Urgency Profiles and the archetypes defined in Kanban for classifying work items by these profiles. Now we look at the prioritisation/ordering technique know as Weighted Shortest Job First (WSJF): the formula, the assumptions behind it and how the formula arises. WSJF brings the primacy of time into decision making about which item to implement and when.

Consider a product development team. They have many ideas for what to add or change in the product, and for improving the way they work. The question is, which of these many useful things should be done first. It turns out the that the total business value of a proposal is not the the deciding factor in maximising the business value a team can deliver in a given period; nor is it urgency of the proposal (the Delay Cost per unit of time). The deciding factor is the urgency divided by duration of implementation, a term sometimes referred to as the WSJF (or "wisjif") of the item.

To see why let's consider 2 work items with a total cumulative value of V, a duration of D, and an urgency of U. Suffices will indicate which of the 2 work items is being referred to. Assuming the WiP limit in our team is 1 (so the team does only 1 feature at a time), and assuming the urgency, U, is a constant over the period of interest, the estimated value realized by the 2 features will be:
Total value arising from implementing Item 1 followed by Item 2
For more information see Essential Kanban Condensed
This is the net present value of the two items less each item's delay cost. In the case of the first item, the delay is just its own duration, but in the case of the second item, it must wait for the first item as well. If we want to know whether it is better to do item 1 first or item 2, we need to know which has the higher urgency (Delay Cost per time period). We can visualise the delay cost like this... it is the total area in these graphs.
Feature 1 then Feature 2

Feature 2 then Feature 1

Switching the terms over in the formula above, and subtracting, gives us the difference in value realised by changing the order. Most of the terms cancel out, but we are left with the following, for the addition benefit (cost if negative) of doing item 1 before item 2.
This gives us the basis of WSJF. To maximise business value delivered by the team, we should prioritise the items which have a highest value for urgency divided by duration. The "wisjif" term may thus be expressed as:

WSJF = U / D

In the next article in this series we will look at whether the duration used in this formula should be Customer Lead Time, System Lead Time or something else. we will also consider the assumptions behind the WSJF formula. This will lead us to suggest how the formulae can be used in practice, in conjunction with delay cost profiles for different categories of items.

Read part 4 now: WSJF - Should you divide by Lead Time or by Size?

Back to part 1: Understanding Cost of Delay and its Use in Kanban

Monday, April 25, 2016

Delay Cost and Urgency Profiles

Understanding Cost of Delay (Part 2): Delay Cost and Urgency Profiles

In part one of this series of blogs on Understanding Cost of Delay and its Use in Kanban we explored how - from understanding the business benefit that is likely to occur following the decision to implement a proposal now or later - we can derive 
Value Flow, Cumulative Value, Delay Cost
 and Urgency for time-sensitive feature
(click on image for more detail)
  1. the value flow (net benefits, positive and negative) each week through the useful life of the proposal, for a given release date
  2. the change in cumulative value (Net Present Value, NPV, or life-time profits) as a  function of time, for a given release date
  3. the Delay Cost Profile - how much business value is lost as a function of the delay 
  4. the Urgency Profile (the rate at which value is lost as a function of the delay)
Note: The terms Cost of Delay (CoD), Class of ServiceDelay Cost, Lead Time, NPVwork item and Urgency, as well as over 60 commonly used terms in Kanban and Lean are defined in the Kanban Glossary in Essential Kanban Condensed [2] (currently available as a free download).

For the type of work item that was considered in part 1 (a product feature in a time-limited competitive market), the four curves are shown above: value flow, cumulative value, delay cost (as a function of the delay), and urgency (as a function of the delay).

This feature shows a diminishing rate of cost of delay (urgency), due to the twin effects of a reduced peak in earnings and reduced period of earning, the longer the feature is delayed.

What if we were examining a different type of work item which was estimated to save a certain amount of work each week, work which is currently being contracted out to external staff? In other words the same savings would occur every week for the foreseeable life of the product. Here is an estimated projection for the 4 curves in this case ...
Value Flow, Cumulative Value, Delay Cost and Urgency
for a feature providing constant benefit for a period of time
In this case the cumulative NPV is more or less a straight line (bending downwards slightly due to the present value discount), and it results in a CoD profile which is also more or less a straight line with the same gradient (bending upwards slightly). Straight line CoD profiles result in constant urgency which we can see (approximately) in the final graph in the series.

Different again - what about an item that would save a penalty fine from a regulator if a certain issue is not addressed by a fixed date? Here are the curves ...
Cash Flow, Cumulative NPV, Cost of Delay and Urgency
for a feature providing step-function in benefit at a fixed date

This work item displays a sudden step-function in cumulative NPV at the point the fine would be applied, and a similar step-function in the CoD about 10 weeks before the date of the fine, since development Lead Time is estimated to be 10 weeks. The urgency profile is a spike - no urgency up to the "last responsible moment" when work must start, and no urgency after this point since you would then have passed the "first irresponsible moment"; there is no avoiding the fine after that point! In reality the CoD and Urgency profiles should be smoother since there is uncertainty in the estimate, and leaving it to the last moment increases the risk of incurring higher costs in order to hit the date, or indeed of missing the date due to unforeseen circumstances.

Value Flow, Cumulative Value, Delay Cost
and Urgency for a feature providing constant
 for a period beginning at a fixed date
Finally consider the case where the savings of staff (similar to the second scenario above) would not start until a fixed date. See graphs to the right.

We can see this case effectively combines the previous two, with a period of low or negative Delay Cost, followed by approximately linear Delay Cost up to the end of the opportunity.

We have taken some time here to look at the 4 curves (Value Flow, Cumulative Value, Cost of Delay and Urgency) for these 4 different types of feature because it is easy to confuse between them. In the case of the "constant benefit" item, the Cumulative Value and Delay Cost look almost identical, with the same units on both axes. This has caused some confusion and some inaccurate statements about the use of cost of delay. Take care!

One of the observations to make about the graphs shown so far is that to estimate and derive them accurately for real features is difficult and error-prone. While this is true, one should not conclude from it that we should therefore estimate a completely different entity, which is easier but not well correlated with the scheduling decisions we wish to make! (Sadly, you may also come across some advice like that.)

However it does suggest that looking at archetype profiles for different types of work item may be helpful. Picking from a menu of profiles, based on the type of feature proposed e.g. diffentiator in a competitive market, cost-saver in a monopoly market, fixed date cost-saver, and so on, is much simpler than trying to derive these curves from scratch. Some tools for Kanban are already offering such features. The profile can be combined with order of magnitude estimates of value and urgency (e.g. using a series such as 1, 2, 5,10, 20, 50, 100, 200, 500, 1000, etc.).

Kanban [3] defines 4 archetypes with different Delay Cost Profiles which are typically used to differentiate Classes of Service. Black Swan Farming [4] also suggests some typical profiles. The Kanban archetypes do not correspond exactly to the types of feature discussed above, though there is some overlap.
Kanban's Delay Cost Archetypes, from Essential Kanban Condensed

The archetypes show 4 Delay Cost Profiles:
  1. Expedite items have very high urgency (high CoD) and there is no end in sight to the cost - if you wait, the losses don't come to an end. It's a straightforward decision - do it now! 
  2. The Fixed Date items also have high impact but only if you miss the deadline. The scheduling imperative here is to make sure you start before the last responsible moment and deliver before the deadline. 
  3. The Standard profile is approximately linear to start with and tails off or cuts off as the opportunity loses value. Standard items should therefore be done as soon as possible and scheduled relative to each other according to the degree of urgency and the item's size (see later discussion of WSJF). 
  4. Finally, Intangible items have an apparently low urgency. One might ask why do them? Two reasons. The intangible profile does indicate a rise in urgency - possibly a steep rise - will happen in the future. It is useful to make some progress on these items even though the impact in the short term is likely to be low. In addition having some items in the schedule which are "interruptible" makes the system more resilient in the event of expedite items having to be handled, or events which threaten the service level agreement for standard items.
So how might a workshop gather the quantified information that we need for scheduling the work item options based on cost of delay, particularly if we do not currently have a menu of items to pick from. Here's a generalised profile of cost of delay and urgency that (roughly) covers all the profiles we have discussed within the precision we could reasonably expect from the workshop.

Using this profile we can ask for 3 parameters that give enough detail for us to schedule the items. There are 2 dates (t1 and t2) and the slope of the CoD line (or urgency). Before t1 there is low or zero CoD - it's the "CoD low until date" (CLUD). After t2 there is also low or zero CoD - it's the "CoD low after date" (CLAD).

Armed with this information about delay cost and urgency profiles, we can now move forward to consider the WSJF method itself. To use it we need information about the urgency, the urgency profile and the duration taken by implementation of the work item.

This is considered in the next blog in this series.

Read part 3 now: How to calculate WSJF

Back to part 1: Understanding Cost of Delay and its Use in Kanban