How Should We Use Velocity?

19 April 2013

Beth Macy
BHM Consulting, Inc.

In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. Velocity is used in sprint planning to fill a sprint.

Velocity can be used as a guide for removing obstacles and roadblocks, increasing training, enforcing a firewall, predicting releases, descoping functionality, resource planning, and increasing product owner involvement.

So how reliable is velocity, and how can we use it?

Once established, velocity can be used to plan projects and forecast release and product completion dates. If a team is kept intact for approximately three months and on the same project for that period of time, then its velocity will stabilize within a range and be predictable for the duration of the project. Velocity, however, is not forever fixed. It varies from team to team and from project to project. A team velocity of .5 could be a better velocity than a team velocity of .8! Even if two teams are identically productive, one team's velocity will naturally differ from another. Why?

Team size

  • Velocity is calculated for the entire team. All other things held equal, larger teams will have faster velocities.

Project complexity

  • All other things held equal, teams on more complex projects will be slower than teams on lighter-weight projects.
  • Complexity of project may be complexity of requirements and/or technical complexity.

Lack of firewall

  • The following slows down a team's velocity:
    • Interrupts and multitasking
    • Adding and subtracting people from a team
    • Split resources

Uninvolved product owner

  • Having a product owner involved daily is optimal.

Obstacles and impediments that are not removed in a timely fashion

Sprint duration

  • Unequal length sprints will invalidate velocity.

The sprint burn-down is a graphical representation of velocity, so we can see why sprint burn-downs can vary a lot across projects. Burn-down is not work completed — it is time remaining. Scrum focuses on what is left to do versus what has been done. You can't undo what has been done, but you can course-correct and change what is left to do.

Velocity and burn-downs should never be used in a punitive manner. Team and individual velocities cannot be compared, nor should they be. Velocity is a guide for removing obstacles and roadblocks, increasing training, enforcing a firewall, predicting releases, descoping functionality, resource planning, and increasing product owner involvement.

Velocity and release planning

Once established, velocity can be used for release planning. Developing software is still based on the age-old principles of features, resources, time, and quality. Again, if a team is kept intact for approximately three months and on the same project for that period of time, then its velocity will stabilize within a range and be predictable for the duration of the project. Velocity, however, is not forever fixed.

Many corporations are concerned with product road maps, communicating upcoming functionality to customers, budget and resource planning, and other concepts that seem in odds with Agile development — but are not, if addressed early. Release planning is key to success in these models, and velocity is a key part of release planning.

Where does velocity come from? Before the first sprint, we guess. In the first sprint, the team accepts work based on gut feeling and discussion. After each sprint, we measure the velocity. After two or three sprints, the average measured velocity can be used to predict the velocity in the future, and thereby the completion date.

For the first sprint, guess using the entire team, including those doing the work. For future sprints, look at what team members will be assigned to the next sprint, and if they're the same as the previous sprint, use previous sprint velocity data to refine capacity estimates.

In order to plan a release, you need the high-level epics needed for the release. Many teams forget to add into release planning the "non-requirements" such as scalability, performance, quality, security, infrastructure, release source code control, builds, and roll-out. These hidden tasks take up resources and time.

The trick is to have a fully articulated but high-level, prioritized backlog. Now this epic-level backlog can be SWAG'ed to get a first, very rough (up to 200 percent of) estimate of potential release date and resources required. Velocity can be estimated for the team to get the approximate number of sprints required. The first sprint can be 60 percent or more off from the final average velocity, but, over time, average velocity can be used to refine release predictions.

Now to discuss a very controversial subject: using individual velocity for resource planning and training. In Scrum and Agile we encourage using the team and focus on team velocity. These concepts are based on having a firewalled team of interchangeable skill sets. However, in reality we rarely have that luxury. And as managers, we often are justifying our resources and fighting for more. To protect individuals and encourage teamwork, individual velocities should be kept guarded, except in open environments and team cultures where they actually can be made public as a way for others to see who needs help and therefore be used to help teams work together. I once had such a culture, where team members would first check to see if they could help in their sprint and their release, and if they really had spare time they then went to see if they could help other teams by checking the posted team and individual velocities. It was a wonderfully cooperative and open environment. Sadly, we don't see that often, and too many organizations are trying to use velocity in a punitive way.

However, individual velocity can be used to see who is critical path or who is drowning. I once was on a project where one of the senior developers worked very hard and produced solid code. He had a velocity of about one-third of a day's work produced for every day worked, and he was working ten-hour days! He was getting very frustrated.

The daily Scrum stand-ups showed that he had multiple interrupts because he was an extremely nice guy who just couldn't say no. After some one-on-one mentoring on how to say no and use humor to enforce his firewall, this developer's velocity jumped up to .84 days work for every elapsed day, and he scaled back to a nine-hour day.

On another project, the schedule looked very doable and the days remaining on the backlog looked achievable for team. However, this team had two people who were split across projects and therefore had lower velocities. When we looked at their time remaining, on the surface it looked achievable. However, when we took into account their actual velocity, it turned out they were critical path and would cause the schedule to bump out by a month. This was a great argument to upper management to hire additional resources into the development and QA groups, since these were two overloaded and highly leveraged resources (FE developer and QA).

So velocity, both team and individual, is a useful metric. Like all metrics, it needs to be used with caution and only for the good of the team and the project. Use it as a way to make things better, as a way to forecast what remains to be done.

Article Rating

Current rating: 5 (1 ratings)


Michael Brashier, CSM,CSPO, 4/19/2013 1:00:51 PM
I'm not sure that your two examples indicate a need to track individual velocity. With the developer being interrupted often, a Scrum Master should be well connected to the team and see a high number of interrupts. Once identified the SM can correct the problem.

On the example of team members split accross projects. It goes without saying that this is very bad for Scrum teams. Given that some companies will not correct that problem, you should still be able to use that team's past velocity (the actual velocity) for release planning. If two team members had lower velocity, didn't this empact the team velocity?

Tracking individual velocity can bring on problems. If the team knows (and they usually do) it lowers the team spirit. It can also lead to team members gaming the numbers.

The only time I can see tracking individual velocity as helpful is if you have a single resource that is the only resource that can work a type of story. This is a resource problem and should be addressed that way.
Beth Macy, CSC,CSP,CSM, 4/20/2013 6:09:11 AM
True, but sometimes in some companies, upper management can only be convinced by hard data and using the individual velocity in was the only way that the point was proven. In the first case, the worse offender of interrupting the developer was his manager. In the second case the team had been trying to point out the resource issue for over a year. The Scrum Master HAD been trying to fix the problem but was beating his head against the wall. Knowing the company culture is key to whether you use this metric or not and it should be used sparingly. Tracking individual velocity can be a demotivator and teams can game the system. But it's a wonderful thing when you can use it to the good. I have seen more misuse than good use of this metric, but when you can use it, it's a good tool to have.
Kapil Dhawan, CSM,CSPO, 4/22/2013 10:49:29 PM
Hi Beth,

You mentioned "Larger teams will have faster velocities". To me, Larger team means more communication channels, more time required to take decisions etc. There should be an optimal number depending upon kind of work, skill set available and other factors. Less or more team members add delay.

Lack of firewall should automatically get highlighted in Daily Scrums.

I find more cons of using Individual velocity than benefits. This should get highlighted in daily scrum in one form or the other. It is Scrum Master's job to take note of such cases and act accordingly.

You must Login or Signup to comment.