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. 

A(nother) Response to SAFe Criticisms: Part 3

Full Disclosure: I am a certified Scaled Agile Framework (SAFe) Program Consultant (SPC).

In the first part of this series, I explained my intent behind answering some of the criticism for SAFe and asked for concerns that you would like to see addressed. I haven’t received any direct feedback, but the offer still stands. In the meantime, I’m going to dive into some of the more common criticisms I’ve seen already published. I’ll try to focus on one concern or small group of related concerns per blog post.

HIP Sprints

One criticism that’s prevalent among SAFe’s detractors is the inclusion of the HIP Sprint on the Big Picture. This is another case of SAFe trying to accommodate reality for organizations new to Agile. HIP, by the way, stands for “Hardening | Innovation | Planning”. It definitely gives the vibe of “Waterfalling the Sprints” and deserves our attention.

Hardening

Hardening should, in my honest opinion, be done away with as soon as humanly possible. However, if you’re brand new to Agile and have not yet built up your technical practices and hardware, releasing to Production without a hardening period is a bad idea.

SAFe does a good job of outlining what may be appropriate hardening activities versus those that could/should be done sooner. This is a good resource for new teams to get rid of hardening. Teams should focus first on getting activities that should definitely be done before hardening included in their Sprint Definition of Done. Then they move on to those that could be done sooner out of hardening. Eventually, they should aim to have their Release Definition of Done match their Sprint Definition of Done. At this point they could, potentially, go to Production with the completion of each User Story, which is just a hop, skip, and a jump away from a continuous delivery team.

Innovation

I know, I know, having an “Innovation Sprint” is like having a “Kaizen event”. And yet, we hold Retrospectives as an opportunity to focus on improvement that should, in theory, be continuous. If your company does not support a culture of innovation then no framework will magically change that. However, if you have a team that has managed to eliminate hardening activities, they should be rewarded with a Sprint of unfettered innovation. Give them a couple of weeks to do what they want and they will surprise you with how much they accomplish! Heck, it may even help to transform the company’s culture to one that embraces innovation.

Planning

This aspect of “HIP” tends to have the least resistance as Planning is well-recognized as a fundamental component of successful Agile organizations. The final Sprint of the PSI should include the planning activities that will prepare the Agile Release Train for the upcoming PSI. These include the Solution Demo (PSI Review), Inspect & Adapt Workshop (PSI Retrospective), and PSI Planning (PSI Planning).

Most ARTs will get these activities done in the last 2-3 days of the PSI. The timing and duration are flexible, but the activities are essential, especially for new Agile teams. This may not make sense for continuous delivery teams, but neither do any of the other time-boxed meetings that provide the structure for time-based commitment approaches (a la Scrum).

Thoughts?
Given my experience with new Agile teams, the HIP Sprint is a powerful tool. Without it, making the transition to Agile would be near-impossible. Is it a mature Agile practice? No, of course not. But is it better than continuing with Waterfall until the teams magically reach a state where they can do Agile without a HIP Sprint? Most definitely. That’s what I think, anyway.

A(nother) Response to SAFe Criticisms: Part 2

Full Disclosure: I am a certified Scaled Agile Framework (SAFe) Program Consultant (SPC).

In the first part of this series, I explained my intent behind answering some of the criticism for SAFe and asked for concerns that you would like to see addressed. I haven’t received any direct feedback, but the offer still stands. In the meantime, I’m going to dive into some of the more common criticisms I’ve seen already published. I’ll try to focus on one concern or small group of related concerns per blog post.

25% Scrum Masters

Edit: I originally published that "This is something that I have yet to find on the SAFe website but did come up in my SPC training. And I can tell you that it was not well received! If you want to hear about exactly how well it went over, just ask Valerie Santillo. Here’s what I got out of it:"

It has since been pointed out that this guidance is on the main website. I'm not sure if this is a new addition or an oversight on my part. It can be found in the Scrum/Agile Master Abstract in the Details section, under the heading "Sourcing the Role: A Part Time Responsibility".

Accommodating Reality

The truth of the matter is that you can’t always get Scrum Masters that are dedicated to that role. This should absolutely be avoided if possible, especially when working with teams new to Agile. What they’re saying by 25% is that, if you absolutely cannot get someone to be a fully dedicated Scrum Master, you should expect the role to take up about 25% of their time. I’d say that should about cover the administrative aspect and keep the wheels moving, but that’s about it.

Four Teams

A better approach is to make Scrum Master a dedicated role and allow them to work with multiple teams. The 25% recommendation tells me that Scrum Masters can handle at most four teams. Again, if you can avoid it, I would recommend having fewer than 4 teams sharing a Scrum Master. The most I’d personally recommend is two, with a preference to only one. However, this guidance is supposed to accommodate reality, and sometimes you just don’t have enough SMs to go around.

Starting Point

