You are here

Tracking Velocity

It is a good idea to estimate the size for every story that you take on. Depending on your team, this might be in story points (recommended), ideal days or something else. A team's velocity for an iteration is the sum of the points for the stories completed in that iteration. You can also track how many points you attempted to complete for the iteration. Tracking both of these over time can be very illuminating.

The above graph (from Planigle) shows a common pattern when teams are adopting agile. It takes a few iterations to get things done within an iteration time box and to get a good feel for what the team is capable of. Iteration three in this example has a big increase since you only get credit for a story's points when it is completely done. This was the iteration that this team got the first few stories done.

Once you get used to getting things done within an iteration, it becomes a matter of understanding what the team is capable of. Some tips to hitting your goals for the iteration:

  • Start with the right size stories; too big and you won't be able to get it done in an iteration
  • Specify a clear definition of done - what must be met for any story to be considered done
  • Define clear acceptance criteria - what must be met to consider this particular story done
  • Be crisp on what is in the iteration; Leave stretch goals out (they can always be brought in if you get ahead)
  • Commit as a team to the iteration goals
  • Push new requirements that come up mid-iteration to subsequent stories / iterations

Get in the habit of meeting your iteration goals and people become more motivated to ensure that you hit them. Get in the habit of not meeting them and failing becomes viewed as not a big deal.

When you have a consistent velocity, you can use this to project when stories will be completed in future iterations. It is just a projection since things change (prioririties, understanding of difficulty, etc.). But having this can be very helpful in getting people on the same page as to what the release is about (see this previous blog entry for more on release planning).

Over time, your velocity will likely increase as the team works better together and as it becomes more proficient in the technology and the domain. By tracking it over time, you can use velocity as an indicator of team health. If it goes up or down too quickly, you can investigate why. Or inversely, if something happens in your environment (such as a layoff), you can use it to assess the impact on the team's productivity.

Don't compare velocities between teams or use it to evaluate a team (or the team's leaders). Doing this can cause people to game the numbers. This will quickly remove the ability to use velocity as an indicator (see this previous blog entry for more on the subject).

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer