What is Velocity, and Why It’s Not That Important #

Velocity is defined as: “The amount of work (not value) that was delivered (not done) by the team in a sprint.”

In other words, it’s a measure of the completed work—not necessarily the value it brings to the product or the customer.

While velocity is often treated as a critical measure of progress, it’s actually a very limited metric. Its only real use is to help the team approximate how much work to focus on for the next sprint. Beyond that, velocity isn’t as crucial as many people assume, and here’s why.

The Real Use of Velocity #

The primary reason to track velocity is to determine how many Product Backlog Items (PBIs) to pull from the backlog for the next sprint. The team’s velocity gives a rough idea of what’s manageable within a sprint, which can help guide the discussion around how many PBIs to bring in.

Agile teams maintain a large backlog of items, and it’s not efficient to discuss or estimate all of them every sprint. Instead, we “siphon off” a few PBIs from the top of the backlog—just enough for the team to begin discussing, estimating, and planning for the sprint. Velocity helps give an idea of what “just enough” might look like, but it’s not an exact science.

If we bring in too few PBIs, the team might finish early and need to have more discussions and estimations mid-sprint to pull in additional work. That’s not ideal, but it’s not a big problem either.

If we bring in too many PBIs, some may remain unfinished by the end of the sprint. In this case, we’ve invested time in discussing and estimating items we didn’t work on. Again, not ideal, but it’s not a huge issue.

The goal is simply to pull in a manageable number of PBIs that the team can invest time in discussing. And if we misjudge that number, it’s not the end of the world.

Why Velocity Fluctuates #

Many teams get hung up on maintaining a consistent velocity, but there are plenty of reasons why velocity naturally changes from sprint to sprint. Here are a few examples:

Different People Estimate Differently: Estimation is subjective. If a team member with deep experience in a particular area estimates a task, they may view it as quick to complete. But if someone else ends up working on it, it might take twice as long, impacting velocity.
Dependency on Important Resources: Some PBIs depend on external resources—perhaps a database setup, accessibility review, or procurement of a software library. If these dependencies aren’t met in time, the team may be delayed, impacting the sprint’s velocity.
Varying Complexity of PBIs: Some sprints may include straightforward PBIs, while others are packed with complex work that requires more problem-solving, testing, and refinement. Naturally, this variation affects how much can be delivered in a sprint.
Team Composition Changes: When team members join, leave, or are temporarily unavailable, it affects velocity. A sprint with the full team may complete more PBIs, while a sprint with fewer members will likely deliver less.

The Problem with Treating Velocity as a Goal #

A common misconception is to see velocity as a target. This pressure can lead to undesirable behaviors that actually harm the quality of the work:

Cutting Corners to Meet “Velocity Goals”: When velocity is treated as a benchmark of success, team members may feel pressured to complete all the PBIs within the sprint, even if time is tight. To achieve this, they may cut corners on testing, skip handling edge cases, or leave documentation incomplete—just to close tickets and meet an arbitrary velocity target.
Slowing Down to Maintain “Stable Velocity”: Conversely, if team members finish PBIs early, they may slow down or delay checking in their work to avoid increasing the expected velocity for future sprints. Some teams might unconsciously “manage” their velocity to a stable level, to avoid creating pressure from upper management or stakeholders who might expect an ever-increasing velocity.

Both of these scenarios result from a misunderstanding of what velocity is and how it should be used.

Misuse of Velocity and Its Impact #

Putting too much importance on velocity leads to a fabricated sense of productivity. When velocity becomes a goal rather than a guide, teams may start taking steps that aren’t necessarily in the best interest of the product, the user, or even the team itself. The emphasis on velocity can:

Shift focus from the quality and value of work to the speed of task completion.
Create unnecessary pressure, leading to rushed or subpar work.
Result in artificial manipulation of the team’s pace, reducing transparency and honesty.

Final Thoughts: Velocity as a Guide, Not a Goal #

In reality, velocity is just a tool to help us decide how much work to plan for the next sprint. It doesn’t measure quality or value, and it shouldn’t be used to judge the team’s effectiveness. Teams will deliver differently from sprint to sprint, and that’s perfectly normal. By understanding that velocity is a simple planning tool, not a measure of value or productivity, agile teams can keep the focus where it belongs—on delivering high-quality work that brings real value to users.

So, while velocity is helpful for planning, it’s not nearly as important as many teams make it out to be. Keep your eyes on the bigger picture, and use velocity to guide—not dictate—your sprints.