The 25% justification really only works when you’re just starting out and trying to get organizational buy-in. If you can suck it up and make it work well enough then, hopefully, your management will see the benefit a good Scrum Master could make and will make it happen. They’ll remove the part-time role, reduce the number of teams per Scrum Master – anything necessary to continue the improvements the teams have started making. That was actually the case with my first team. They went through their “Sprint 0” and their first two regular Sprints without a dedicated Scrum Master. They were struggling, but they were showing management that they were committed to making Agile work. I was allowed to come in as their Scrum Master – and only as their Scrum Master – to see how it would work. The rest, as they say, is history.

Final Destination

Good Scrum Masters always talk about how it’s their job to work themselves out of a job. If that’s the case, then eventually you’ll have teams that don’t have Scrum Masters. In those cases, there are certain responsibilities or overhead that the Scrum Master took care of which will now fall to the team. In those cases, the overhead work will need to be accounted for. From a Sprint Planning perspective, I think that cutting the velocity to account for 25% of a team member’s time for Scrum Master duties is entirely appropriate.

Thoughts?

That’s my response to the “25% Scrum Master guidance” from the SAFe training. Hopefully I was able to provide some context to show that it’s not as evil as you might have thought. Whether I was successful in addressing this concern or not, I’d like to hear your thoughts on the matter.

Continuing the Series
Part 3: HIP Sprints

A(nother) Response to SAFe Criticisms: Part 1

Full Disclosure: I am a certified Scaled Agile Framework (SAFe) Program Consultant (SPC).

Before you continue reading this somewhat lengthy, multi-part blog post, let me lay out the prerequisites. Well, really just the one. If you are not already at least somewhat familiar with Dean Leffingwell’s Scaled Agile Framework (SAFe) then this post is not going to be as meaningful to you. The official website for SAFe is http://scaledagileframework.com, although there are others out there (Andrew Blain, for example) who have done a good job of explaining what SAFe is.

Last year Dean Leffingwell (and SAFe in general) had a significant presence at Agile2013. In response, Ken Schwaber wrote a provocative blog post entitled “unSAFe at any speed”. What Ken failed to accomplish was to produce criticism that was any more founded than your run-of-the-mill angsty hearsay. He did, however, manage to set off a civil war within the Agile community over whether or not SAFe should be allowed in the Agile club or beaten until silenced or killed. I have been rather surprised at how many “Agilists” have chosen the latter.

Agile has always appealed to my inclusive nature. The goal is outlined in the Agile Manifesto and its 12 Principles. Anything that strives to deliver within the paradigm of the Manifesto and its Principles can be considered Agile. All approaches have strengths and weaknesses, and all approaches focus more on some aspects than others. In the end, though, all approaches are well-intentioned efforts to elevate teams to their potential. I think that’s beautiful, I really do.

A roadblock that has existed for years is that of large organizations who are not already Agile. Getting these behemoths to shift the way they work, much less the way they think, is no easy task. Many have taken the “All or Nothing” approach – either adopt an existing Agile approach in its purest form, wholesale, with no alterations, or surrender yourself to your competition, wither away, and die. Neither of these options is particularly appealing to most of these organizations, so they ignore Agile and continue their status quo.

Along comes Dean Leffingwell and SAFe and, all of the sudden, you have an Agile approach that the organization can use to become Agile. Of course it looks different from the other options currently available, but that’s kind of the point. It aims to establish Agile Principles and Lean Thinking in larger enterprises in increments that are actually realistic. Just as every Scrum team is different, every organization that adopts SAFe does so in its own way. And, just like Scrum, a lot of the implementation details cannot be neatly outlined in a guide or abstract for anyone to pick up and repeat without putting in any of the effort.

The reality of the situation makes the Purists out there really uncomfortable. A lot of criticism has been published. I am going to attempt to address some of this criticism. My intent here is not to get everyone out there to use SAFe. Heck, I don’t even intend for everyone to like it. My intent is to clarify a few misconceptions, first and foremost the one that SAFe is not Agile.

I’ll be publishing my response in multiple parts in order to accomplish this intent. The number of parts depends, at least partially, on you. I want to know what criticisms or misunderstandings of SAFe you would like me to respond to. I would further ask that you communicate with me as a respectful professional (and I’ll do the same). I’ve seen this topic get out of control without ever getting to root cause. Not that I have delusions of grandeur or anything, but I’d like to think that I can help find and address the root cause of these criticisms without it turning into a shouting match. I guess we’ll find out.

Series Posts:
Part 2: 25% Scrum Master
Part 3: HIP Sprints

Titles

I work for a company that is predominantly (for the time being, anyhow) NOT Agile. As a person who is passionate about Agile and leads one of three areas in his Division that are all-Agile, this wreaks havoc on my job title. Technically, my job title is "Systems Analyst". But I'm not that. That doesn't describe what I do at all, really. Maybe if you use "System" to refer to a team of people, as in Lyssa Adkins and Michael Spayd's teachings. However, that's not what the title is meant to refer to internally. So I'm stuck with the dilemma of how I describe who I am and what I do for the company.

