The HiPPO vs. The Dude - The Eternal Prioritization Battle

If you didn't already know, I'm a huge fan of David Hussman's "Dude's Law", which states that "Value = Why? / How?". I've used this concept both in coaching in general (as it was intended), as well as a fun and easy way to execute Weighted Shortest Job First (WSJF) prioritization.

A universal obstacle to value-driven prioritization is the HiPPO - the Highest Paid Person's Opinion. I still encounter this in organizations that have been on their Agile journey for over a year. It's painful for me to hear them explain the difficulties they have with changing priorities while being held accountable for the successful delivery of original commitments. Yet, when I recommend they quantify their value somehow, they explain that it can't be done. Priorities are set by people that have much more subject matter expertise and are "above my pay-band". They have to obey the HiPPO.

How does one respond to the HiPPO? With the immortal words of The Dude, of course!

"Yeah, well, you know, that's just, like, uh, your opinion, man."

Opinions are important, but we want everyone's opinion and we want to put those opinions in context of all the available options! When a conversation framework is used to turn opinions into a quantitative estimate that can drive consistent and objective prioritization of work, it becomes easy to justify a change in plans. When teams track how much value they delivered relative to what was committed to (instead of static features or objectives) then the reluctance to take on valuable, unplanned work goes away; even more importantly, the team is armed with the data to push-back against unplanned work that really isn't as valuable as the HiPPO made it seem!

The HiPPO vs. The Dude

Dude's Law isn't the only way to prioritize work. There are other techniques you may decide to use, just know that if you stick with the HiPPO you run the risk of seriously damaging team morale and momentum. The HiPPO destroys, the Dude abides.

Practical Application of Dude's Law: The Value Estimation Game

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.

Revisiting Normalized Story Points

It has been just over 18 months since I published my most popular blog post to-date: "Normalized Story Points". As of this writing, it has received over 5,400 page views, thanks primarily to the reference it has from Dean Leffingwell's blog post from ScaledAgileFramework.com entitled "More on Normalizing Story Point Estimating".

As an Agile Coach who takes continuous improvement seriously, I have learned much and grown much over the last year and a half. Here are a few of the things I've learned regarding Normalized Story Points.

Know Why You Want Them

I've become a HUGE fan of David Hussman's "Dude's Law". Before you do anything, you need to know WHY you're doing it, not just HOW to do it.

The purpose of Normalized Story Pointing is to enable high-level estimation of work for a SAFe Release Train comprised of closely aligned teams, any one of which may pull a Feature off the Program Backlog for implementation. Normalized Story Points should not be used for:

1. Comparing teams against each other
2. Forcing teams to use the same story point size (so that "1 Story Point" means exactly the same thing to everyone forever and ever amen)
3. Defining "Story Point" to mean "Ideal Man-Day"
4. Any punitive purpose

