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.

Releasing

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.





Get Your Estimation Guide




Would you like to know if custom software is right for you?