What is Velocity?
Before we start, let’s talk briefly about velocity.
Velocity is the amount of accepted work, expressed in measurable units, that the team can accomplish in one iteration
In other words, this is the speed at which the team is moving towards the project completion. As with driving, this determines how fast the vehicle will reach the target. Though speed is not the only deciding factor, it provides a vital input to release planning.
Common units of measurement are story points and ideal days.
Story points are relative sizings assigned by the team to user stories, representing their magnitude. Ideal day is the time required to complete a task by any team member, devoid of any distractions.
5 Common Mistakes
As with various other metrics in Agile Projects, Velocity must not be considered as definite or constant. Its purpose is to give meaning to your planning efforts and offer visibility into the future – and not to make detailed plans for religious tracking.
Here are some common mistakes in using the velocity!
Mistake #1 : Comparing Velocities between Teams
The first thing to understand and accept – velocity is team-specific.
It goes in line with the fact that every team is unique. They cannot be compared on the same scale. Though their accomplishments can serve as a comparison metric, their velocities are not.
You may ask why… Because the definition of velocity is specific to a team. Here are some ways in which the velocity might differ.
- Different units of measurement (story points, ideal days, T-shirt sizes etc.)
- Focus factor – amount of distraction in an iteration – differs between the teams
- Difference in competencies
- Iteration lengths are different
In short, comparing velocities between teams don’t offer any meaningful results.
If you must really do it, find a way to convert the throughput on a common scale and perform the comparison. Again, the results may not be perfect but better than a mere velocity comparison.
Mistake #2 : Using Initial Velocity to change Release Plans
A Project Manager cannot resist the temptation to track progress against the plan. She gets super excited when the team is delivering faster than expected in the initial few iterations. Then she makes a mistake.
She goes ahead and updates the release plan. Even worse, she announces in the next meeting with the customer that the project will be delivered before the committed date.
Here are the problems with this approach:
- Velocity is an estimate of team’s throughput, not a commitment
- Fluctuations are very common. It depends primarily on the type of stories taken up by the team in a given iteration
- Other factors that affect velocity are special cases (e.g., extra developer available), conducive conditions and elimination of risks
So the next time you are tempted to change your plans based on the initial velocity of the team, think again!
Mistake #3 : Unfinished (or unaccepted) stories don’t contribute to Velocity
If you go back to the definition of velocity, you will notice the stress on the word "accepted." It is quite normal and natural that the team cannot accomplish everything they committed. Iteration review meetings help to decide if the stories can be handed over to the customer. If not completed or accepted, usually they are carried over to the next iteration – unless there is a change in priority.
In such scenarios, these stories don’t contribute to team velocity. Here’s why:
- Unfinished stories aren’t usable by the end user
- If the customer starts testing an unfinished story, chances are high that she may have to repeat it after the final delivery
- Completeness determines throughput, not the commitment
If you consistently find that the velocity is remarkably low due to a spate of unfinished stories, look for ways to improve the story split.
Multiple short stories that can be completed in an iteration are better than few large stories that are incomplete.
Mistake #4 : Use planned effort for Velocity, not the actuals
In continuation to the previous mistake, some teams use the actual effort spent on a story for velocity calculation. This doesn’t give the right message. Velocity must be calculated using the planned effort, determined in the planning meeting.
Let’s take an example. User login story is estimated by the team at 10 ideal days. Once they start the implementation, they realize that the encryption part takes longer than expected. They managed to finish the story but spent 15 ideal days.
In this example, 10 ideal days must be used for velocity calculation and not 15 ideal days.
But, the difference must be considered while making the next estimation for a similar work item.
Mistake #5 : Wrong interpretation of Burndown charts
Burndown charts are a very common tool to interpret the health of an iteration. But often, they are misunderstood and as a result, misinterpreted.
Burndown charts show the amount of work remaining to be accomplished. It is a good metric to determine if the iteration will meet all its goals. But, it doesn’t show the rate at which the work is completed, which is what velocity is all about.
In this chart, you can immediately conclude that the team will not meet its commitment of 50 Story Points in the iteration. But it neither gives the indication of velocity nor the reason for deviation.
So then, what helps with velocity calculation? Yes, its counterpart, the Burnup Chart!
We covered a lot of ground in this post. Let’s recap the key points.
- Velocity is a key metric for release planning, that is important for various project stakeholders
- But there are many common mistakes made in velocity calculation
- A Team’s Velocity is unique, a 1-1 comparison is meaningless
- Using initial velocity to change release plan is a wrong approach. Wait for the velocity to stabilize and use the averages
- Unfinished (or unaccepted) stories don’t contribute to velocity calculation
- Planned estimates must be used for velocity calculations and not the actuals
- Making velocity conclusions and interpretations from Burndown charts is flawed. Instead, use Burnup charts
This article originally appeared in Breathe Agile on July 2016.