Velocity is the metric engineering managers get asked about most and mismanage most. When delivery slows, the instinct is to add more estimation ceremonies, more standups, or more pressure. None of those things work. Velocity improves when you find and fix the specific bottlenecks that are slowing the team down - and those bottlenecks are almost always structural, not motivational. The team is not moving slowly because they are not trying hard enough. They are moving slowly because the system they work in is creating drag.
Slow velocity is not a people problem. It is a system problem. Find the constraint, change the system, and the output follows.
What velocity measures - and what it does not
Velocity measures the amount of planned work a team completes in a sprint, typically counted in story points. It is not a score of how hard the team is working, how talented they are, or how accurate their estimates are. It is a throughput signal: how much planned value is consistently flowing out of the team per sprint. The word consistently matters more than any single sprint number. A team that delivers 45 points one sprint and 12 the next has a velocity problem, regardless of the average, because the variance is telling you something important about the system.
The most important thing to understand is that velocity is only meaningful within the same team, over the same period, doing the same kind of work. Comparing velocity across teams is meaningless. Using it to evaluate individual engineers is harmful. Treating it as a commitment rather than a forecast will break trust with your team. And chasing higher numbers by inflating estimates will destroy its diagnostic value entirely.
What velocity tells you
What velocity does not tell you
The most common causes of slow velocity
Most teams that struggle with velocity are dealing with a small number of structural problems. The failure mode is trying to address several at once, which produces no measurable improvement in any of them. Before taking action, it is worth understanding which of these is actually the primary constraint for your team.
Too much work in progress
When engineers are juggling multiple stories simultaneously, the context-switching overhead is enormous. Each switch costs significant reorientation time. A team with five stories in flight per person is not five times more productive than one with a single focus - it is often slower overall because nothing reaches done.
Unplanned interrupts
Every interrupt - a Slack question, an urgent bug, a stakeholder with an ad-hoc request - pulls someone out of deep work. If your team is fielding frequent interrupts, the impact on velocity is significant and largely invisible in sprint planning. The sprint plan assumes focused work; the actual day does not deliver it.
Unclear requirements at sprint start
Stories that are not fully defined when they are picked up create mid-sprint clarification cycles. An engineer who hits an ambiguity, waits for a product decision, then restarts is occupying a sprint slot for longer than planned, creating knock-on effects across the rest of the sprint.
External dependencies
When your team's work is blocked on a decision, an API, a deployment, or a review from another team, the story sits incomplete. Blocked stories are some of the most damaging to velocity because they consume sprint slots without producing output - and they are often outside your direct control.
Technical debt
In a codebase with significant technical debt, every change takes longer because the code is harder to understand, test, and modify safely. Engineers slow down not because of individual ability but because the system resists change. This compounds over time and is invisible to anyone not reading the code.
Context switching between projects
If engineers are split across multiple products or work streams, individual productivity drops and coordination costs rise. A team that is nominally ten people but spread across three work streams has far less effective capacity than a focused ten-person team working on one.
How to diagnose your team's bottleneck
Before intervening, spend two weeks observing. The fastest way to waste effort is to implement WIP limits when the real problem is unclear stories, or invest in refinement when the real problem is a dependency on another team. One focused fix, consistently applied, will outperform three simultaneous interventions that each get partial attention.
- Look at where stories get stuckReview your sprint board at the end of each day for two weeks. Where are stories piling up? If they cluster in review, the bottleneck is your code review process. If they cluster in progress with multiple per person, the bottleneck is WIP. If they cluster with a blocked status, the bottleneck is external dependencies. The board tells you almost everything if you read it daily.
- Track completed versus startedAt sprint end, count how many stories were started versus completed. A high started-but-not-done rate almost always indicates WIP overload or unclear requirements. A low number started and completed often points to interrupt pressure or blocked work consuming capacity that never appeared in the sprint plan.
- Run a velocity retrospectiveA retrospective specifically focused on delivery speed is different from a standard retrospective. Ask directly: what is slowing us down most? Rank the answers. Your team almost always knows what the primary constraint is. They have not been asked, or the answer has not been acted on. The diagnosis is rarely the hard part.
- Audit interrupt demandFor one sprint, ask the team to note every interrupt they handle: questions, bug reports, ad-hoc requests, meetings added after planning. Most teams are surprised by the total. If interrupts are consuming more than twenty per cent of sprint capacity, that is your primary velocity constraint regardless of anything else you find.
Practical steps to improve velocity
Once you have identified the primary constraint, here are the interventions that reliably improve velocity. Pick the one that matches your diagnosis rather than trying to implement all of them at once. Each requires consistency over several sprints before the effect is visible in the numbers - do not change approach after one sprint if you see no immediate improvement.
- Introduce WIP limitsSet a rule that each engineer works on no more than two stories at a time, and ideally one. This feels counterintuitive because it looks like less work happening, but it almost always produces more completions per sprint. When WIP is limited, the team pulls new work only when existing work is done rather than starting everything at once and finishing nothing.
- Protect the sprintOnce sprint planning closes, new work can only enter by swapping out something already in the sprint at the same size. This removes the slow accretion of additional tasks that expands sprint scope without expanding sprint capacity. The team should have a clear sprint commitment they have a realistic chance of honouring.
- Invest in refinementStories should be considered ready only when they have clear acceptance criteria, no open questions, and a shared understanding of the technical approach. Spending an extra thirty minutes in refinement to prevent a story entering the sprint half-formed will save multiple hours of mid-sprint clarification. A well-refined backlog is one of the highest-leverage investments in delivery speed.
- Create an interrupt queueRather than handling every interrupt as it arrives, designate one engineer per sprint as the interrupt handler. All non-emergency requests go through them. The rest of the team stays in deep work. Rotate the role each sprint. This does not reduce interrupts but concentrates their impact on one person, protecting the majority of capacity.
- Pay down tech debt deliberatelyReserve ten to fifteen per cent of each sprint for technical debt reduction. This is not optional extra work to be fitted in around the sprint goal - it is part of the sprint plan. Teams that treat technical debt as something to address in a dedicated sprint once a year will find the debt compounds faster than they can reduce it, and velocity will decline steadily as a result.
- Reduce concurrent work streamsIf your team is officially working on two or more major initiatives simultaneously, negotiate to sequence them. A team fully focused on one stream will deliver both faster in sequence than in parallel. The reason is simple: context switching, coordination overhead, and the difficulty of getting a story to done when engineers are pulled in different directions.
For a practical structure to improve the quality of your backlog before each sprint, see our guide to running a backlog refinement session.
Measuring improvement honestly
Velocity improvements take time to show up in the numbers. The first signal is usually not higher averages but more consistent ones. A team that was delivering anywhere from 20 to 50 points per sprint and is now consistently delivering 32 to 36 is making meaningful progress, even though the average has barely moved. Consistency is the foundation. If the range of your velocity across the last six sprints is narrowing, the interventions are working.
Use a rolling average over four to six sprints rather than comparing sprint to sprint. Single-sprint comparisons are too noisy to be informative. A team with a high average velocity and high variance has a worse planning problem than one with lower average velocity and low variance, because they cannot make reliable commitments. The goal is predictable delivery, not a bigger number.
Signs velocity is genuinely improving
The goal is not to chase a number. It is to build a team that makes reliable commitments and consistently delivers them. When that happens, velocity becomes a useful planning input rather than a source of anxiety. For more on how to track what your team delivers and communicate it to stakeholders, see our guide to measuring engineering team performance.
Frequently asked questions
Keep your team's commitments visible between sprints
Capture sprint actions, track commitments with clear owners, and connect work to the people responsible for it.