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.

Understanding Agile Planning

One common myth about Agile is that those who practice Agile don't plan. I've found the opposite to be true: those who truly understand Agile are planning all the time. The difference is that the planning they do is much more lightweight. They also anticipate change, rather than pretend it doesn't exist, resulting in plans that are living documents instead of notarized relics. Their plans are always accurate, but with varying levels of precision. How do they do this? Using one of the simplest, most powerful planning tools out there: the backlog.

The Backlog
A backlog is really nothing more than a prioritized list. If you've ever made a To-Do List (or its popular cousin, the Honey-Do List) then you've made a backlog. If your backlog was short, you probably got a lot done and felt a great swell of accomplishment. If your backlog was exhaustive and poorly prioritized, you probably got overwhelmed and did little to "move the needle".

Levels of Planning
I'm tackling this from an enterprise view of Scrum, but the concepts are the same regardless of how many levels you use or the terminology you pick. In general, an enterprise using Scrum should have five levels of planning.

Levels of Planning

I'm not the first to notice these five levels, so I can't take credit for the concept. The idea is that you start with a Vision that serves as your "True North". Everything that you do should align with your Vision, and your Vision statement should be updated infrequently. At this level, you're looking at Themes or Strategies that execute the Vision at a very high level.

Everything in your Roadmap - lets call them Epics - should align to one or more Theme. You may call it something different, and the word Epic may mean something different to you. When I say Epic, I refer to a set of one or more Features that provide significant strategical value to your organization. Waterfall project charters usually consist of one or more Epics as I've defined them here. Your Roadmap may go out 3-5 years or more, but becomes more "squishy" the further out you go. Roadmaps should be revisited at least quarterly and updated whenever necessary.

Releases should align to the Roadmap and should consist of one or more Features. When I say "Release", I'm referring to a production release with significant functionality. If you're in a shop that employs Continuous Delivery, this would obviously not refer to the type of release that happens multiple times each day; perhaps the word "Release" doesn't even make sense in that context. Regardless of the term, this is the level that is easiest for end-users to understand. Everything above this level is too abstract, and everything below this level is too granular.

Sprints should have goals that align with the Release plan. The Scrum teams do this by committing to User Stories that contribute to the completion of the next Releases Feature(s). My recommendation for Sprint Duration is two weeks. I've tried 3-week, 4-week, and month-long Sprints and I didn't care for any of them. Two weeks seems to be the sweet spot. Changes to the Sprint plan should be kept to a minimum, especially if the team is a less-mature Agile team. Again, the mechanics of this change for Kanban, DevOps, or similar teams.

At the lowest level, the team aligns in their Daily Scrum on how they will work together to accomplish the Sprint's goals. They may be aligning in the context of tasks, which may or may not be planned out at the beginning of the Sprint, but they are not likely to be discussing their daily work in terms more abstract than User Stories. After all, they know how their Stories are tied to Features, how those Features are tied to Epics, and how those Epics are tied to Themes; there's no reason to revisit the higher levels every day.

The Planning Engine
The mechanism for moving work intake to something that's actionable is actually quite similar across all levels. The cadence, level-of-detail, and people involved may differ, but the process is essentially the same.

1. Discuss the item
2. Estimate the item
3. Prioritize the item
4. Implement or Decompose the item
• If Decomposing, the sub-items are fed to the next level down and the process repeats at step #1.

At the team level, this is done in the Backlog Grooming sessions (or, as I like to call them, "Story Time"). The same concept can and should be used at the other levels of Planning, simply modified to be appropriate for said level. For example, you may have more executive people meeting quarterly to groom the Epic backlog; you may have representatives from each Scrum team in a product area get together monthly to groom the Feature backlog; and you may meet as a Scrum team each Sprint to groom the Product (User Story) backlog. Use whatever cadence and team members that makes sense for your organization and circumstances.

A SAFe Approach

If you're familiar with the Scaled Agile Framework (SAFe), then you know that what I just described is accounted for in their Big Picture. If you wanted more advice on how to implement this planning engine then I recommend you view the abstracts found on their website. I've found their advice to be very useful and pragmatic.

You can implement the five levels of planning with a backlog-driven planning engine without SAFe. Indeed, there are many non-SAFe Agile companies that have established an Agile planning process before the advent of SAFe. I'm simply suggesting that, if you're new to this and don't know where to start or if you're in the middle of this and struggling with what you have, check out what SAFe has to offer. Take what works for you and toss the rest.

A Rose by Any Other Name...

As I stated at the beginning, mine is only one perspective on Agile Planning, and the terms I use may be different (or defined differently) than what you use in your organization. I would love to get your perspective on how Agile Planning can be done. After all, I'm always on the lookout for better, more Agile ways to do things!

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

