Jeremy Jarrell

Agile Made Simple

Tag: velocity

The Destination Is The Goal, Not The Journey

Many organizations try to measure a team’s progress by their velocity, or at least, to conflate their velocity with their goal. But, velocity is not their team’s goal. A team’s…

Many organizations try to measure a team’s progress by their velocity, or at least, to conflate their velocity with their goal. But, velocity is not their team’s goal.

A team’s goal should be a specific and measurable piece of business value that the team plans to deliver within a certain timeframe. For example, some great ideas for goals might include a new feature set that sets your product apart from its nearest competitor or a fresh look and feel and for an older feature set. Or, rather than being user-facing, a valuable goal might the delivery of a new capability or service that’s useful to the rest of the organization, such as a significantly improved build pipeline.

Whatever the goal may be, high-performing teams clearly define the goal that they intend to achieve at the outset of each sprint so they have a shared understanding of the objective that they will all be striving towards.

Velocity is different

Velocity, on the other hand, is simply the sum of the estimated effort that the team completed during the sprint in pursuit of their stated goal. For example, imagine that during the last sprint your team completed the following stories:

  • Story A: 3 points
  • Story B: 8 points
  • Story C: 5 points
  • Story D: 1 point
  • Story E: 1 point

Based on this list, we know that your team had a velocity of 18 points in the last sprint.

Was your team’s overarching goal to deliver 18 points the last sprint? Probably not. Most likely, your team’s goal was something that held the promise of a more tangible piece of business value, such as a social sign-on capability to encourage more users to create accounts, or a streamlined build process.

The 18 points of velocity that your team achieved during that sprint was nothing more than a byproduct of the progress that they made towards their goal. This is because, by itself, the act of delivering 18 points yields no value to your organization. At it’s best, it might serve as a correlation to the value that your team produced during the same timeframe, but only if you assume that your team had only selected high-value work to tackle during that time.

Making this stick

If this sounds familiar to you, then you’re not alone. Most agile coaches find themselves repeating this point on a regular basis. But, despite how many times most organizations have heard this story, it simply never seems to stick. So, in hopes of making this stick, let’s look at an analogy to this problem based on another problem that you probably already intuitively understand.

Imagine that you’re planning a trip to the beach with your family. Your entire family has been looking forward to this trip and are anxious to arrive. However, the beach is far from your home and it will take most of a day to drive there.

You’ve done some initial planning using your GPS and have discovered that the beach is 520 miles from your home. You also know from your experience with previous, similar trips that you can cover about 65 miles per hour in your car. This means that, roughly speaking, it should take you about 8 hours to drive your family to the beach…or 520 miles divided by 65 miles per hour.

If you relate this problem to our previous discussion then it should be easy for you to recognize that your goal is to arrive safely at the beach. The 520 miles between your home and the beach is simply an initial estimate of the effort required to achieve that goal. And finally, the 65 miles that you expect to cover per hour is your forecasted velocity per hour, based on similar trips in the past.

Simple right?

Simplicity, meet reality

If you’ve ever taken a long-distance trip then you probably know that trips are rarely as simple undertakings as they first seem. Although we may start our trip with the best-laid plans many unexpected events often emerge to disrupt those plans.

For example, your initial estimate of a traveling speed of 65 miles per hour most likely assumes that the majority of your time will be spent traveling at a constant speed on the interstate. But, few of us are lucky enough to have an interstate that runs directly from our front door to our favorite shoreline. As a result, you’ll most likely have to spend a bit of time at the beginning of your trip and the end of your trip traveling on secondary roads. This means that you should expect to travel less miles than you’d originally planned during those times, which means that you should also expect some variation in your speed throughout your trip.

In addition, even the most ambitious amongst us wouldn’t attempt an 8 hour trip with our families without a few short courtesy stops for everyone to stretch their legs. In fact, most of us would even grant a longer stop for lunch.

But most importantly, every great travel planner knows to expect the unexpected. Traffic jams, road closures, out-of-the-way detours, or even inclement weather can all emerge to slow you down while pleasant surprises like unexpected shortcuts can give you a boost in the right direction.

Any trip offers the possibility of unexpected developments, any one of which could affect your overall travel time. In fact, the longer the trip, the more possibility there seems to be for those plans to go awry.

Remembering the goal

If you’ve ever taken a long trip, then none of the twists that I threw at you in the example above would have been surprising. Difficult road conditions? Sure. Inclement weather? Of course. Unexpected stops along the way? Absolutely.

But, if you’re like most people, when I gave you my first estimate of 8 hours of travel time, which I arrived at by simply dividing our expected effort by our average forecasted velocity, these types of issues were probably the furthest thing from your mind.

However, even with those unexpected developments, if you arrived at the beach safely then you’d likely still consider the trip a success. This because arriving at the beach is your ultimate goal, not the trip to it.

If your goal had simply been to drive 500 miles in your car, then you could have just driven 250 miles in one direction out of your front door, turned around, and drove 250 miles back. Or, if your goal had only been to spend 8 hours in your car, then you could have just driven in circles around your block for 8 hours.

