Agile Velocity 101
Why Velocity in Agile Works Better than Man Days Effort Estimation?
Agile Velocity: Learn how to calculate and use it with real life examples
What is the velocity metric in Agile?
Agile Velocity represents the amount of work that can be performed by a team during a sprint. There is no standard benchmark of what is a good or bad Agile velocity. It depends on each particular group and the product they work in.
How does the classic estimation work?
Estimated effort in days is a mix of mathematic calculations, experience, and gut feeling. There are multiple mathematic formulas to calculate the effort needed by the team for a specific task. To name a few of them:
- Analogous estimation. It is generally used at the start of the project when not much is known. Comparable evaluation in projects compares the current project with past similar projects. It is a relatively easy method of estimating, although not accurate.
- Bottom-up estimation. I see this estimation method used when there is significant detail about the tasks needed to implement a particular user story. Clarify on the resources, skills; capabilities must be passed before. The bottom-up estimation method is the most precise but also the most time-consuming and expensive form of estimating.
- Parametric estimation. A method that I use for estimates that are quantitatively based, such as dollars per square foot or number of installations per day. It is a relatively simple method, but not every activity or cost can be estimated quantitatively.
- 3 points estimation. It consists of determining the Optimistic (O), most likely (M), and pessimistic (P) scenarios. The most likely scenario will weight the most. The equation is (O + 4M + P) / 6.
An experienced person will apply the gut feeling on top of the mathematic calculations. The result is close to reality. More experienced the person is, the more repetitive the task, closer to actual the estimation will be.
BUT here is where the work estimation fails: an estimate will always be wrong because it’s an estimation.
How does Agile velocity work?
First of all, Agile velocity is natural. It is the natural, sustainable pace of the team. For a long term performance, the team must work at its best consistently. It is like high-performance athletes: they train every day, sustainable for years. They don’t train day and night for one month and then lay by the beach for four months and get back to training hard for 1–2 months and win gold medals on the Olympic Games. NOT! It is the same for the teams in projects and products. The team works consistent, efficient, without interruptions, sustainable and velocity metric in agile is measuring their steady pace. It is the pace they can work long term.
Why velocity in Agile and not Work estimation?
Work estimation is based on mathematical calculations and experience of each team member, while Agile velocity is based on the natural pace of the team. No algorithm can be more accurate in predicting human behavior than the facts.
Velocity in Agile is the sustainable pace of work you can trust.
The same team working on a different product might have a different velocity. You should NEVER compare the velocity metric between scrum teams.
What is the fake Agile velocity?
Fake velocity is when you do a story halfway, without respecting the Definition Of Done (DOD), and the team claims story points for it.
Learn more about User Stories Definition of Done (DOD) in
When marked as “Done”, a story is considered ready to be released to the users. The effort left to be made available for the users must be of a maximum of 1–2 hours. Otherwise, it creates a false impression that the functionalities are available for the client. But, in reality, the team needs to perform more work: deploy to the production environment, test, end-to-end user testing. This work is hard to assess. If we have such kind of features developed, then, YOU CANNOT MEASURE VELOCITY.
The first mission is to be able to measure the velocity.
The velocity in Agile is the sum of the story points all the COMPLETED stories during the sprint.
Velocity is not a measure of effectiveness, efficiency, competency, or anything else. It is merely a measure of the rate at which a given amount of problem statements are turned into tested software.
How to use the Agile velocity metric?
My recommendation is always to use it as a measure of consistency. I measure the predictability of the velocity. To give an example, a team does:
- 34 story points in Sprint 12,
- 48 story points in Sprint 13
- 28 story points in Sprint 14
I measure the deviation of the Agile velocity:
- I take a baseline, for example, sprint 12. Which means that I give a 100% for Sprint 12
- + 41% for Sprint 13
- - 18% for Sprint 14
When looking at the velocity, my target is to keep it consistent. Like an athlete training. Even on bad days, it must not go below 3–5% deviation.
You may also read:
