Last summer,
Todd Kromann and I presented on
Dude's Law at
Agile2014, and I figured it was high time that I wrote a blog post to walk through what we covered.
Dude's Law
If you're not already familiar with the Agile Dude,
David Hussman, we highly recommend becoming familiar. David is most well-known for his coining of
Dude's Law, which states that "Value = Why / How". The intent behind Dude's Law was to help teams avoid what David refers to as the "Recipe Trap" - doing things because that's what the "recipe" (read prescribed methodology or management mandate) says you're supposed do.
 |
| Dude's Law: Value = Why / How |
Using Dude's Law as a coach is extremely powerful.It's a simple way for people to question everything they do. It emphasizes the need to know why we do the things we do. It resonates with people at an almost instinctual level.
WSJF
The more Todd and I used Dude's Law in our coaching, the more applications we found for it. Eventually, we noticed the similarities between Dude's Law and
Don Reinertsen's concept of "Weighted Shortest Job First", or WSJF.
WSJF is a powerful prioritization tool. There are basically three underlying principles to WSJF. First, if all the work you have to do is the same size, you do the job with the highest cost of delay first. In other words, we want to do the work that is the most urgent or will cost us the most to not do. After all, if all the work items are going to cost us the same amount then we want to get the most out of the time spent.
Second, if all the work you have to do has the same cost of delay, do the shortest job first. In other words, if all work is equally expensive to not do then we want to start getting benefit as quickly as possible.
Third, if both the size and cost of delay are variable, do the weighted shortest job first. You do this by dividing the cost of delay by the size; the higher the result, the sooner the work in question should be executed. Since our highest cost is typically the manpower necessary to do the work, size is defined by duration. Duration is also useful as the denominator because it emphasizes the need to get things delivered quickly, so we have a bias towards smaller slices of value.
 |
