Team Velocity
Team velocity is a crucial tool for effective project management. Not only does it track team delivery, it also allows for the projection of delivery potential.
What is team velocity? Simply put, velocity is the average of the work delivered by an agile team. It can be done with hour estimates, but it is easier to track through using the story point method (which I will use for my examples).
A quick Agile primer: In Agile development, work tasks, often referred to as User Stories, are estimated using Story Points. Typically, a modified Fibonacci sequence is used for Story Points. (i.e., 1, 2, 3, 5, 8, 13, & 20). Work is committed to for a specific duration of time known as a Sprint. Sprints are divided by weeks, often 2 weeks, though I have seen sprints with lengths ranging from 1 to 4 weeks. Velocity is determined by an average of point delivery over time.
Example:
An Agile team has 2-week sprints.
For weeks 1 & 4, they deliver 20 points. For weeks 1 & 3, they only provide 10.
Adding these up, we receive 60 points.
Divide this by the number of sprints (4) and we get a Velocity of 15.
Project managers can now start using this as a guideline for what the team can provide over time. If you are starting a new feature, and receive the estimates, you can imply divide by the velocity to get a general idea of how long something will take.
Extended Example:
A new feature is needed, and the team has estimated it will take 60 story points to complete.
We can divide this total by the team’s velocity. 60/15 = 4 Sprints (8 weeks).
Note: In that example, the project manager should add some padding to the delivered time. If there is a significant service or person outage, then it can take longer. It is a good rule of thumb to pad an estimate with an additional 1/4 of the time (in this example, 15 more points, or an extra sprint).
As velocity is better measured over an extended period, it is essential to take the following steps:
Ensure that teams follow a consistent story-pointing scheme.
Try not to modify the team makeup.
Do not change the length of sprints.
Revisit the velocity over time.
To ensure consistency, use retrospective events to analyze whether the story points assigned to a User Story make sense. Have the team determine if they estimated incorrectly or didn’t take something into account. This helps them refine their estimates over time.
Changes to the team often have their own issues, such as training or differences in capabilities.
Changing the length of a sprint will make tracking velocity nearly impossible. The key here is to keep it simple. If something can’t be delivered in a sprint, it is ok to move it to the next sprint. Ensure that there are no penalties to the team from this perspective. They should be praised for their delivery.
As a team progresses, velocity will fluctuate. A 4-sprint velocity will look very different from a 40-sprint one. The longer you go, the more accurate the velocity will be, and the easier it is for a project manager to build out plans based on it.