Okay, I know I started this post out on a somewhat pessimistic note, but I have to be honest: coming up with my own job title has been fun. It's rather liberating to just make something cool-sounding up when you are asked what you do. One example of this is my LinkedIn profile, where I brand myself as a "SAFe RTE, Agile Evangelist, and Scrum Ninja". What does that mean? Exactly what it sounds like. I've also referred to myself as a Defender of the Agile Brand; Agile Enthusiast; Head of the Walmart Agile User Group (which isn't so much silly, as I really did found and lead the Walmart Agile User Group); and Über Scrum Master (I really like that one because the Ü looks like a ridiculously happy face). I also have a whole slough of non-Agile titles that describe me outside of my professional life, such as Dad, Brother, Son, Captain Obvious, and Snarky McSarcasticson.

Titles are a funny thing because they define so much of who we are, whether we want them to or not. In some cases, such as my "Systems Analyst" title, that can be a bad thing (read more about the cons of titles here). Yet I wouldn't refer to myself as anti-titles. I consider myself a proponent of creative, descriptive, and self-appointed titles. Your title should be part of your brand. If you don't live up to your title then it quickly becomes apparent and does you more harm than good, so it's in your best interest not to pick something entirely inappropriate.

What do you think? Are you a fan of titles? If so, what titles do you hold? If not, how do you describe yourself succinctly when asked what you do?

Normalized Story Points

UPDATE: 18 months later, I've reflected back on this topic in my post "Revisiting Normalized Story Points".

I was recently involved in a discussion on LinkedIn on the topic of Normalized Story Points and whether or not it was a good idea. What I noticed was that, despite what I think is a very clear explanation by the Scaled Agile Framework (SAFe), many people misunderstand both the process for normalizing Story Points and the intended benefit to be gleaned from this practice. If you have not yet, I encourage you to read the explanation in the “Iterations” abstract on the Scaled Agile Framework before reading on (the section entitled “Relative Estimating, Velocity and Normalizing Story Point Estimating”). That will provide the proper context for my thoughts, as a Certified SAFe Program Consultant and active Release Train Engineer, on what this means (and what it doesn’t).

First, how do we normalize Story Points? The gist of the process is this:

“1. For every developer tester on the team, give the team eight points (adjust for part timers)
2. Subtract one point for every team member vacation day and holiday
3. Find a small story that would take a about a half-day to code and a half-day to test and validate. Call it a 1.
4. Estimate every other story relative to that one.”

That’s basically it. The primary problem that teams run into is that they ignore step #4, along with the advice that follows these steps: “There is no need to recalibrate team estimating or velocities after that point.” This is a tool that has very specific benefits; it is intended for one-time use that allows for long-term benefit.

This means that teams within a SAFe organization are using a common practice to determine a baseline from which to begin relative estimation and, as such, will have Story Points that are roughly the same size. This will enable “just good enough” Story Point estimation of cross-team Features and Epics, which allows for more precise road-mapping and budgeting than we would otherwise have.

This does not mean that teams are estimating using Ideal Man-Days. They should still do relative estimation using the modified Fibonacci sequence. This also does not mean that roadmaps will be 100% precise; they will simply be more precise than what’s been available before. Budgeting will be precise in the sense that we float scope, not cost; however, the Epic Owner should only expect the Minimum Viable Product (MVP) and not necessarily every requested feature when the Epic has been initially estimated and not yet broken-down.

This means that teams establish how “big” a Story Point is early and don’t have to spend as much time figuring that out as a team. When I first became a Scrum Master, my team ended up having to re-baseline several times as they learned how to better write and slice User Stories. The alternative would have been either User Stories that were smaller than one point or multiple one-point Stories that were considerably variable in the amount of effort they actually required.

This does not mean that all teams will have exactly the same Story Point “size” or estimate exactly the same way. Every team is still unique and has their own dynamic that works for them. You will find, however, that the “size” of each team’s Story Point is close enough to allow for Program and Portfolio level estimating and planning.

This is not intended to take the place of established Agile practices for planning, splitting, and estimating the work that teams deliver. It is intended to get teams started in such a way that planning, splitting, and estimating can be done more simply and effectively across multiple teams. Once you establish your baseline, throw Ideal Man-Days out the window – it then becomes only a part of the criteria for relative estimation, along with complexity and uncertainty. Once you establish your initial velocity, throw the 8 Story Points per person per Sprint out the window – instead, use “yesterday’s weather”, current circumstances, and team growth to determine the number of points the team will commit to each Sprint.

Just like any other tool, metric, practice, meeting, or role that we use in Agile, the practices used for Normalizing Story Points have a stated benefit. We do not do things for the sake of doing them. Normalizing Story Points can have a tremendous positive impact on an organization practicing Agile at scale; a misunderstanding of Normalized Story Points can have a significant negative impact on that same organization.