Agile Velocity Calculation: How to Calculate Velocity to Meet Deadlines

In agile development, the best way to measure success is through team velocity. Have you ever underestimated how long it would take to build a feature or fix a bug? You get halfway through the sprint and a mild panic sets in as you remember the promises you made to your sales and customer success teams.

Eventually, tasks begin to creep into future sprints and you’re none the wiser on how to better estimate engineering and product tasks in the future. You try approaching team members individually, attempting to pinpoint single performers who may be holding up the line. But ultimately, it becomes clear that your entire team has to maintain shared ownership and momentum to build features quickly.

This is where team velocity comes in.

What is velocity in agile methodology?

According to Scrum, Inc., team velocity is a “measure of the amount of work a team can tackle during a single sprint and is the key metric in Scrum”. When you complete a sprint, you’ll total the points for all fully completed user stories and over time find the average number of points you complete per sprint.

Past velocity can be used to make future estimates and prevent further issues and risks like not hitting a deadline or rushing the development process. Note that each team has its own velocity so you’ll have to measure it separately.

Team Velocity = Total Story Points Completed Per Sprint / Number of Sprints

Why team velocity tracking matters

The point of tracking velocity isn’t to generate a nice-looking report for your boss. Measuring team velocity gives you a realistic understanding of how long team members will need to complete certain tasks based on their complexity.

Universally, we tend to overestimate the amount of work we can complete in a given time period. Measuring actual velocity – how much work we really get done – enables us to plan more accurately, making us much more likely to achieve our goals!

In isolation, the amount of work completed in one milestone isn’t very helpful. Factors outside your control – a sick teammate, an unexpected bug – are bound to pop up. Life happens. Viewing work completed over time, however, becomes a valuable piece of insight.

Let’s get to the details of how to calculate team velocity in agile.

Defining story points within team velocity

Agile development deals mainly with story point estimates. Story points involve relative estimation as their sole role is to compare tasks in relation to other activities.

For example, let’s say in Sprint 1, a team completes a user story with 3 points, a story with 2 points, and a story with 5 points, totaling 10 points. They had originally committed to a 5 point story that they didn’t complete, so it doesn’t get included. In the second Sprint, the team completes 11 points. In the third Sprint, the team completes 9 points. At this point, the team’s velocity is 10.

When calculating velocity, only include user stories that are complete. Incomplete users stories should be carried into the next sprint.

Team Velocity = Average Number of Story Points Delivered Per Sprint

Measuring your team velocity allows you to use previous estimates to predict how long upcoming work will take. Of course, there will be dips when it comes to people being sick or on vacation, but you should be able to better understand the trends of your team’s collective productivity over time. With this information, you’ll be able to make better predictions by looking at historical data and adjusting expectations moving forward.

For example, if you notice that for some sprints you’re able to get 28 story points complete and others only 22, talk to your team to explore why this may be happening. Are you estimating inconsistently? Or are there other factors contributing to certain sprints being less productive than others?

How to increase team velocity in an agile project

Measuring your team velocity doesn’t mean much if you aren’t increasing that velocity. Ideally, when you increase scrum velocity, you’re more quickly releasing features, shortening the time to value for your customers and increasing equity value for the company.

Not sure where to start? Here are some ways you can continue to improve your team velocity:

1. Increase visibility: To maintain collective team accountability, visibility is key. Wherever you’re tracking production progress, make sure that everyone is able to access that information and encourage them to document what’s necessary in order to keep velocity at top speed.
2. High-impact daily scrum meetings: Daily meetings can often feel like a drag, creating major mental fatigue for your team. Make sure that you’re entering into these meetings with high energy and commitment to keeping them direct and productive.
3. Don’t skip the retrospective: When a sprint ends, it’s easy to want to move on to the next thing immediately. However, without a retrospective, there’s a higher chance of poor practices enduring, which will continue to slow down how fast your team can move forward. This is another opportunity for your team to share the responsibility and maintain an open line of communication.
4. Focus on system bottlenecks over individuals: Improving a person’s individual performance is one way of tackling inefficiencies, but in many instances, it’s likely a case of a workflow or communication issue. If you’re frustrated and don’t know why features aren’t completed on time, take a beat and talk to your team about where the system may be failing them. This avoids any finger-pointing and encourages honest feedback. (See #3 if you’re struggling to find the time to explore.)

See your team’s velocity inside GitHub without agile velocity calculation

If you haven’t already, start adding story point estimates to your GitHub issues and pull requests. (If you’re not sure how to estimate, read our guide!) This will allow you to track their progress in reports later.

When you’re preparing for a sprint, you’ll add your estimated issues to an epic. You can give the epic a descriptive name, and don’t forget to set both a start and an end date on the roadmap!

After you’ve completed a few sprints, you’ll have historical data in your agile velocity charts. To view them, click the new Reports tab in Zenhub, and select Velocity tracking.

Zenhub will automatically display up to ten upcoming and past sprints. Hover over each bar to see more detail. The blue line denotes the average number of story points (estimates) closed each sprint – open story points do not count toward this total.

Note: You can get a broader view of team velocity by connecting repositories together.

Track team velocity visually with Zenhub

No one has time to do agile velocity calculation manually. That’s why we’ve made it simple with our Velocity Charts to quickly see your team’s historical speed of work. They provide a simple, at-a-glance picture of your velocity, as measured by the total number of story points closed in recent sprints.

Another visual alternative to monitor team performance and velocity is the burndown chart. A burndown chart is a graphical representation of work that has to be completed during a sprint. You can use these to get a real-time overlook at the workload that’s done and what still needs to be finished:

With these charts, you can see exactly how much value your team can ship each sprint. And since they’re built using live GitHub data, you’ll know they’re always accurate.

Learn more about Zenhub’s velocity reports and charts here.