Help Your Team Understand Its Velocity

So, you’ve got teams doing agile and you want to check that they’re OK. What do you look for?

Teams should be working toward a target velocity that is based on historical evidence. There may be times when this figure needs to be adjusted based on factors such as team availability, but teams that understand their velocity know that it is a good indicator of what they are capable of achieving in a sustainable way.

There are typically two ways to compare velocity:

• “Yesterday’s weather”: This is comparing the target velocity with the velocity achieved in the previous iteration. Assuming there’s no change in team availability, the team should be able to achieve the velocity recorded for the previous iteration. (An adjustment may need to be made if team availability is different because of vacation or other factors.)
• Average velocity: Comparing the target velocity with an average is perhaps a better method, but it requires the team to work for several iterations.

Using the “yesterday’s weather” comparison is good for when you’re starting to build regular iterations with a team (“We did this last time; let’s aim for the same”). If the last iteration was affected by vacation, sick leave, etc., then it’s not such a good indication, as the velocity for that iteration is likely to be less than is typical for the team.

Average velocity provides an indicator built from the last x iterations. This is good for when team members are showing that they can consistently deliver, but not so good when they’re just starting out because initially you can expect a team’s velocity to deviate while they establish a rhythm. A newly formed team usually takes a few iterations to find the number of points it can expect to achieve sustainably. Even established teams working on a new project may need a few iterations to discover and understand how their estimates are affected by their new environment.

It’s hard to say when the target velocity gets too high to be achievable. I have known teams who like to stretch their velocity, but if your target is overly optimistic, then you should ask yourself (and the team) why you believe this is achievable. Teams may wish to stretch themselves (“We did 30 points last time; let’s aim for 32 this time”), but this should always be a team decision without management pressure. It also should not be used as an attempt to play catch-up (“We aimed to do 30 points last time but we only did 25, so we need to 35 points this time”). This approach will seldom result in a clean iteration.

Teams may also trivialize the amount of work associated with carried-over stories (“We aimed to do 30 points, but we did 22 and carried over an 8-point story. That is almost done, so for this iteration let’s do 24 points and the carried-over story to make 32 points). The amount of effort may be less, but the team should not underestimate how much work is involved in getting a carried-over story completed and accepted.

Other things to look out for:

• Large stories: The larger the story, the larger the complexity and risk, and therefore the more unlikely it will be completed in the iteration. If a team has a velocity of 20, then bringing in a 13-point story is a massive risk as this story is more than half of the expected effort for the whole team for that iteration. Large stories should be broken down so the team can understand the required work better and reduce the risk.
• Carry-over: If you’re continually carrying over stories, find out why and try reducing the target velocity for an iteration in order to complete cleanly. Perhaps the acceptance criteria is too open-ended? Perhaps the story is too large? Find the reason and fix it.
• Blocks/impediments: The slower you resolve these, the more likely the team will run out of time, treat these as a priority, and ensure they are discussed in every stand-up until they are resolved.

Examples

Here are a few example scenarios. What should you be worried about in each situation?

Example 1: The team has an average velocity of 20 points but for its last iteration only managed 12 points. The largest story size was 5 points. The ScrumMaster explained that the velocity was affected by the Christmas break, and for the next iteration the team has a target of 22 points (including carried-over stories), with a largest story size of 5 points.

Recommendations for Example 1: This explanation sounds reasonable. Popular vacation times such as Christmas can often disrupt a sprint, resulting in a reduction in velocity. Teams can decide their own approach to this interference. In this example they decided to maintain their cadence and expect a drop in velocity.

Example 2: The team has an average velocity of 30 points and for its last iteration achieved 35 points. The largest story was 8 points. For this next iteration, the team is planning to do 45 points and the largest story is 13 points.

Recommendations for Example 2: The team is on a high, but it looks like it’s attempting too much (150 percent of its average velocity). Discuss with the team and agree what is achievable based on the average velocity and “yesterday’s weather.” Also ask what the largest story size they’ve successfully delivered is—13 points sounds large and full of risk!

Example 3: The team has an average velocity of 30 points but for its last iteration only achieved 24 points. The largest story size was 8 points, and one of these was carried over to the next iteration. The team is planning to do 32 points and the largest stories are 8 points.

Recommendations for Example 3: The team is trivializing the carried-over story and attempting to match its last iteration while completing the carried-over story. It looks like the team is struggling to deliver 8-point stories within the iteration. What is its track record? It makes no sense to attempt 8-point stories unless the team is confident why they failed to deliver previously. A far better approach would be to try to break these stories down into smaller stories.

Summary

Ensure that the velocity target is realistic based on what the team has achieved in previous iterations. The team members can agree to stretch this slightly, but make sure they also take into account their availability for the iteration.

Think of large stories being not only effort, but also complexity and risk. Break these down into smaller stories to reduce the chance of carry-over.

When stories are carried over, find the reason and fix it, and break larger stories down or tighten up acceptance criteria.

And finally, don’t become tolerant to blocks or impediments. Treat these as a priority and fix them as soon as possible.

Teams that can sustain their velocity will be more predictable, and this will increase confidence for both the teams and stakeholders, as they will see good and consistent progress.

Any views expressed within this article are Dave Browett's and do not necessarily reflect those of his employer.