Progress

A sudden drop in sprint velocity is a symptom, not a diagnosis. The fastest way to fix it is to work out which kind of drop you're looking at before you change anything: less work actually finished, work finished but not counted, or a change in how the team measures. This article covers what velocity measures, the most common causes of a sharp decline in startup teams, and an order of checks that gets you to the real cause with the least wasted effort.

What a Sudden Velocity Drop Actually Tells You

Velocity is the amount of work a team completes in a sprint, usually counted in story points or sometimes in issue count. It comes from Scrum and Agile practice as a planning aid: after a few sprints, a team can forecast roughly how much it can take on next time. It is not a measure of productivity, effort, or individual performance, and it was never designed to be one.

That framing matters because a drop can mean three different things:

A real drop: less work actually finished.
An apparent drop: the work was done but not counted in this sprint, usually because of carryover (unfinished work that rolls into the next sprint) or tickets left in the wrong status.
A measurement artifact: the ruler changed. A re-estimation, a new pointing convention, or a change in how tickets are split can move the number without any change in output.

Consider an illustration. Imagine a startup whose velocity falls from 42 points to 28. Looking closer, two large tickets worth a combined 14 points were merged a day after the sprint closed. The work happened, the team did not slow down, and the next sprint will probably show an inflated number as those points land. Treating that as a performance problem would have been a mistake.

Before calling anything a drop, look at context. Pull the last three to six sprints and note the normal range. Most teams swing by a meaningful amount from sprint to sprint, so one low sprint inside that range is variance, not a trend. A drop is worth investigating when it falls clearly outside your usual spread, or when it persists for two or more sprints.

Capacity Causes: Fewer Hours, Not Slower Work

Start with the boring explanations, because they are the most common and the cheapest to check. If the team simply had fewer working hours, velocity should fall, and nothing is wrong.

Look at the calendar for the sprint in question:

Public holidays and company days off
Planned PTO, especially several people out in the same week
Sick leave
A departure, which removes capacity immediately
A new hire, which usually costs capacity before it adds any

Why onboarding lowers velocity first

It is widely observed in engineering teams that a new hire reduces output in the short term. Experienced teammates spend time on setup, code walkthroughs, pairing, and review of early pull requests. That time comes out of their own planned work. The effect is temporary, but if you hired two people in the same month, a dip is expected.

Unplanned load that never reaches the board

Startups carry a lot of invisible work. An on-call incident that eats a day, a support escalation that pulls in an engineer, an urgent request from a key customer: none of these appear as sprint tickets unless someone creates them. The team was busy, but the board doesn't show it. If velocity dropped and people report feeling slammed, this is a likely explanation.

A quick normalizing check

Compare points completed per available person-day instead of per sprint. Count the working days each person was actually available, sum them, and divide the points completed by that total. Do the same for the previous few sprints.

If the normalized rate is roughly flat, the drop is a capacity effect and the team's pace is intact. If the rate fell too, capacity does not explain it, and you move on to the work itself.

Scope and Process Causes: When the Work Itself Changed

If capacity checks out, look at what the team was asked to do and how smoothly work moved through the process. Several distinct problems hide here.

Mid-sprint scope changes and interruptions

In early-stage companies, priorities move. A founder asks for a demo feature, sales needs a custom integration for a prospect, a bug from a big customer jumps the queue. Each one is reasonable on its own. Together they displace planned work, and the planned tickets finish late or not at all. Compare the tickets in the sprint at kickoff with the tickets in it at close. A large gap tells you the sprint plan was never really the work.

Larger or vaguer tickets

Unrefined stories stall. When a ticket is started without clear acceptance criteria, the engineer discovers the gaps midway and waits for answers. Estimates can also creep upward after a re-estimation session, which changes the scale itself. If the average ticket size grew, or the number of tickets that sat untouched for several days rose, refinement is a suspect.

Waiting, not working

Work often stalls between people rather than inside them. Common queues include:

Pull requests waiting for review
Tickets waiting on QA
Questions waiting on a product decision
Dependencies waiting on another team

Review queues are a classic startup bottleneck, because the same few senior engineers are both the best reviewers and the busiest builders. Check how long pull requests wait before a first review. If they sit for days, cycle time (the elapsed time from starting a ticket to finishing it) will have stretched even though nobody is working more slowly.

Tech debt and risky code

Sometimes the sprint simply landed in a difficult part of the codebase. A feature that touches legacy code, a fragile module, or an area with weak tests can take far longer than its estimate. Ask the engineers where the surprises came from. If several tickets overran in the same area, the cause is the code, and it will likely recur whenever you work there again.