| WSJF = Cost of Delay / Duration |
Where's the work?
Before we go any further, we need work items. If you're applying this within a team, simply use the work that's already on your backlog (or slated to go on your backlog). Application of WSJF (or Dude's Law) tends to work best at the Epic or Feature level, but can be applied to User Stories as well.
If you don't have real-world work, you can do what we do - have the team(s) come up with their own work. We usually run this with multiple "table teams" - teams formed around tables in the room. We like to get one set of Features for the whole room so we can see the differences in prioritization by each group (it makes for some interesting conversation at the end of the workshop). To do this, we tell the room that we have a great idea for a game, but all we have is a title. Based on our market research, we know this title is a winner. We want to build "Angry Flappy Candy Bird Crush Saga". We then solicit five Features from the room that we think are essential to become profitable as quickly as possible. Voila! We now have the beginnings of a backlog.
Estimation Game
The key to applying WSJF (or Dude's Law) in the context of prioritization is the quantification of those values. We need numbers so we can do an actual numeric division to get a numeric value for WSJF (or Value). How do we do this? We highly recommend relative estimation! The most common way to use relative estimation is to use Fibonacci numbers to size items relative to each other. If you've never done this before, this can be daunting - especially for your first work item, when you do not yet have anything to compare the item's size against.
The technique that we use in this workshop is called the "
Team Estimation Game". This technique works well to quickly get an initial backlog estimated. Since most people are used to estimating size anyway, we have teams estimate the size (what we refer to as "Cost of Implementation") first using the Team Estimation game. Once they're done, we have them write the number on the bottom of each story card, in the center.
 |
| The Team Estimation Game summarized |
Cost of Delay
Now that we've estimated the cost of implementation, we need to estimate the cost of delay. We do this with the exact same approach we used for cost of implementation. When trying to figure out cost of delay, think of it in terms of, "How expensive is this to not do?"
When considering cost of delay, there are several factors we need to consider: inherent value to the business; urgency due to any number of reasons (legal deadlines, market demands, partner collaboration, etc.); the value of other work that's dependent on this work item being done first; risks that this item may reduce; and so on.
When we're talking about benefit, we usually use the priority scale where 1 is most important, then 2, then 3, etc. That is not what we're doing here. In this case, a 1 is something with a very low cost of delay - it's not very urgent, valuable, etc. The higher the number, the more expensive it is to not do.
Once each card has a number value, write it in the bottom left corner of the card.
Run the Math
Now that we have the two variables on the right side of the equation, we need to "run the math" to see what our WSJF (or Dude's Law) number - what we call the Value Index - comes out to be. For each card, divide the Cost of Delay (bottom-left number) by the Cost of Implementation (bottom-center number) and put the result, the Value Index, in the bottom-right corner. Order the cards from highest Value Index to lowest Value Index. This is now the priority that the math recommends you complete the work in.
As long as your estimation was honest, doing the work in this order will give you the greatest return on your investment over time. We can maximize how much we capitalize on our work as soon as possible. The below graphs help illustrate this.
 |
| Add value sooner with WSJF/Dude's Law |
Remember Dude's Law
What we often find is that the first time people use this approach their prioritization is a little wonky. That's okay - the purpose of this exercise isn't to mandate what order you do things in. This approach is a
conversation framework to help teams make sure they're working on things in the right order, factoring cost of implementation into the prioritization process instead of looking only at short-term benefit. Teams also find that this tool becomes more beneficial as they gain experience with it - they learn what they need to discuss in order to come to proper estimates that lead to better prioritization.
Remember the original intent behind Dude's Law: to avoid the Recipe Trap. This approach is not intended to be a recipe for the team to follow blindly. This is a tool, one that the team should understand the benefits of before they decide to adopt it. Understand the
Why before jumping into the
How.
You may also decide to elaborate on the formula. You may take the
SAFe approach and discuss different factors to Cost of Delay instead of having a single number. You may decide to incorporate IBM's approach of
Value Dials and ITBV. You may end up with a multi-sheet Excel workbook with dozens of numeric inputs that feed into a complicated formula. In the end, it all boils down to Why/How. Be careful how much extra time you put into prioritization and make sure the improvements to your prioritization justify that extra time.
I actually want to try a whole bunch of things that Jurgen introduced in his opening keynote, but this is the one I’m starting with. I’m working on mine now and, on Wednesday, my tech lead and I will present ours to the team. We’ll give them about a week, and then they’ll share theirs. I will keep mine up-to-date in a digital format that I can share with any other new team members that arrive in the future, as well as all of my friends here on the Internet.
I’ve joined the Slack team, followed them on Twitter, joined the Facebook group, and plan on getting involved with their open source repo on GitHub. I’m not sure what exactly I’m going to do with all this, but I’ve got the sticker on my laptop that reminds me everyday to Make People Awesome; Deliver Value Continuously; Make Safety a Prerequisite; and Experiment & Learn Rapidly. I’ll be re-watching Joshua’s mid-conference keynote when I share it with the team and perusing his slides for further hints and advice on how I can implement Modern Agility on my team.
The conversation in the Agile community has been trending more and more to value, but I most like the term that David Hussman used: impact. Before our team builds anything, we’ll define the impact it will have once it’s been delivered. We won’t work on things that don’t have impact, and we won’t call it done until we’ve validated whether or not the impact was made. 
Following the conference, I had lunch with Woody Zuill of #NoEstimates and #MobProgramming fame. He talked about the process by which Mob Programming came into existence. He was trying to help the team learn how to identify what’s working and what’s not by holding short, daily retrospectives. By narrowing the timeframe for inspecting and adapting, the team could more easily pinpoint daily activities that were beneficial or not. As a software engineer, I see the daily retrospective as the algorithm that produced the solution of Mob Programming, and I want to see what kind of results it produces when I provide my team as the input to that algorithm.
Coming back full circle to Jurgen’s “Managing for Happiness” keynote, I want to use the Celebration Grid approach in our fortnightly retrospectives to highlight learning. I’ve grown accustomed to the “Fail Fast” language that permeates the Agile community, though I always use the Spotify language of “fail fast to learn fast to improve fast”. Well, if you fail fast but don’t learn from it then it’s not useful, so why not focus on the learning and not the failure?
.png)
