How to Calculate Velocity for the First Sprint?

We all want to improve our productivity or in the development language - maximize sprint velocity. After a couple of sprints, you can estimate how much time you will need for upcoming sprints. But, how to calculate velocity sprinting for the first sprint?

Why is it hard?

In sprints that are not first, the team can use past velocities to estimate. Past record and data helps to make a plan and have a more clear vision about the progress. Sometimes, the velocities from previous projects can help to predict velocities for new projects.

However, not all projects are similar. That means that it is often not a reliable way of estimation. Even bigger problems occur when a team is new or using new technology. Past data is not available. Using data from other teams can be a way to go but often you don't have enough information about their performance.

Calculating first sprint velocity

To avoid uncertainty, there are some methods of how calculating velocity for the first sprint. They follow steps:

Calculate the Capacity

When calculating the number of hours you have to make your project, don’t expect you will be productive 100% of the hours. Remember, your team has emails to answer, scrum meetings to participate in, and lunch breaks to refresh.

That’s why you can take 80% of the total capacity of working hours. So, let’s say that:

Developers - 200 hours
QA (Quality Assurance) - 120 hours
UAT (User Acceptance Testing) - 60 hours

Connect Amount of Time for Each User Story

User stories might need multiple disciplines and more than one member of the development team to be finished. Write how much time does it take for each discipline and each team member to finish a user story. For example:

User story #1 takes 20 hours of the development team, 16 hours of the Quality Assurance team, and 4 hours of User Acceptance Testing.

Connect capacity with availability

The next step is to connect the estimated effort for each user story or requirement to team capacity (80%). Here it is important not to make slowdowns in the estimation. Remember you already left 20% of the capacity out of the calculation.

Also, since there is not much progress planned for the first sprint, you can save some time if you do more than planned in the first sprint. Planning the first sprint slower is one of the ways to prevent snow plowing in agile.

Assigning Members to User Stories

You assign stories that are in the beginning of the plan to team members. They commit to user stories or requirements. Don't forget that there will never be 100% utilization and that's not the intent.

Eventually, this should show you how many story points are committed by team members. In the end you can see the total story points committed by the whole team in the first sprint.

How to estimate story points?

Story points are metrics in Agile that help to understand the estimate of the story difficulty. In other words, it is a number that shows how challenging and complex a certain story is. Development teams use them in order to determine the time needed for each story.

There are few ways to do it. One of them is to use Fibonacci sequence numbers. It stands for a series of numbers where each number is the sum of the two previous numbers. They go like: 0, 1, 1, 2, 3, 5, 8, 13, 21, etc.

In Agile,

the sequence is usually modified to 0.5, 1, 2, 3, 5, 8, 13, etc. Estimating story points with these numbers is easier than thinking about the difference between two close story points.

When estimating, make sure you think about the value of each story. Here, relative values are more important than raw values.

Calculate velocity from the story points

After you know story points, it is time to put them all together and finally estimate the team velocity. After estimating story points you will be able to estimate the amount of hours your team needs for the first sprint.

For example, if a team can work 100 hours, and an hour per story point is 5, then velocity is approximately 20. It would be more relevant to express it as a range instead of a single number. For example 18 - 22.

To Wrap Up

Discuss whether each of those work items had a similar level of effort. If not, discuss why. Use that insight in future estimation discussions.

Like everything else in agile, estimation is a practice. You'll get better and better with time.