Descriptive versus Prescriptive

“Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.” -Martin Fowler, Agile Manifesto signatory, from his October 2006 blog post, “Agile Imposition”

As a member of the SAFe community, I've heard and experienced a lot of concern and displeasure with what is perceived as a highly prescriptive Agile framework. However, having actually met and worked with Dean, Colin, and Alex, I have never felt they were trying to shove a framework down my throat. To me it felt more like "your organization is new to Agile and we come with decades of experience; try this framework on, including all of these recommended practices, see how it fits, then tailor it accordingly." Granted, that vibe came from face-to-face conversations, not websites and white papers.

This problem is not unique to SAFe. Pure Agilists have always pushed for a more "hands-off" approach. It's interesting to me how married some of agilists become to a certain methodology - conversations with these people usually boil down to "you should let people do whatever they want, but if you're a good coach and they really get the principles then they're most likely going to go with my favorite methodology." This is often coupled with, "I also offer Agile Coaching services..." The problem is, they've got a point about the coaching. You can't leave teams all to themselves; you have to support them somehow. I'm not saying all Agile teams need a dedicated Agile Coach, but they need the resources necessary to ensure the direction in which they adapt is in accordance with Agile principles and the environment that will support them when (not if) they fail.

Many of my thoughts on this subject have recently been affected by the information I was recently exposed to at OpenAgileAdoption.com. One of the references cited is Martin Fowler's "Agile Imposition" - an article written nearly seven years ago and more relevant now than ever before. Of course, Fowler and Open Agile Adoption are both focused more on organizational transformation than prescriptive frameworks, but I think the principles still apply. It all boils down to enacting change through influence but without mandate. It's a principle that every good Scrum Master is already familiar with - Servant Leadership. You've got to not only lead the horse to water but get them to realize just how parched they are!

So how do you do this within the context of a framework? My opinion: change the way you say what you're trying to say. More specifically, make it clear why you recommend certain practices, when they're relevant and highly likely to improve results, and when it might make sense to try something else. You're still going to lay out the recommended practices, but you'll be taking a descriptive approach to explaining them rather than a prescriptive approach.

The Scrum Alliance uses the term "Common Practices" instead of "Best Practices" to describe what would traditionally be considered "Best Practices". By changing the term they change the reader's perception. They're not saying "you need to do this or you can't be considered among the 'best'"; they're saying "this is something that a lot of people do in this situation, and here's why." That's the approach the entire industry needs to be taking. I would bet that many framework authors already think that way. The problem is that way of thinking is not reflected in their writings.

What do you think? Does this resonate, or am I way off base? How would you expect websites and other communication regarding what are typically seen as "prescriptive frameworks" to change to be more in line with a descriptive approach?

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.

Conversation

Many Scrum practitioners don't realize that Scrum did not invent the idea of User Stories - XP (eXtreme Programming) did. They are, however, often familiar with Ron Jeffries' "3 C's of a User Story", namely Card, Conversation, and Confirmation. The more I train teams on User Stories, the more convinced I am that the Conversation aspect is the most important of the three, and it is applicable to all things Agile, not just User Stories.

I recently facilitated PSI Planning for my area's Agile Release Train (Potentially Shippable Increment). I’ve noticed that, with each new PSI, the teams become more concerned with extensive pre-planning. They try to get more out of the meeting by doing as much of the actual planning before arriving at the meeting. Unfortunately, they do not understand that the primary reason for PSI Planning is not to generate a plan as much as it is to have conversations. Teams must communicate and align with each other and their customers. They must examine their work to determine what dependencies and risks are inherent in the work so that they can communicate, manage, and mitigate them as much as possible. This process happens to produce a better plan, which is why we do it. However, those who come to the event with pre-determined plans often find they must be reworked or scrapped altogether.

Rework manifests itself as delay, and delay indicates waste. Agilists hate waste. In fact, an Agilist’s views on waste and rework can be found in the 10^th principle that accompanies the Agile Manifesto: “Simplicity – the art of maximizing the amount of work not done – is essential.” How do conversations help prevent rework? If we talk before acting then we get a better sense of the truth, established in an environment of shared context. Conversations mean multiple perspectives, which bring difficult questions and challenge our assumptions. They force us to produce something as a group that is better than could ever be produced in a silo. They reinforce the paradigm of “just enough, just in time” instead of “big up-front”.

Once I realized that conversations are integral to Agile, I began to review the tools and practices within Agile, specifically Scrum, for conversations. All of the prescribed ceremonies – Daily Scrum, Sprint Review, Sprint Retrospective, and Sprint Planning – center on team conversations. Pair Programming and Test-Driven Development are XP practices that rely heavily on communication, both within the development team as well as between the developers, testers, and customers. A good Scrum Master helps the team most by facilitating conversations, and the Product Owner’s backlog is meaningless if they don’t ensure the team understands the work. There are conversations baked into literally every aspect of Scrum!

