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

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.