When applied to analogy like this the idea of driving circles around your block for 8 hours and considering that a success seems ridiculous. “Of course I wouldn’t do that” you say, “the goal was to get to the beach…not to spend some arbitrary number of hours in my car driving aimlessly.”

But if this is the case, then why is it that so many organizations judge the success of their teams only on whether that team closed an arbitrary number of points in a given a timeframe with little regard for the work the team ultimately produced while earning those points?

The next time your organization holds a sprint review in which the focus is solely on the number of points closed rather than the value that those points delivered, remember: the destination is the goal, not the journey.

Want to learn more about how to make agile work on real teams? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of their agile adoption.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on The Destination Is The Goal, Not The Journey

Measuring The Value Of An Agile Team

Measuring the value that an agile team creates is one of the biggest challenges that teams who are new to agile often face. And while many agile methodologies put an…

Measuring the value that an agile team creates is one of the biggest challenges that teams who are new to agile often face. And while many agile methodologies put an emphasis on focusing on those activities that are most likely to yield value for your organization, how to actually measure that value often remains a question.

For many agile teams, especially those using the Scrum framework, velocity is often the first place we look. But is velocity really the best measure of the value that a team creates?

What’s Wrong With Velocity?

Velocity is often described as a measure of the amount of work a team delivers in a given sprint, but this description isn’t entirely correct. Rather than a measure of the amount of work a team delivers, velocity is actually the sum of the estimates of each story that the team delivered during that sprint.

Let’s look at an example. Imagine during the last sprint your team delivered the following 5 stories.

The total of the estimates of all of those stories was 21 points, which means that your team’s velocity for the last sprint was also 21 points. But does that mean that your team delivered 21 points worth of value? Not necessarily. The points that we’ve just described are estimates of a story’s complexity, which doesn’t always correlate to a story’s business value. For example, the previous sprint’s most complex story, which was the story to update the admin portion of the app to support color blindness mode, was estimated at 8 points. However, just because this was the most complex story undertaken in the sprint doesn’t necessarily mean that it was the story which produced the most business value.

By comparison, the story to add American Express as a supported credit card was estimated as the least complex story in the sprint at only 2 points. However, due to the potential for additional revenue this story may have been one of the most valuable stories delivered in the entire sprint, despite its relative simplicity.

What does it mean that our most complex story was one of our our least valuable while our least complex story was one of our most valuable? It tells us that velocity isn’t necessarily correlated to the value produced. In fact, this example tells us that it may not even be a reliable proxy.

Changing the Conversation

To measure the value that an agile team produces you must shift the conversation away from your team’s productivity and towards the value that your team actually creates. But to do this, you must have at least an initial understanding of how that value is created.

Sometimes this can be easy, as in the case of a story that may result in increased usage of your product or even in direct revenue. But other times, it may not be as easy. Sometimes the ultimate goal of a story is not to increase revenue, but instead is something more tangential. For example, some stories are written with the goal of streamlining an existing workflow inside of a product, improving the perception and awareness of a company’s brand, or simply making an existing process inside of an organization more operationally efficient.

Measuring the impact of these kinds of stories can be difficult and that difficulty only increases if the impact must be measured soon after a story is delivered. So, how do you measure the impact of these types of stories?

Understanding The Value Your Stories Will Create

The most important point to remember is that if you don’t have at least an idea of how to measure the impact of these stories then immediately stop where you are. Everything an agile team does should be in support of maximizing the value that they produce for their organization. This means that if you don’t have at least an idea of how to measure the value of what your team will be creating then you don’t understand your end goal well enough to continue to invest in it.

If this is the case, then take a step back and consider what the value is that you’d like each story to produce. Once you have an understanding of what that value is then you can begin to brainstorm possible ways to actually measure that value after delivery.

It’s important to realize that your first idea of how to measure the value produced in these cases doesn’t have to be correct. In fact, measuring these types of stories can be so difficult that you’re unlikely to get it right the first time. But to learn from that experience you need to consider why your first attempt was wrong and what you could do differently to measure that value more effectively. Like most things in an agile, learning to measure the value produced by stories that don’t directly produce value themselves is often an iterative process. However, this iterative process not only results in the right answer, but also teaches you more about the value your stories are creating along the way.

Making the Most of Measuring

A high-performing agile team will almost certainly produce value for your organization, but understanding how much value they create isn’t always straightforward. Worse, it can often be easy to conflate metrics such as velocity, which are intended solely for the team's own use for forecasting and planning, with the amount of value that the team is producing.

But by using the opportunity to measure the value that your team is producing as a chance to uncover what that value truly is, you can be sure that your team will always be producing value for your organization.

Want to learn more about getting the most out of agile with your team? Check out my course, Agile in the Real World, for tips and techniques for making agile work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Measuring The Value Of An Agile Team

Type on the field below and hit Enter/Return to search