What is Team’s Velocity in Agile Methodology?
In agile velocity is the amount of work done during a sprint. In agile, velocity provides the distance your team travel to reach to the sprint objective.
Agile Velocity Definition
In agile Velocity help you to understand how long it will take your team to finish the whole backlog. In general, it takes few sprint to get to know the team velocity.
I average the amount of user story completed by your team in for e.g past three sprint take the average of it is your team velocity. Assuming your team is completing 5-7 user stories in each sprint with total story points of 25-35. So, the average velocity of team in past three is 25 – 35
How To Calculate Sprint Velocity in Agile Development
Lets have a detail look in how to calculate velocity in agile development.
Assuming that team is having one week sprint.
Calculating Sprint 01 Velocity in Agile Scrum
- Assuming that in sprint 01, team committed to total of 5 user stories
- Story point of each of the user story = 8 story points
- Total story points committed by team in sprint 01 = 40 story points
By end of sprint 01 team completed 3 out of 5 user stories
- Total user stories completed in sprint 01 = 3 user stories
- Total story points completed in sprint 01 = 3 x 8 story points -> 24 story points
Calculating Sprint 02 Velocity in Agile Scrum
- Assuming that in sprint 02, team committed to total of 7 user stories
- Story point of each of the user story = 8 story points
- Total story points committed by team in sprint 01 = 56 story points
By end sprint team completed 4 out of 7 user stories
- Total user story completed in sprint 02 = 4 user stories
- Total story points completed in sprint 02 = 4×8 story points->32 story points
Calculating Sprint 03 Velocity in Agile Scrum
- Assuming that in sprint 03, team committed to total of 9 user stories
- Story point of each of the user story = 8 story points
- Total story points committed by team in sprint 03 = 72 story points
By end sprint 03, team completed 5 out of 9 user stories
- Total user story completed in sprint 03 = 5 user stories
- Total story points completed in sprint 03 = 5×8 story points->40 story points
Calculating Average Velocity of Sprints
Once you know the velocity of past three sprints, calculate the average of them. Let’s assume your previous sprint velocities were [completed story points in each of the sprints]
- Sprint 01: 24
- Sprint 02: 32
- Sprint 03: 40
So your average velocity of sprint is: 24+32+40/32 = 32
That is your average velocity in past three sprints. This is the reference how your team will be finishing the user stories in a sprint.
You need to successfully complete at least 3-5 sprints and check your completed story points in each of the prints, this will give you better visibility and help you in planning future sprints, when planning your sprint, velocity will provide you reference how much user stories can be completed in a sprint, by using this value you are sure that you are not over or under planning your sprint. So the total number of user story taken during a sprint should not be exceeding the average velocity of past sprints.
Agile Velocity Chart
Bellow you can see the velocity chart from Yodiz. In the chart bellow you can see the average velocity of sprints from past 10 sprints
How To Use Average Velocity In Agile Develpoment
Release planning
You can use average velocity for planning releases, for e.g, if you are a product owner, you need to know when you can deliver all the features. If you know the team’s velocity you can put all user stories from product backlog in sprints to calculate how many sprint it will take to finish all the features.
Assuming you have two weeks sprints, and your average team’s velocity is 33.
So you can put the swim lane of sprints to see how many sprints will take to complete all the features (putting userstories in sprints using the velocity of sprint)
This is a useful way of predicting your time-line of delivering the final product with all the features.
Sprint planning
Normally average velocity is only used by product owner when doing the release planning, but we strongly argue that this should be use in sprint planning as well, normally scrum team uses hours when calculating a user story, story points should be use for estimation and average velocity should be use to make sure sprint is not over or under planned.
Using Story Points Instead of Hours
The advantage is developers are pretty bad at estimating time, a very complex task can be done in 2 hours from the point of view of a developer, but to maturing it will take 8+ hours, but using the abstract value like story points which compare complexity in relative terms will be easier for developers, it takes off the actual time in hours and put the focus on relative complexity of task.
We use the Fibonacci number from 1- 8 anything above that number needs to be divided into smaller user stories. We love using planning poker which give us the edge to start a technical discussion among team during sprint planning.