Velocity-Based Sprint Planning

What is Velocity-based Sprint Planning?

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:

• Calculate the team’s average velocity (from last 3 Sprints)
• Select the items from the product backlog equal to the average velocity
• Verify whether the tasks associated with the selected user stories are appropriate for the particular sprint
• Estimate the tasks and check if the total work is consistent with past sprints

Why do we need velocity-based Sprint Planning?

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:

• Estimate how much amount can be delivered by a particular date
• Estimate a date for a committed amount of work to be delivered
• Understand our goals while fixing the amount of work we will commit for a sprint

Who all participate in the velocity-based sprint planning?

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.

How to calculate Sprint Velocity?

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 committed to 5 user stories
• And each user story= 8 story points
• Then the total story points in sprint 1= 40 story points

Assume that the team has completed 3 user stories out of 5 by the end of sprint 1, then

• Total user stories completed= 3
• Total story points completed= 24 (total no. completed user stories x story points=3 x 8)

Calculating the velocity of sprint 2

• Assume that the team has committed to 7 user stories
• And each user story= 8 story points
• Then the total story points in sprint 2= 56 story points

Assume that the team has completed 4 user stories out of 7 by the end of sprint 2, then

• Total user stories completed= 4
• Total story points completed= 32 (total no. completed user stories x story points= 4 x 8)

Calculating the velocity of sprint 3

• Assume that the team has committed to 9 user stories
• And each user story= 8 story points
• Then the total story points in sprint 2= 72 story points

Assume that the team has completed 5 user stories out of 9 by the end of sprint 3, then

• Total user stories completed= 5
• Total story points completed= 40 (total no. completed user stories x story points= 5 x 8)

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.

Calculating average sprint velocity

We now know our previous sprint velocities which are given below:

• Sprint 1: 24
• Sprint 2: 32
• Sprint 3: 40
   

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.

Reasons for fluctuations in velocity:

Velocity can fluctuate based on the following variables in a given project:

• Project complexity
• Team size
• Uniformity in team membership
• Team ability to concentrate on Scrum stories and activities
• System outages
• Lack of Product Owner engagement
• Unexpected absences in the team

How does the Velocity chart help?

The velocity chart helps us to:

• Track overall project status
  The velocity chart computes a number of project trends such as accepted stories by type, volatility metrics, and iteration velocity. This makes the velocity chart ideal for monitoring overall project status.
• Track volatility
  Volatility is a measure of predictability. Frequent velocity valleys and peaks may show you an unpredictable project, while iteration-by-iteration velocity implies a predictable one.
• Know velocity trends
  Accepted story points may be less for a specific iteration when there is a large number of Zero-point stories, chores, or bugs. This chart makes these chores/bugs visible clearly by exhibiting iteration velocity dips along with an increase in accepted bugs.

How to forecast the next sprint velocity?

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.

What is the impact of velocity-based sprint planning?

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.