The Human Layer: Morale, Burnout, and Momentum

Velocity often lags team health. After a crunch to hit a launch, a death-march release, a painful reorg, or a round of layoffs, output commonly dips weeks later, not during the push itself. The team pushed through on reserves, and the bill arrives afterward. If your drop follows a stretch like that, treat it as a delayed effect before you treat it as a process failure.

Several signals tend to appear in the activity data before they show up in delivery:

Slower responses to pull requests and review comments
Fewer commits, comments, or contributions to discussion
More reopened tickets, which suggests rushed or low-attention work
Quieter standups, with less questioning and less volunteering

None of these proves anything alone. Together, and in a team that used to behave differently, they point to disengagement or fatigue.

Be careful about the response. Pushing a tired team harder rarely restores velocity. More often it makes people inflate estimates, split tickets to look productive, or stop surfacing problems, so the number recovers while the underlying issue gets worse and harder to see. Pressure on a metric invites gaming of the metric.

The best confirmation is a conversation. Use 1:1s to ask directly how the last few weeks felt, what is getting in the way, and what people would change. Data tells you where to look; only the people involved can tell you why.

This is the layer Progress is built to read. As an AI-native engineering intelligence platform, it analyzes activity from tools like Linear and GitHub and gives you team momentum reads (is work accelerating or slowing) and team morale and wellness signals. The aim is to show you a shift in the human side of the team before it appears as a missed sprint.

A Step-by-Step Diagnostic Order

The order matters. Start with the cheapest checks that rule out the most, and move toward the ones that require conversations.

Confirm the drop is real. Check carried-over work, ticket status hygiene (done work still marked in progress), and whether estimation conventions changed. If points landed one day late, you may be finished here.
Rule out capacity. Tally PTO, holidays, onboarding, departures, and incident time. Normalize to points per available person-day.
Look at flow. Find where tickets sit longest: in progress, in review, or blocked. Use cycle time and a list of stalled work to see which stage grew.
Review scope changes. Compare sprint contents at kickoff and close, and list everything added mid-sprint.
Check team health. Look at activity patterns, then hold 1:1s to understand what the patterns mean.

The manual cost

Done by hand, this is slow. You export from Linear, cross-reference pull request timestamps in GitHub, build a spreadsheet of carryover, and reconstruct who was out when. For a manager who also has a roadmap to run, that can eat half a day, and it tends to get skipped until the problem is already large.

This is where a tool that interprets the data helps. Progress ingests data from Linear, GitHub, and similar tools and pre-computes operational signals, including flags for stalled work and emerging risks, along with initiative and work-stream health. Steps 1 and 3 largely become a matter of reading what has already been surfaced. You can also ask plain-language questions, such as which work stalled this sprint, through its MCP server and Claude integration, and get answers grounded in real activity. Confirm current capabilities against the product documentation, since features evolve as of 2026.

What to Do Next and How to Avoid Overreacting

Once you know the cause, match the response to it. A fix for the wrong cause wastes a sprint and costs trust.

Capacity: protect it. Plan sprints around available person-days, and reserve explicit room for incidents and support.
Vague or oversized work: tighten refinement so tickets are clear and small before they enter a sprint.
Review bottlenecks: set a review expectation, such as a first response within a working day, and spread review load beyond the same two people.
Too much in flight: reduce WIP (work in progress) so fewer tickets are open at once and each finishes faster.
Fatigue: give the team recovery time, and reduce scope for a sprint or two without framing it as failure.

Resist turning velocity into a target or a league table. Goodhart's law says that when a measure becomes a target, it stops being a good measure. Teams estimate differently, so velocity is not comparable between them, and a target invites inflated points.

Pair velocity with other signals so no single number drives a decision: cycle time, deployment risk and change pressure (how much merge volume and code churn is landing in a short window), and initiative health. Together they show whether the team is slower, stuck, or simply measured differently.

When you talk to stakeholders, bring an explanation and a recovery expectation. "Velocity fell from 42 to 28 because two large tickets closed a day late and one engineer was out; we expect it to normalize next sprint" is far more useful than the bare numbers.

Run the Diagnostic on Your Last Sprint

A velocity drop is a prompt to investigate, not a verdict on the team. Take your most recent sprint and walk the five steps in order: verify the count, normalize for capacity, find where work waited, compare planned and actual scope, then talk to the people. Most of the time the answer appears before you reach the end.

If doing that by hand each sprint feels like too much, consider tooling that surfaces stalled work, risk, and team momentum automatically so you spend your time on the fix instead of the search. Learn more about our services

Sprint Velocity Dropping Suddenly? How to Find the Cause Before You React