Scribd
Upload
43 views5 pages

Velocity Planning

Velocity-based sprint planning uses a team's average velocity over past sprints to estimate how much work can be completed in the next sprint. It involves calculating the team's average velocity, selecting user stories equal to that velocity, estimating tasks, and using velocity to forecast releases and plan future sprints.

Uploaded by

sharan kommi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
43 views5 pages

Velocity Planning

Velocity-based sprint planning uses a team's average velocity over past sprints to estimate how much work can be completed in the next sprint. It involves calculating the team's average velocity, selecting user stories equal to that velocity, estimating tasks, and using velocity to forecast releases and plan future sprints.

Uploaded by

sharan kommi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

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.

You might also like