Skip to main content


Showing posts from 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 Condensedwhich 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 CostIn 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…

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 differentDelay Cost and Urgency Profilesand 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…

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  the value flow (net benefits, positive and negative) each week through the useful life of the proposal, for a given release datethe change in cumulative value (Net Present Value, NPV, or life-time profits) as a  function of time, for a given release datethe Delay Cost Profile - how much business value is lost as a function of the delay 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…

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…

Kanban's Survivability Agenda and Antifragility

A conversation on the kanbandevonline forum has triggered this post. The discussion concerns how evolutionary change is applied, particularly when the fitness landscape is changing to such a degree that large rather than small steps are needed to survive in the new competitive environment. It got me thinking that we must consider evolutionary change on more than one level if we want to address what the Kanban Method calls its Survivability Agenda.

The first mystery to consider is how evolution jumps across valleys in the fitness landscape. Seems to me there are 3 possibilities. You could make large leaps in what you think are promising directions. Doesn't sound a great idea because you're doing reasonably well as you are (different if you know you face an imminent existential threat, but it has the same likely outcome). You could wait for the peak you're climbing to decline in the fitness landscape, to the stage when small steps will move you off it. That's probably goi…