[music]

**Al Shalloway**: Hi. Thanks for attending our Weighted Shortest Job First Training Module, Identifying Comparative Value across this portfolio. My name is Al Shalloway. I'm CEO and Founder of Net Objectives. As you can see from the books I've written with my team, I'm actually very familiar with Scrum, Lean Agile software development, design patterns and essential skills for the agile developer.

I was co‑founder of Lean Systems Society and a board member until fairly recently. I also co‑founded Lean‑Kanban University, but I'm no longer active with it. My company is a goal partner with Scaled Agile Framework and personally I'm an SBC trainer as well.

This talk is actually about prioritizing for optimal return on investment and whether you're using SAFe or not, this is very relevant. This technique works regardless of how you implement things.

When we want to prioritize for optimal ROI we sometimes think, "This is top priority. This is next priority." What you want to do is what we call job sequencing. It's really the key to getting proper economic outcomes.

If you just prioritize you can say, "Everything is an A. OK, these 97 things are an A. These three things are a B." There's a tendency they have too much at top, and then too many things get started. We want to actually have a sequence. This is first then we can allocate people in resources we need to it.

This is second and we can allocate other people with other resources we need to it, things of that nature. They need to be sequenced. This begs the question what's the things we're sequencing?

In that objective is we like using things called minimum business increments. You may have heard these called minimum marketable features, minimum viable products. The reason we use MBI is, it's a term that whether you're IT group or product group, Lean start‑up or you're building add‑ons it's a term that works.

It's the smallest amount, the minimum amount of business value that can be built to [inaudible 1:53] consume that makes sense from a business perspective. Meaning if you've got a subset you could deliver but you don't want to come out with something that's not complete then don't deliver it, that's not making sense.

If you've got something where you're targeting a market segment and you could get a totally done for that market segment and release it say, two months before the product that would be ready for every market segment. That might make sense.

Or if you want to build something and try out something. Do like AB testing that might make sense. Don't think of it as the minimal thing that could be built. It's the minimum thing that makes sense to be building and releasing.

Agility really should be about delivering business increments. It's not about team iterations per se. Anyway, now we know what we're prioritizing. What are the minimum business increments? What sis the sequence that we can deliver these in?

We also have other training modules on MBIs, how you create them, but that's for another time. Then how do we do this? Don Reinertsen suggests that if you only quantify one thing, quantify the cost of delay. This is from Reinertsen principles or product development flow, very [inaudible 2:58] advice.

By cost of delay what he really means is that it's the cost of unrealized value. This could be that of deferred value like, "This thing is going to make me $100,000 every month." If I get it now I get 100,000 this month. If I don't get it delivered for a month it's lost the value of 100,000. I could have gotten. It gets deferred by three months, I've lost 300,000 value.

It could be a missed deadline. This could have consequences, such as we have some compliance issue or some commitment to a client of ours. Could also be a lost opportunity in that if we can get it out before our competition we've got an opportunity, if we don't we lose the opportunity. If we can get it out in a certain time we gain a client. Things of that nature.

Cost of delay is not quite just a vanilla number, but it has to include all of these things. The question is how would I prioritize? Assume right now we know what the cost of delay is. We want to get some sense of how we would prioritize and look at cost of delay in a little greater depth.

Let's say we have three MBIs, A, B and C and they all have the same cost of delay. Let's just say it's five and not really worrying about the unit right now. A will take two weeks, B will take four weeks and C will take five weeks to complete.

The question is which one do we do first? Since they all basically will give us the same value or we lose the same amount by the deferment of them, we should do A first. I think that's pretty clear. We can actually analyze this.

Do the shortest one first. If we do A first...I've got this graphically tabular, the same thing really. On the left it's doing shortest job first. We get a deferment of 10 because it takes us two weeks to get it done. At the end of two weeks it's done and we now start getting our value, but we've lost 10 potential units of value while it was being built.

I show this both on the left, graphically on the right and tabs. The shortest job first is top row. The longest job first is the bottom row. The cost of delay, the lost value is 90 at the top and 125 on the bottom. Meaning we better do the shortest job first, because we'll get more value by deferring less value.

Another way to think of this is that if you do A quicker you get more value from it. A could be done, returning value too quicker. Then B will get you value even sooner than if you did C. If you do C first you don't get value quickly enough.

Now let's ask the other question. How would you prioritize the following when they all take four weeks? A's cost of delay is four, B's cost of delay is two, C's cost of delay is one. In other words they cost as much to build but you get more return on A. That's why its cost of delay is higher.

Again it's the same thing graphically and tabularly, we're going to get faster return, more return if you do A first because you get more value with that and the time period takes the same. We do the thing that gets us the more value. Given all of the cost it's the same amount.

This is really no surprise. If three things take the same amount of time, do the one that gets you most value. If three things give you the same value, do the one that takes the less time.

What we do when nothing is equal? In other words what if A's cost of delay is four, it takes five weeks to complete. B's cost of delay is three, it takes three weeks to complete. C's costs of delay is one, it takes two weeks to complete. What do we do?

