Sprint Velocity: 5 Ways to Move Faster.

The SeaLights Software Metrics Guide
for Better and Faster CI/CD

In this article, we explain the basic concepts behind sprint velocity and provide 5 ways you can improve the velocity of agile software development teams.

What is Sprint Velocity?

Velocity in agile development measures the quantity of work a team can accomplish in a sprint. It can be measured in story points, hours or ideal days. Ideally, the higher a team’s velocity, the more software functionality they are delivering, and the more value is created for customers.

Sprint velocity can be used in sprint project management to evaluate and estimate team productivity. In the diagram below, sprint 5 was exceptionally productive—the team produced almost 40 story points. Their average velocity is around 10 story points.

Average sprint velocity, usually taken over the last three iterations, can help R&D leadership understand how much a team can get done, and plan their workload for future sprints.

Understanding Agile/Scrum Velocity: Key Concepts

The following are basic concepts of the agile approach which can help explain velocity.


Capacity is different from velocity in that it measures how much time the team has available, not how much they are getting done. Typically, a full time employee is considered to have 6 productive hours a day (allowing time for breaks, meetings, emails, etc). So a scrum team with 10 developers, working 5 days a week for two weeks, has a capacity of 600 hours.

Story Points

Agile teams use story points to quantify how much effort is needed to build a user story, or feature, taken from the sprint backlog. The units can vary from team to team. For example, a team can decide that a small story or bug fix = 1 point, a medium story = 2-4 points, and a large story = 5-8 points. From sprint to sprint, the team tries to estimate how many points each story is “worth,” and commit to completing a certain number of story points as part of the sprint.

Definition of Done (DoD)

“Definition of Done” in an Agile or Scrum project is the acceptance criteria teams use to determine if a story has been completed. Each team has its own Definition of Done. The Definition of Done will typically require that the feature is working and able to provide value to a customer. It can include other criteria such as testing, code comments, documentation, peer review, etc.

Image Source

Burndown Chart

The burndown chart (sometimes called a Scrum velocity chart) is a visualization of sprint velocity. It shows the time remaining to complete the planned user stories for each day of the sprint. The slope of the burndown chart makes it possible to predict the outcome of the sprint—extend the chart until the X axis to see when the stories will be complete—ahead of time, on time, or later than planned.

Improving Sprint Velocity—a Few Caveats

One of the goals of R&D leadership is to increase agile or Scrum team velocity over time; to achieve more with the same resources. While this is an important goal, it can’t be followed blindly:

  • Velocity does not equal business value—a team might roughly deliver the same quantity of working features for years. Their velocity is the same, but due to their improved professionalism, teamwork and experience, they can deliver more value and higher quality within the same story points.
  • Velocity can come at the expense of quality—teams that are pushed to deliver more, faster might have no choice but to cut corners and reduce practices like unit testing, code reviews, UI and usability testing.
  • Velocity is a fluid concept—in agile, velocity is determined by subjective story point estimates and depends on the Definition of Done. Teams measured only by velocity will have a strong incentive to estimate more points, or lower DoD criteria.

The bottom line is that velocity is not the be-all-and-end-all. It’s an important metric, but one which needs to be used carefully to avoid hurting some of the best qualities of an agile team.

Improving Velocity Tip #1: Increase Quality

Increasing quality may sound counter-intuitive. Higher quality means a bigger investment in code reviews, test automation and bug fixes, which leaves less time to produce new features. Therefore you may think that higher quality would probably reduce velocity.

However, most agile practitioners agree that an investment in quality always pays off in improved productivity down the line. Plant quality now and sow the seeds later with elegant, maintainable software, and no time wasted chasing bugs from the past. Teams with issues in production cannot move at high velocity.

Improving Velocity Tip #2: Stop Wasting Time on Unnecessary Tests

Developers increasingly spend time on test automation and maintenance. This is a critical activity, but one which can slow down a team’s velocity. An important way to save time and increase velocity is to eliminate unnecessary tests.

Here are three examples of tests that are probably a waste of time:

  • Test overlap—it’s common for developers to write tests for a feature which is already covered by other tests, partially or fully. This typically occurs in end-to-end, UI or integration tests; these are complex and tend to cover several software components. Developers don’t have much visibility over which tests exist in the system and what they cover, which inevitably results in overlap. Any test overlap is a waste of time and effort.
  • Testing unused features—features that are rarely or never used in the current production version do not deserve additional tests. Even if you discover bugs, they will affect almost none of the software’s active users.
  • Testing code that hasn’t changed—code that has been stable for several sprints, or even weeks or months, and hasn’t broken, is unlikely to break now. Adding tests for code that isn’t actively worked on is probably a waste as end users already tested this code for you.

An important addition to your agile or Scrum testing methodology is how to make the tests themselves agile by prioritizing on what provides most value to the customer.

Improving Velocity Tip #3: Optimize Sprint Planning Meetings

The agile methodology advocates not planning too far in advance, or in too much detail. Nevertheless, some advance planning can generate important efficiencies.

In your sprint planning meeting be sure to plan a few sprints in advance with detailed task breakdowns for the next 1-2 sprints, and only “stubs” for user stories in the next 4-5 sprints to show teams the “big picture.” This added visibility helps to see dependencies, identify challenges, and consider approaches and technical solutions in advance.

Improving Velocity Tip #4: Sprint Retroactive and Process Review

One of the most celebrated aspects of the agile method is the recurring iteration which helps teams fine tune their processes, tooling and teamwork. But sometimes a neglected element is the sprint retrospective, when teams sit down after each iteration to discuss what worked, what didn’t work, and how to improve.

Agile teams collect valuable insights into what is slowing down the sprint—cooperation within the team, interruptions, missing skills, interfaces with other teams, tooling or technical issues. Surfacing these problems together with the product owner, and finding practical ways to resolve them, can have a dramatic improvement on velocity.

It’s important not to turn the retrospective into a “venting session/” Problems discussed during the session must be taken seriously and leaders must spend the necessary time to resolve them.

Improving Velocity Tip #5: Add External Resources or Training

The agile concept of a cross-functional team makes us think of development teams as self-sufficient units. They are supposed to build the tooling, create the automation, write the code and test it—all within the scope of the sprint.

In reality, many teams find it difficult to scrape together the infrastructure they require, while still producing new features. Some teams are short on certain skills—for example, DevOps, test automation frameworks, or different technologies introduced when integrating with new components.

When these problems occur, managers should be attentive and try to provide support to help the team remain productive by:

  • Hiring external or internal consulting to help setup needed infrastructure
  • Training to help team members get up to speed on new technologies
  • Supplementing the team with new members who have much-needed skills
  • Buying better tools that can help solve problems or enable the team to move faster


There are many ways to increase sprint velocity and we covered five that are relevant for almost all agile organizations. The common denominator is that to move faster, we must make an effort now and “plant the seeds” to enable higher productivity in future sprints.

Software quality is probably the biggest factor that will affect the productivity and effectiveness of teams in the future. A sound, tested, working codebase is an excellent foundation for developing new features. Conversely, a codebase with serious testing gaps, riddled with technical debt, can make future development very difficult.

SeaLights is part of a new category of tools which provide Software Quality Governance. Quality Governance can help you increase sprint velocity by:

  • Identifying quality risks—where to add tests that will have the biggest impact on quality
  • Identifying wasted tests—which testing activity is redundant and taking time away from new feature development
  • Supporting release decisions with data—helping teams decide which build to release to production, and decreasing the chances of production faults

For more practical advice on how to increase agile velocity with quality intelligence, learn more about Quality Governance.