How To Calculate Velocity for the First Sprint

May 21, 2022

5 min read

How To Calculate Velocity for the First Sprint

Has a lack of historical velocity left you uncertain how much work to pull into your first Sprint? You have a handful of choices and some to avoid.

Why Do We Need to Forecast Velocity?

There are a couple of different reasons you might want to forecast a velocity.

First, we can use velocity for release planning. If you know there are 100 story points of work in the first release for a new product, then given Sprint length and the Development Teams’ velocity, you can calculate a target release date.

Given a release containing 100 story points, a team with an average Sprint velocity of 25, and two-week sprints, you can forecast that the release will be ready in 8 weeks (100 story points/25 average velocity=4 sprints * 2 weeks=8 weeks).

Another reason you might want to know the velocity for a team is to use it as an input to Sprint Planning. It can be helpful to compare the total points selected for the Sprint Backlog to the velocity to determine if we might be over or under committing to work.

The issue with new teams is that they have not yet completed a sprint, so there is no historic velocity to base decisions on. A method for forecasting velocity can come in handy in this situation.

Emergent Velocity

The first and generally preferred option is to wait. After we’ve completed the first Sprint, we’ll have a better idea of a reasonable estimate for velocity. Once we’ve concluded our third Sprint, we’ll be able to calculate an average Sprint velocity that, in theory, is more representative of what we can expect in future iterations.

When possible, it’s better to wait to forecast velocity. With time we gain knowledge, and our forecasts will be more accurate.

Random Guess

You have no data on which to base a forecast, and anything you do will be imprecise. Story points themselves are abstract. Instead of coming up with a perfect mathematical solution that doesn’t exist, if you absolutely must have a number, guess.

Hourglass with a small amount of sand running into bottom — Spend the least amount of time possible generating estimates.

All the time you would have put into calculating what velocity might be in the future can now be spent making progress toward delivering working software, which should be the team’s focus - not perfecting estimates.

Educated Guess

The best educated guess you can make is to base the number on Sprint Planning using a capacity-driven approach.

Following this approach, we’ll break down stories starting at the top of the backlog and estimate the resulting tasks in hours. Once we’ve reached the number of work hours available in the Sprint, we stop. We ensure that we’ve only pulled completable user stories into the Sprint Backlog. Finally, we do one last review of the Sprint Backlog as a sanity check.

At this point, we’ve discussed the work in detail and should be reasonably confident of our ability to complete the selected user stories. Our forecast velocity is the sum of the story points included in the Sprint Backlog.

Kenneth Rubin suggests this approach in his book Essential Scrum.

Historic Velocity

If this Scrum Team has worked together previously, and this is just a new product, you could consider using past velocity from the last time the team worked together.

Consider reducing this initial forecast if more than two months have passed since the team last worked together. This reduction accounts for some regression of Tuckman’s Stages of Group Development, as the team is unlikely to pick up exactly where they left off.

If the new product is in a different business domain, you’ll also want to consider reducing the forecasted velocity. This reduction accounts for the ramp-up period of learning new business concepts, terminology, and processes.

A third reason to consider reducing the forecasted velocity would be if the team will be working with new technology, especially one no one has experience with.

Avoid These Options

Don’t use the velocity of another “similar” team. Story points are unique to each Agile team, and you shouldn’t compare teams on their Sprint velocity.

Imagine you ask me to estimate how long it would take to get from my house to the three nearest cities, taking into account complexity, uncertainty, risk, and effort using the Fibonacci scale. Then, separately, you ask my husband to estimate the same trips. It’s unlikely we’d provide the exact estimates. We quantify risk differently, my husband hates driving, and his worst fear (right after snakes) is navigating in the largest city near us.

Clip of George from Seinfeld swerving in city streets

Similarly, we can’t assume that one team will reach the same velocity as a different team. It may look like the developers are using the same stick to measure, but one team’s eight might be vastly different from another team’s eight.

Another common yet dangerous suggestion is to take a couple of user stories, break them down into tasks, and estimate those tasks in hours. That data can then provide a crosswalk between story points and hours. Given an 8-point story that generates 20 hours of tasks, we’d say each point takes (20/8=2.5) 2.5 hours. Thus a 3-point story should take 7.5 hours.

Considering the number of team members, holidays, planned vacations, and administrative overhead, we can calculate how many hours we have available in a Sprint. Dividing hours per Sprint by hours per point would theoretically give us the number of story points we can complete in a Sprint.

This math-based assumption is dangerous as it seems logical but has a large margin of error. Also, it establishes an unhealthy relationship between story points and hours.

Zoomed in shot of a clock counting down hours — A story point is not an accurate unit that will crosswalk to hours consistently.

The truth is that story point values don’t consistently alight to a given range of hours in the way this math presumes. If you don’t believe me, go through the exercise in this blog post, it’s startling.

Velocity Will Fluctuate

Forecasting velocity is, at best, an educated guess, and there is no guarantee that the team will consistently be able to reach a particular estimated velocity. Each time we share this metric with anyone outside the Scrum Team, we should convey this uncertainty.

We want stakeholders to understand this number is subject to change. Average velocity is transparent because anyone can calculate it at the end of each Sprint. Any processes that use this number should be fluid and subject to regular updates.

Helping stakeholders understand the transient nature of the metric is an essential step in preventing velocity-based anti-patterns. We don’t want to end up in a position where we treat the team’s inability to achieve the average velocity in subsequent Sprints as a failure.

Works Consulted

TLDR

The best option to forecast sprint velocity will depend on how you intend to use the metric. When possible, it’s best to allow your velocity to emerge as your team completes Sprints. Your second-best option is to go through a Sprint Planning exercise and use the sum of story points of user stories selected for the Sprint Backlog.