The weighted shortest job first says is equal to the cost of delay divided by duration, and this makes sense too. In other words as the cost of delay goes up, the weighted shortest job first goes up which is what we'd expect. As duration goes up, the weighted shortest job first goes down.

As it is more valuable the score goes up. If it takes more cost to do it, takes more time to do it, the value metric we're using goes down which is what we'd expect. Here we've got from the example before the MBI A, B and C cost of delay duration weighted shortest job first is given on the right side. Four divided by five is 0.8 basically.

What is really this cost of delay? How can we actually measure this? We've talked about its business value type criticality, risk reduction opportunity enablement, things of that nature. How do we measure this?

The way SAFe suggests doing this and I like this. It's not exactly the way Don Reinertsen does it. Don actually suggests getting absolute numbers, which is more accurate but is actually difficult in a lot of places.

Dean Leffingwell when he came up with SAFe, said weighted shortest job first, the way we could do this is relative measurements which actually works better. [laughs] It works better because even though it's not exactly accurate in the sense of Don's. It's better in the sense that we could get these numbers and that's really what we want to do, is be able to get numbers we can use.

Let's calculate the weighted shortest job first and we have cost of delay divided by duration, but the cost of delay is equal to business value plus time plus risk reduction and opportunity enablement divided by the size.

The way we're going to do this is we're going to use a scale for each parameter of the modified Fibonacci sequence 1, 2, 3, 5, 8, 13, 20 which will be familiar to you if you're familiar with agile estimation. If you're not, just think of it this way. We really are talking about significant differences. Difference between one and two is fairly significant. Difference between say, 8 and 9 isn't, between 12 and 13 isn't.

We want to have an easy way to basically block things out as about the same size. We're going to do one column at a time. We're going to use relative estimation, ones I'm going to teach in just the next couple of minutes. Making value for the smallest MBI one. There must be at least one, one in each column therefore because this will help normalize things to some extent.

The highest weighted shortest job first is the highest priority. Let's look at this. I'm going to show you this is a method called team estimation developed by Steve Bachman. It's a little easier to learn and takes less time than Planning Poker. We find it fairly useful and it's also been what we use instead of Planning Poker.

If you like Planning Poker, keep it up. It's a good method too. This is a little more efficient, Planning Poker may be more fun. That might be the difference.

Anyway, we take our list of MBIs and we take the first one off. We put into the column by itself. Then we take the next card and we say, "It's significantly more than the first one" or not. If we think it's significantly more we put it to the right.

If this third card, we think is about the same. We just keep doing saying whether it's about the same, in between or greater than or less than. We keep doing this until we get all the cards. We can reprioritize them. If somebody says, "I used to think that was about the same, but now I think it's over here."

You keep discussing this and there are some rules you can come up with. Some people like to do it one person at a time likes to talk, picking one card and rotate. Some people like to do it as a group. It's really up to you.

Eventually you get all of these minimum business increments prioritized by column. What this means is left most one it's by itself, so it's there. This one to the right of it is significantly larger than the one to the left of it and etc.

Now we start. The first column is easy, it's always one. You guys are trying to get some general normalization of things. Then the next one as well is it's about twice as big, three times as big. What is it? We think it's twice as big.

The next one is, is it a three or five, an eight? It's a five. We keep doing this until we come up with all the different methods that we have. What we have now is we can actually do this estimation and come up with things. Let's say this is how it worked out.

The cost of delay is this and we have the size as before. The weighted shortest job first is this. Actually we would do A first, B first and C first in this example anyway. It doesn't always go by the cost of delay. In fact you can actually see we're doing C last even though it has more value, because it also has a lot more cost to it.

You might though ask, is the cost of delay an equal weighting of business value, time criticality, risk reduction and opportunity enablement? Actually probably not, or possibly not anyway. Once what you had was business value was worth half of it. Time criticality was worth a fourth and risk reduction opportunity enablement was worth a fourth.

This is something you've also got to talk about what's an alternative way. We're now actually extending weighted shortest job first from the same method. This seems like a nice extension at times.

If we calculate these numbers we come up with the cost of delay sizing the weighted shortest job first as shown. That's because we're weighting the business value by half for the time criticality. In other words, it's 0.5 * 1 + 0.25 * 3 + 0.25 * 13. That's why we have a small number.

If we compare this against the old values you'll see in fact that we get a different order or different values. Actually different order, because now it's saying let's do B first. Because most of its value is coming from business value, not the time criticality or the risk of production.

Again, what these values are, what these weightings are would really depend upon your organization. If you do 0.33, 0.33, 0.33 you're exactly back at the SAFe model. Just a thought to see if it applies.

Weighted shortest job first in summary is what provides a way to assess roles of value, business value across a program. It evaluates value and the cost of not achieving it, time criticality of delivering it as well as risk mitigation and opportunity enablement. It can be extended to work across the enterprise.

Thanks for being here. I hope you've enjoyed this.

[music]

Transcription by CastingWords