### 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

### 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?