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?
- Velocity is calculated for the entire team. All other things held equal, larger teams will have faster velocities.
- 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
- 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.