When teams are completing more stories faster, managers tend not to worry. That's not true when velocity falls. Velocity will decrease, however, and there are many reasons why.
What Is Velocity
Velocity is an indicator of what the team has been through. It is a historical metric that informs planning. It is an attempt to capture, "how quickly can the team get work done?"
Velocity is calculated by adding the number of units of work completed in an iteration. This can be story points, number of tasks, or ideal engineering hours or days. Since iterations are often short a lot of noise can be introduced in this metric. That is why it is useful to look at the average velocity over the last few iterations
Example 1: A team that uses story points
The team has completed five iterations. The number of story points completed in each iteration are: 20, 17, 22, 12, 28. Their velocity is 19.8 points/iteration.
Example 2: A team that uses idealized engineering days
The team has completed five iterations. The number of days completed in each iteration are: 45, 20, 35, 37, 43. Their velocity is 36 engineering days/iteration.
Both teams will see changes in their velocity. Both teams will benefit from understanding the cause of the change in velocity. Lower velocity from sprint to sprint may be normal and healthy, but it may also indicate that something needs to change.
Adding a Team Member
Adding a team member, just like hiring a new employee, is an investment in the team or company. Investments are expected to pay off over time, but there's a startup cost. That startup cost is reflected in a lower reported velocity.
A little slowdown while new members get acclimated to the problem space and the technology being used is normal and not generally a cause for concern.
Before a release, production bugs do not exist. There's not a chance of losing customer data or rendering the product unusable. When money is on the line and customers can be lost, some bugs must be fixed quickly.
These are valid reasons for having developers drop everything and fix a bug. There is also overhead in making that switch. That interruption to flow didn't exist before the release, so it could never impact velocity. At retro the team may need to refine their bug reporting, triage, and fixing process.
Some teams don't track the time taken to fix bugs. In that case bug fixes will have an invisible infulence on the team's velocity. If the team fixed more bugs than normal in a sprint, velocity will decrease. If they fixed fewer bugs than normal, velocity will increse. Other teams treat bugs like every other story. On those teams it could be there are too many drop-everything-and-fix-this bugs and the triage process needs attention.
Work Is Unevenly Distributed
After a release, senior or lead team members sometimes find that they are the only ones trusted with special access. This oftem makes them the only developers who can answer certain questions or fix certain problems. That is time when those team members aren't contributing to completed stories. The team can develop tools to let any member solve those problems, but the change in velocity may be the tip the team needs to recognize what is happening and work toward the correct solution.
Without titles, people may develop affinities for working in certain areas of the code. Often this is seen as a steady or even increasing velocity as people develop special knowledge. When this happens slowing down may be the right thing to do. That way the team is not dependent on a few people and everyone can use their vacation time.
And the Worrying Ones
There are unhealthy reasons a team's velocity may be falling. A death march, a lack of focus, or an unclear direction are all examples we'd like to avoid.
Again, retros are key for providing a context to help understand the change in velocity. The decrease in velocity doesn't necessarily indicate any of these problems.
If the velocity is decreasing for a worrying reason, that is not the final word on the project. All of these problems can be recovered from.
You Can Finish on Time
If you find not as many stories are being completed every iteration, it may be time to step back and adjust your plan. Regular retros help keep the team on track. Reporting the team's velocity at those retros can help the team adjust and stay headed in the right direction.
Adapting is at the heart of an agile process. Plans change. Velocity is just one metric that helps inform that change.
A Guide to Estimation and Velocity
If you are feeling the pressure of hitting a deadline or accurately estimating your budget, this free guide can help you.