Weighted Shortest Job First

Ian,

Check out this article. It will probably give you what you are looking for:

http://scaledagileframework.com/wsjf/

Ian,
Check this article out and let me know what you think:
http://agilebuddah.blogspot.com/2014/02/5-steps-to-using-weighted-short…

Hi Brad

I suspect that using WSJF to order a Product Backlog may invite vanity metrics. The question is, how are the variables to be populated in an unbiased and credible manner?

The article you linked to (thanks!) has the advantage of at least making things more democratic, in that planning poker is used to agree the values that certain attributes will hold. Yet clearly that could still result in "prioritization by persuasion". In Scrum, forecasts are applied by the Development Team to the smallest batch possible - the Sprint Backlog - in order to contain such estimation risk.

I reckon WSJF should be contrasted with more objective methods of backlog management such as innovation accounting, whereby Product Backlog order is informed by actionable metrics derived from A/B tests and the release of MVP.

As a feedback-driven approach to exploratory development, Scrum builds in an assumption that we will use small increments to prove or disprove hypothesis and make adjustments based on those results.

Values assigned for User Value, Time Value, RROE Value, and Job Size should be re-assessed based on real metrics. They should also be adjusted when strategic drivers change or if something happens that change the time-sensitivity of some Product Backlog Items.

In other words, give these values a best-before date. Just as every Product Backlog Item has a half-life, if it's been on the Product Backlog for an appreciable amount of time or is constantly prioritised down, it should be reconsidered in its entirety.

> In other words, give these values a best-before date

Yes, that would be sensible. The value measure given to a PBI does not suddenly disappear if that measure is unaddressed in a validated learning cycle. Rather, it is subject to gradual decay.

Hi Ian,
I’m not an expert in SAFe, but based on the literature on value management, and the structure of that formula, using relative “Job Size” should be OK; something like story points.

Generally, “value” is simply proportional to the benefits to cost ratio. In cases that do not involve procurement and costs are only for human resources with the less or more same level of salary, we can easily replace cost with “job size”. If we assume that the same number of people usually works on items, then we can even replace “job size” with duration.

There are a few things about the formula that I’m not comfortable with:

1. Risk is only considered for the numerator (benefits), while each risk has the potential to affect both the benefits and the cost; e.g. a risk that may cause you to spend three times more effort on the item.

2. There’s a risk of double counting the benefits with those three elements: User-Business Value and Time Criticality are not independent of each other.

3. There's an issue with the suggested way of normalizing in SAFe: assigning 1 to the item with lowest state in each column practically impacts the weight of that criteria. For example, if items are generally more time critical in our project, the importance of time_criticality automatically reduces in this formula, which is not right. The main problem is that we can simply use relative values with any linear normalization method, as long as we’re only dividing and multiplying them, while this formula is adding them up.

Anyway, I still have a bigger problem with this formula. When it’s difficult to measure something, people usually break down the calculation into smaller pieces and try again. Sometimes it’s not the right way, and we’re only fooling ourselves. In case of measuring value for items in a project, it’s probably enough to simply assign a relative, intuitive amount to “benefits”, and divide it by the size to get the “value”. Some people are not comfortable with it, because it’s subjective. However, the more detailed formula is still subjective, there’s more room for biases, and worst of all, creates the illusion of precision which is always dangerous.

I think it's also an important reminder that all exercises like this have flaws and aren't meant to be absolute replacements for intuition and other data points you may have. In most cases, there's no way to empirically know that you've made the right decision until after you've made it and executed (to the point above that some values decay over time if not acted on and will need revisited). If you're feeling particularly uneasy about the decision at hand, why not cook up two matrices with more granular articulations - then exercised independently to see if there are conflicts!

I've used WSJF extensively with a number of companies and context.  I've found that I've needed to adapt it slightly for specific contexts.  For example, with one company I built a scale for BV, 21 points being a £1m return per calendar month and £1k being a 1 point return.  Can also use a scale for TC too.  Found RROE less easy to build a subjective scale.

Currently working in national healthcare where, as I do not cover front line patient care services, where I found measuring value very challenging.  In this case I've used a tool called VMOST (http://vmost.tools) to help me organise product visions, missions, objectives, strategies and tactics and measured the value of BV against how does this tactic (feature) move the objectives for its mission.  That seems to work well.

The bottom line for me is that WSJF forces the right conversation over how we really assess value / cost of delay, whilst also understanding that there are dates we just need to hit, risks that need reducing and features that would enable further future BV.

The other benefit is size as a divisor.  When I publish a backlog, I usually put the CoD score right next to the WSJF score, even heat mapping them.  I do this because it forces a conversation around big valuable stuff languishing at the bottom of the list, because it's just too damn big, and how we decompose that value (batch size) into smaller units to release the value faster.

WSJF has really worked for me and has become the standard mode of backlog sequencing at many companies I've been involved with.  Can it be gamed, yes, but if backed with a set of measurable objectives or scale, it can reduce the amount of gaming.