If you don't know why you're using Normalized Story Points, don't use them. If your intended use of Normalized Story Points violates the mindset established by the Agile Manifesto, don't use them (although, if this is the case then you probably won't realize it unless someone points it out to you).

Beware the Ideal Man-Day

The 4-step process for getting started with Normalized Story Points involves using time as a reference. This works well because you're using a very small story, one with very little complexity, which means the primary factor for determining "bigness" is lapsed time. That being said, I've found that teams that start with this approach have a very, very difficult time recovering from the mindset of "1 point == 1 ideal man-day". This is bad for reasons.

This also leads to teams always using days of availability to forecast velocity rather than taking a rolling average velocity or "yesterday's weather" as an indicator of what they're likely to deliver. Data trumps theory; the approach to get started is based on theory, while average velocity is data.

Individuals and Interactions over Processes and Tools

Processes and tools exist to enhance and enable interactions between individuals, not replace them. As I've explained in a previous post, the process of Agile estimation is beneficial primarily because of the conversation that it fosters. It's a well-formed game that drives a shared mental model of the work for the entire team.

I've found that teams that use Normalized Story Points may skimp on the conversation, especially if one team ends up with work that another team has already estimated (after all, we all share the same definition of story point, right?). This was never the intent behind Normalized Story Points, but that doesn't mean it doesn't happen.

Beware the Recipe Trap

David Hussman explained that he uses "Dude's Law" to help teams avoid what he calls the "Recipe Trap" - doing something because that's what the recipe says to do, without understanding what the intended benefits are. When it comes to Normalized Story Points, the recipe trap is very real and very dangerous. If you use it, be very careful about how you explain and implement it with your teams. If your teams can't all pull from a common backlog; if you're going to use them to run punitive metrics; if you want to streamline your process by reducing meaningful conversation; or if you're looking to use it because that's what SAFe says to do, I plead with you to reconsider.

TL;DR: Normalized Story Points can be a useful tool for your organization, but it's not a one-size-fits-all solution. 

WSJF - What to do in a tie?

Todd Kromann and I facilitated a workshop at Agile2014 on the subjects of Dude's Law and Weighted Shortest Job First (WSJF). We helped the group understand how to apply relative estimation not only to Cost of Implementation (size, expense, complexity, etc.) but also Cost of Delay (urgency, risk, dependency, compliance, etc.). We used the modified Fibonacci sequence most often used for Story Points to quantify both of these numbers, which was done by table teams. Each feature's Value Index, used to prioritize, was determined by its Cost of Delay number divided by its Cost of Implementation number. (You can get a soft copy of the handout we used here).

At the end of the workshop we had, as we usually do, a team whose features included a tie. This sometimes happens because they have the exact same Cost of Delay and Cost of Implementation numbers. More often, this happens because the numbers used in the equation are different, but the division comes out the same. One of the questions that invariable arises is: which feature should be prioritized first?

In theory, it doesn't matter - the ratio of urgency to expense is the same. Once both are implemented the ROI is equal. The decision of which to do first should be determined by the organization. In reality, I believe that the smaller feature should be implemented first. I've drawn up an example to illustrate.

In this scenario, we have two features, A and B. Feature B is 20 times more expensive than A, but also 20 times as valuable. Let's look at what would happen if we implemented Feature A first.

As you can see, we get a little value very quickly and significantly more after a delay. If we say that the y-axis represents millions of dollars and the x-axis represents quarters of the year, then we get $2MM/quarter after our first three months with no increase until five years later, when our quarterly revenue jumps to $42MM. By the end of our 22nd quarter, we will have earned $82MM.

Now let's see what it would look like if we did Feature B first.

Using the same axis values as before, we're basically going five years without any revenue. However, after five years of development, our revenue jumps to $40MM/quarter, with a $2MM/quarter bump immediately after. Just like before, we will have earned $82MM by the end of our 22nd quarter and will be earning $42MM/quarter thereafter.

So which one's better?

Do you really want to go five years without bringing in any revenue? Of course not! You'd much rather start capitalizing on your work after only one quarter's worth of work. Not only do you now have some money in to fund yourself, you're learning from the market based on how they use what you've released. This new-found knowledge will improve the quality of subsequent releases.

The reality is that, although the former option is better than the latter, neither are great. What you should do is, while you implement Feature A, break down Feature B into smaller components. It is highly unlikely that all of these components will have a 2:1 ratio of CoD:CoI. You'll identify which sub-Features provide the highest relative ROI and implement them as soon as you finish with Feature A. There may be sub-Features that you never get around to implementing because the value doesn't justify the expense. You can instead move on to a new Feature and begin decomposing and prioritizing its pieces. By the end of your 22nd quarter, you'll end up bringing in much more than the $82MM/quarter number that the two options above afforded.

That's my take on what to do in the event of a WSJF tie. What would you do?

Agile2014 Proposal Accepted

Today is a big day for me; today I accepted an invitation to speak at a conference for the first time! Todd Kromann and I will be co-facilitating a workshop I've put together on value-driven prioritization, based on the concepts of Hussman's "Dude's Law" and WSJF. I've copied my abstract below. If you're going to be at Agile2014, let me know! I'd love to meet you in Orlando this summer!

Practical Application of Dude's Law: Come Play the Value Estimation Game!

Abstract:

You know how you determine the "bigness" of your work and establishing commitments, but how do your customers ensure you're committing to the right thing?

Come experience relative estimation to determine value. We'll use David Hussman's "Dude's Law" (Value = Why? / How?) to prioritize the work.

We will share techniques for determining the "Why?" so that you can generate a Value Index. What many people will be surprised to learn is that they already have tools for sizing that can be used for determining value and prioritization.

Information for Review Team:
The break-out of the 75 minutes would include:
3 minutes: Introduction to Dude's Law and the Value-Driven Heuristic
10 minutes: Explain and model the first exercise (Team Estimation Game for relative sizing)
10 minutes: Have round-table teams execute first exercise with a set of 10 features
5 minutes: Explain and model the second exercise (Team Estimation Game for relative benefit - same mechanism, so it takes less time to explain and model)
10 minutes: Have the round-table teams execute second exercise with the same set of 10 features
10 minutes: Have each team determine the Value Index of each card by applying Dude's Law
15 minutes: Have teams share their outcomes, insights
12 minutes (or less, if previous sections have run over): Q&A *

* In the case that there are not enough questions to fill the remaining time, I will explain the flexibility of Dude's Law (you can use Planning Poker or whatever technique works best for you) and introduce them to concepts such as Weighted Shortest Job First and Value Dial weighting.

Prerequisite Knowledge:

The concept of Relative Sizing (Story Points, T-shirt sizing, etc.)

Learning Outcomes:

• Experience and learn how to apply a practical, proven game for prioritizing your work based on value
• Understand that using a heuristic for valuation is better than both gut-feel and over-engineering
• Understand that, as with estimating size/cost, the real value comes from the conversation

Presentation History:

I've done the Team Estimation Game dozens of times before with as many teams and have done the exercise including benefit to determine a Value Index with at least one of those teams. I also have led Program Management teams through a very similar prioritization matrix model that leverages the concept of Weighted Shortest Job First.

Comment:
My presentation is a reflection of my own beliefs and experiences. None of the material I present should be interpreted as an endorsement by my employer. I have received express written permission from David Hussman to reference Dude's Law, and I am a Certified SAFe Program Consultant (SPC), which qualifies me to speak on their Weighted Shortest Job First (WSJF) Framework.

Introspective: Conversation Framework

We're all just faking it and hoping everything works out.

What's in a Number?
For at least half a year now, there has been a growing movement in the Agile Community for #NoEstimates - the concept that estimating the size of your work, regardless of method, is detrimental. The idea is intriguing and thought-provoking, which automatically gives it some degree of merit among those who are constantly striving to push the boundaries of Agile. The thoughts on the subject that most resonate with me on this subject come from Dan Mezick of Open Agile Adoption fame and Valerie Santillo, a blogger I met last year in D.C. and have kept in touch with since. What both of these thought leaders have said is that the conversation that leads to the estimate consensus is the most valuable aspect of the estimation process, and that great care should be taken to maintain that learning process.

The question then becomes: can you have a learning conversation and reach some sort of consensus as a team without an estimate to trigger that the consensus has been reached? My intent here is not to answer the question, but to illustrate how powerful this concept - using a conversation geared towards achieving consensus as a framework for learning - can be in practice.

Meetings, or Games?
Dan Mezick describes this consensus-driving conversation framework in the context of gamification. He posits that all meetings are games, and uses Jane McGonigal's definition of good games to show that meetings are ineffective because they are broken! A good game contains: a clear goal; clear rules; a way to get feedback; and opt-in participation. In a later post, Dan details How Games Deliver Happiness & Learning by putting gamification in terms of senses: a sense of control; a sense of progress; a sense of membership and community; and a sense of higher purpose and meaning.

Estimation as a Game
I propose that Story Point Estimation, particularly the Planning Poker approach or similar, meets the criteria for a good game as stated above. First, there is a clear goal: to agree on the "bigness" of each User Story. This is where my concern with the #NoEstimates movement comes into play, though I'm definitely open to their alternatives. Second, there are clear rules; the team has a Definition of Done for each Sprint, and each User Story has Acceptance Criteria to help the team understand what the User Story is (and isn't). Third, there is a way to get feedback through both conversation and revealing of Story Points. Conversation, in theory, would be good enough. However, experience has taught us that assumptions not stated in the initial conversation are revealed when discrepancies emerge as Points are shared. By having disparity in estimates, we are providing feedback that our assumptions differ. Fourth, the participation is opt-in - or, at least, it should be. Estimation should be done at a time and for a duration that the team agrees to. Nobody on the team should feel like they are being forced to participate. If there are, the Scrum Master or Agile Coach needs to step in, mine for conflict, and find out why the team member is disengaged so that the team can fix it.

Now let's look at it in terms of senses. First, there's the sense of control. The process of Planning Poker should, again in theory, prevent the process of estimation from being dominated by a loud minority. Every participant should feel some level of control over the direction of the conversation. Second, the sense of progress. As votes are cast and the numbers converge, we feel like we are nearing our goal for each Story. On a deeper level, we're growing closer as a team and gaining a more in-depth understanding of the system being built, which provides us a feeling of accomplishment and satisfaction. Third, the sense of membership and community, which should have been fostered prior to the activity and is reinforced throughout the conversation. Finally, the sense of higher purpose and meaning. This sense is driven by the nature of the work being discussed and estimated; a team that isn't opting-in may not feel this sense.

Every Meeting as a Game
What I've just walked you through are the conclusions I've started to form about how ALL conversations should be structured. It's the context with which I constructed the training material for the senior management that my fellow Coach and I were tasked with training on Agile. We started with the goal: how will each person change their behavior as a result of the paradigm shift we take them through? The mechanism we chose was the 5-Spoke Wheel Retrospective that we would end the training with. Starting with the end in mind, we created a framework for having the participants discuss the Principles of Agile and the Themes of Product Development Flow that would result in them debating with each other and examining the work they do on a daily, weekly, monthly, quarterly, and annual basis. As facilitators, we spoke for about a quarter of the time, opting for audience participation and group teaching instead.

I was shocked and amazed with not only how smoothly the class ran with so little structure, but with the amount of positive feedback we got afterwards! I then thought back to my early days with my first Scrum teams, how they would talk about how little time they spend in meetings now that they've gone Agile. When questioned about their Daily Scrum, Story Time (Backlog Grooming), Sprint Review & Demo, Sprint Retrospective, and Sprint Planning meetings, they would respond, "Oh, we don't really think of those as meetings; they're more active group conversations."

Framework for Success
Personally, I like Story Point Estimation and will continue to use it as a tool to help people bridge the gap from traditional (Waterfall) project structure and more Agile approaches. If they decide to do away with estimation altogether and can do it in such a way that the valuable conversation is not lost, I say go for it. I will also begin to encourage everyone to take a gamification approach to meetings with the goal that people not only look forward to them, they are insulted at the insinuation that their conversations are called "meetings". After all, meetings are dull, pointless, no-fun snooze-fests!