The most important measure that an Agile team will use in planning is its “Velocity”. It is the amount of work finished by the team in each sprint. It helps the team to identify how much progress they can aim to make in a given sprint. Velocity is calculated by adding all the story points given to each user story that is completed by the end of the sprint. It measures output, but not the outcome.
The steps involved in Velocity-based Sprint Planning are as follows:
During sprint planning, the velocity of a team is served as an input to the next sprint. They use this velocity data, evaluate and enhance its use in the scrum to deliver customer value. By evaluating its own velocity for the past several sprints, the team can gain knowledge on how the change in the particular process can affect the delivery of measurable customer value.
Moreover, we can:
A velocity-driven sprint planning meeting involves the Scrum Master, Product Owner, and all the development team members. The Product Owner presents the highest-priority product backlog items in the meeting and introduces those top-priority items to the team.
The development team matches their forecasts with actual deliverables, estimate accordingly from current sprint to release. And the team’s velocity is the most appropriate measure used during forecasting.
Let’s assume that the team is doing a one-week sprint to calculate velocity.
Calculating the velocity of sprint 1
Assume that the team has completed 3 user stories out of 5 by the end of sprint 1, then
Calculating the velocity of sprint 2
Assume that the team has completed 4 user stories out of 7 by the end of sprint 2, then
Calculating the velocity of sprint 3
Assume that the team has completed 5 user stories out of 9 by the end of sprint 3, then
According to ResearchGate study, it was proved that velocity always fluctuates in the first few iterations from sprint to sprint. This is mainly because a new team takes time to get the flow. This also may happen because of some changes happening within a team. The report also demonstrated that in most cases, velocity is likely to stabilize after completing at least three iterations. So, it is good to analyze the completed story points after completing a minimum of 3-5 sprints.
We now know our previous sprint velocities which are given below:
This is our average velocity of past three sprints, which serves as a reference in understanding how the team is completing the user stories in a sprint. This will give you more clarity and help in planning your future sprints perfectly. When you are planning a sprint, velocity will give you the reference as to how many user stories can be done in a sprint.
Note: The total number of user stories committed during a sprint should not exceed the average velocity of the past sprints.
Velocity can fluctuate based on the following variables in a given project:
The velocity chart helps us to:
It is easy to predict the future velocity if we have the historical data of velocity. This is one of the advantages of having durable teams, as they will have such useful historical data. But, what if the team is new who haven’t worked with each other and hence don’t have any historical data?
We will need to estimate it.
One simple way to predict the velocity of a team is to consider the team capacity sprint planning to estimate what product backlog items they could commit to deliver at the end of each sprint. If the commitment looks acceptable, we can just add the sizes of the PBIs that are committed and utilize that as the forecasted velocity of the team.
Once the team has completed a sprint and have their actual velocity measurement, we have to use the actual data and leave the forecasted one. Moreover, as the team develops a history of actual velocities, we have to calculate the average velocity to obtain the velocity range.
Release planning is not possible without velocity. A Product Owner, by estimating the velocity, can predict the number of sprints required by the team to achieve a desired level of functionality that can then be dispatched. Therefore, the Product Owner can fix a specific date for release depending on the sprint length.