Conversations are often overlooked because people do not view simply having the conversation as an objective in most cases. They focus on the stated outputs: plans; acceptance criteria; status updates; confirmation of stories completed; etc. Consequently, it is not uncommon for teams to find alternative means to deliver these results without the “overhead” of the conversations. They rely heavily on tools and individual efforts to maximize their time without hindering the team with human interaction. They may, at first, feel an increase in productivity as the perceived burden is lifted. Yet, inevitably, they find themselves struggling to deliver quality quickly and do not understand how Agile could betray them so. Hopefully they have a good Scrum Master or Agile Coach watching them adapt in the wrong direction that can have them take a step back so they can see the error of their ways. If not, it becomes easy to blame their frustration on Agile and revert back to their comfort zone of more “traditional” methodologies.

As a safeguard, I recommend teams, and especially Scrum Masters, go back to their roots frequently to make sure they’re staying true to the founding principles that make Agile methodologies so great. Remember that “business people and developers must work together daily throughout the project,” and that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Don’t just blindly follow a framework or practice; instead, try to understand why you are asked to do things a certain way. If the purpose that you perceive is not aligned with the Agile manifesto and its accompanying principles, you’re probably wrong. Acknowledge your failure, “Fail Fast”, and change your approach so that it fits the Agile paradigm. It may seem counter-intuitive at first, but it will pay off in the long run.

Bottlenecks: the Enemy of Agility

I am the Release Train Engineer for one of my company’s first Release Trains. One of my early struggles when we first adopted the Scaled Agile Framework was understanding what the responsibility of the System Team was and how to concisely articulate it to others. That understanding finally came during the Quick Start event where I heard Alex Yakyma say the System Team identifies, manages, and eliminates bottlenecks. What a powerfully simple mission! I’ve since dedicated time to understanding and helping the team understand what that means, and this is what I’ve come up with so far.

First, how do you identify a bottleneck and what does it mean to be a bottleneck? Sometimes this can be rather obvious, but often it is difficult to separate the symptoms from the root cause. This can be a process, practice, culture, etc. I have come up with a process to help myself and my System Team identify bottlenecks.

First, envision what it would be like if we could deploy to Production a dozen or more times per day. Not that we would, necessarily, but what would it take to be able to roll new functionality to Production the same day we get the request? Second, document our current process and lead time from conception to Production. Third, identify the gaps between our current process and the ideal of Continuous Delivery.

If you find yourself defining symptoms and not the root cause, start using a Lean perspective and start asking “Why?” For example:

“It takes too long to get a package to Production once it’s been approved.”
“Why?” “Because we have to find someone who has the bandwidth to get it deployed.”
“Why?” “Because we do not have an automated deploy process in place.”
“Why?” “Because our application runs on WebSphere in a Mainframe environment, and we can’t set up auto-deploy until it’s migrated to a Linux environment.”

Here we have identified the primary bottleneck – the environment on which our application lives in Production – by asking 3 “Why”s. Expect to ask as many as 5 “Why”s before getting to root cause.

Next, we need to time box the bottleneck. This basically means you’re going to work with what you have for the time being and basically “deal with it”. This is a temporary phase until you are able to eliminate the bottleneck. You should have a timeframe for how long it is acceptable to manage a given bottleneck and hold yourself to that timeframe. You may not always meet your goal, but time boxing is the first step in giving the bottleneck some form of finality.

Last, we need to eliminate the bottleneck. The easiest solution is to just do away with it – stop doing it outright. This is also usually the least feasible. The best solution is usually automation, simplification, or combination. If you can automate it, automate it! This way you’re not diminishing the task, you’re making it take less time. If you can’t automate it, see if you can apply Lean thinking and simplify it somehow. Can you get what you really need with less? Agile encourages just-in-time and just-enough to limit the amount of waste we allow in the software development process. One of the backing principles to the manifesto states “Simplicity – the art of maximizing the amount of work not done – is essential”. Finally, if you can’t automate or simplify the task, see if you can combine it with another task to “kill two birds with one stone”. Pair Programming, an XP practice, is a great example of this – you’re essentially rolling your development, code review, and knowledge sharing all into one activity that typically doesn’t take any longer than development normally would.

Once you’ve eliminated one bottleneck, repeat the process indefinitely. Kaizen mindset tells us there’s always room for improvement and it’s always urgent that we improve. By all means, take the time to acknowledge and celebrate your improvement, but don’t get complacent.