Why WSJF Should Be Done on MBIs and Not Features or Epics

This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.

Disciplined Agile Value Stream Consultant Table of Contents

This article is for those who are already familiar with Weighted Shortest Job First (WSJF) and is mostly intended for those using WSJF on features as prescribed in SAFe.

One of Don Reinertsen’s most valuable pieces of advice is “If you only quantify one thing, quantify the Cost of Delay.” This means to look at the loss of value realized incurred by a delay.  That is, if a release is delayed by two months, and the value we would achieve is $100,000 a month, then our cost of delay is $200,000.

WSJF is a great method of sequencing the work to be done based on cost of delay. However, it requires that the items being sequenced have realizable value. Most features are not releasable on their own, however. Calculating cost of delay doesn’t make sense since you can release it, but no value is delivered so the cost of delay continues.  Doing CoD on epics also doesn’t make sense since you should be trying to get that part of the epic out that will realize value quickest (we call this the minimum business increment, or MBI). Calculating CoD on the entire epic when you’ll be releasing some of the epic earlier will not be useful.

WSJF should only be applied to items that will realize value when released.

Quick introduction

More on WSJF

Improving WSJF.

Related articles

Related reading paths