What Are Your Team's Velocity Values?

For any agile-based operation, you can introduce the concept of "velocity values." Depending on the organizational culture, these values may come as monetary rewards, recognition, or other incentives. This can go a long way toward helping management understand how their respective teams work and can provide great insight into mentoring at both the individual and team levels.

A few years ago, I found myself in an ad hoc encounter with a number of individuals who were very angry at the current state of affairs for the highly visible agile program they were working on. Across the organization, everyone was frustrated that the program had not yet been released into the open market. Sales people were attempting to sell an application that didn't really exist. Marketing wanted to push press releases out into the public space with delivery dates. Executives were seeing what should have been a revenue generator turn into a revenue drain. Delivery managers at multiple levels couldn't figure out what to do as defects being found in higher environments vastly outnumbered new capabilities that were being delivered to those environments. Team members were looking for any way out of their current predicaments, which included leaving the organization entirely. In essence, everything was a mess.

And then I heard a comment I had to write down. Paraphrased, it was, "Team members should always want to increase velocity if they want to keep their jobs."

The comment, articulated by a senior manager at the time, summarized the current state of affairs on multiple levels. Continually increasing velocity meant that people could stay gainfully employed. What was unfortunate and somewhat disheartening at the time was the organization itself. This organization had started its agile journey approximately three years prior and had seen some success within other areas of the company. However, the success didn't resonate across the board for everyone, and the frustration was apparent.

At the time, I wasn't in a position to do much with or about the statement. However, since then, it’s given me ideas that can help agile-based practices.

Now, whether I'm working with a new or existing agile organization, I'll look for ways to introduce the concept of "velocity values" at the team, program, portfolio, and organizational levels. Like many other agile practitioners, I believe each team should develop its own characteristics and subculture. I also encourage each team to develop its own velocity values and share that information throughout the organizational structure. This can go a long way toward helping management understand how their respective teams work and can provide great insight into mentoring at both the individual and team levels going forward.

Velocity at the team level will fluctuate based on a number of different factors:

  • Unplanned team member outages (sickness, emergencies, etc.)
  • Planned team member outages (vacation, holidays, etc.)
  • Quality and consistency of story refinement (success criteria, acceptance criteria, diagrams, etc.)
  • If used, consistency of story sizing (points, T-shirt, etc.)

These factors will affect velocity on an iteration basis. Yet, even with these considerations in place, I believe that encouraging teams to discover their own velocity values can be a very positive step in shaping their own agile-based culture.

Below are some examples of velocity values I've seen and heard articulated by teams I've worked with in the past. This is by no means the best list or even a complete list. These are just examples to share based on my experiences up to this point.

User Comments

Tim Baffa's picture

I disagree strongly with the intent of this article.   As agile practitioners, we should strive to ensure that team velocity is never used as a measurement of team performance (i.e. - increasing on a sprint by sprint basis).

Team velocity should only be used as a tool to both give the team insight into their iteration capability, and to aid management in short and long range planning, provided that the backlog is adequately stacked with estimated stories.

Team velocity can easily be "gamed" to increase sprint to sprint  - just have the team bump up their SP estimating.   No management "oversight" can prevent this, no matter what the author claims.

Heck, if I served as a Scrum Master for a team that was given the incentive to increase their velocity, I would just propose to the team that they double their SP estimates.   The fact that these numbers can be manipulated like this should clearly indicate that they should not be tied to any incentive-based program.

One final thought is whether the author has read any scientific studies around incentive-based performance, because the science proves that if cognitive effort is involved, incentive-based performance is consistently worse than the performance of those that are not incentivized (Read Daniel Pink!).

July 31, 2014 - 4:20pm
Johann Auer's picture

Hi Tim,

I have to disagree with your response. In an attempt to increase velocity by simply bumping up the estimation will not cause velocity (i.e. performance) to increase. Changing the estimation size without increasing velocity will simply cause less items to be worked on in the Sprint backlog.

I do agree however with you that metrics alone are no indication of success for increasing velocity but only one of many areas to increase team performance. Organizationa culture, governance play an important role, and most importantly simply lving up to the scrum values will gurantee success. What you are suggesting also provides no room for continuous improvement.

July 31, 2014 - 6:57pm
Tim Baffa's picture

Thank you Johann for your reply.   Perhaps my post was unclear, so let me try to state my view a little more clearly and concisely:

Team improvement is paramount,.   There are many disciplines and methods that may improve productivity and communication. Some improvements will increase team velocity, some improvements may not.   Still, the focus should always be on improving (12th agile principle).

Velocity should never be discussed or published outside of the team or immediate stakeholders.  

Velocity comparisons should never be made between teams.

Velocity should never be the focus of any analysis around team performance.  

Velocity is a "reflective metric", representing past team productivity, and may be used as one of many tools supporting future estimation.   Never should the goal of any organization be defined as "improving team velocity".

Improve team productivity?   Yes.   Improve internal and external team communication?   Yes.   Improve velocity?   No.

August 4, 2014 - 12:52pm
Lukasz Szyrmer's picture

There's a fundamental misunderstanding in the executive's original comment:  "Team members should always want to increase velocity if they want to keep their jobs."

Velocity is a backward-looking statistical measure. If anyone, particularly an executive, starts to try "managing the velocity" and using it as a metric to set organizational goals, they start to distort the system. Velocity is meant only to be a tool for awareness and discussion. See http://www.infoq.com/presentations/agile-quality-canary-coalmine

Not only that, there's a lot of dysfunctional organizational behaviour around metric-driven goals. The book Drive goes into a lot of examples. 

August 1, 2014 - 5:20am
Rusty Neal's picture

Once you turn a metric into a goal you have destroyed it as a metric.


Velocity is an average number that should ONLY be used for planning, never as a target number to hit in a sprint.

August 1, 2014 - 11:18am

About the author

Eric  King's picture Eric King

Eric King has over 20 years of professional experience in both the software development/implementation industry as well as the financial services industry. Eric has extensive experience as an implementation analyst, project manager, technical delivery manager as well as a professional services manager. From a methodology perspective, Eric has experience in Six Sigma, Six Sigma Lean, Lean Methods and most importantly; Agile. During the last three years, Eric has personally witnessed where teams have recognized tremendous success using Agile methodologies.  In addition, he’s seen numerous challenges at the team, department, division and organizational level as well. One of Eric’s current passions is helping functional managers and executives understand why moving outside of their current role(s) is a critical component for any successful Agile transformation.

Eric’s passion for helping others lead him to expand an Agile training/education program with a previous employer prior to joining Davisbase. He also became a published author with the ScrumAlliance back in April of 2012 and continues to proactively write articles for publication based on his experience and desire to share “learned outcomes” with others. Eric believes that Agile is not a stagnant methodology, but one that should be constantly evaluated and challenged. As such, he constantly asks students to “think differently” in their Agile journey and often challenges students in his classes to take their experiences to a higher level.

Eric believes that Agile practicioners need to possess a number of key characteristics in order to be highly successful. As such, he constantly strives to Coach, Teach, Facilitate, Mentor and Educate individuals, teams and organizations as they begin their own agile transformation.

Eric holds undergraduate degrees in Finance/French from the University of South Dakota and an MBA from the University of South Carolina.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!