Why your sprints keep slipping — and the four causes hiding in your data

If your sprints slip so regularly that you have stopped being surprised, you are not an outlier — you are the norm. Study after study lands on the same uncomfortable number: around 80% of agile teams roll incomplete work over every single sprint. When something happens to four teams in five, it is not a performance problem with your people. It is a structural problem with how the work is planned, tracked, and watched. The good news is that structural problems are findable. The four causes below are not mysteries. They are already sitting in your Jira and GitHub history, waiting for someone to read them in time.

Cause 1: Dependencies you found out about too late

When engineers are asked what actually sank the sprint, the single most common answer is dependencies — one recent survey put it at more than a third of all rollovers. A story is blocked on another team, a vendor API, a sandbox credential, a security sign-off. On the board it looks like one stalled ticket. In reality it is a blast radius: the three stories queued behind it that cannot even start, the engineer who context-switches to filler work, the integration test that slides to the last day.

The reason dependencies slip sprints so reliably is that boards measure the blocked ticket, not its subtree. A single 3-point story marked Blocked can be quietly holding a dozen downstream points hostage — and the burndown chart, which treats every remaining point as equal and independent, shrugs. The fix is not more diligence at standup. It is a system that reads the dependency links and prices the blocker by everything stuck behind it, the day it stalls, not the day the demo fails.

Cause 2: Scope that grew after you committed

Here is a detail most teams never notice: Jira’s own velocity report calculates committed work as the total at the moment the sprint begins. Anything added afterward — the "quick" compliance ticket, the escalation that landed on day six — is not counted against the commitment. So scope can grow 20% mid-sprint and the burndown will quietly absorb it, making a team that is drowning look merely busy.

Worse, the damage from added scope is not linear. Fifteen percent added on day two amortizes across the whole sprint. The same fifteen percent added on day ten comes dollar-for-dollar out of committed work, plus the context-switch tax of re-planning around it. And the mirror image — work quietly removed from the sprint to make the burndown look better — is invisible unless someone is watching the changelog. A real scope-change ledger records both: what was added, what was pulled, by whom, when, and what it cost the date.

A sprint rarely dies from one big blow. It dies from a dozen small fictions — a late add nobody logged, a blocker nobody escalated, a ticket closed before its review — each invisible alone, fatal together.

Cause 3: The review queue nobody is watching

Everyone hits "ready for review" in the same two-day window near the deadline, because the deadline synchronizes finish lines. The trusted senior reviewer is idle on day four and drowning on day eleven — every sprint — and everyone acts surprised. By the time a dashboard says "bottleneck," the SLA is blown and the outcome is decided. But the pileup is forecastable from the board on day seven: count who is mid-flight, know who reviews whom, do the arrival arithmetic. Small improvements in pull-request cycle time have an outsized effect on rollover precisely because review is where finished work goes to wait.

This is also the cheapest slippage to fix, because it is not a coding problem — it is a routing problem. Naming a second default reviewer and setting a 24-hour first-response norm recovers points that were already written, just stuck at the last step. You only need to see the queue forming three days before it clears, by name.

Cause 4: Carryover treated as if it were fresh

A ticket on its third sprint is not a fresh ticket with the same number on it. It is underestimated, blocked on something nobody wrote down, dreaded by its owner, or quietly deprioritized while everyone nods that "it’s committed." Planners count its five points at face value every sprint; veterans know it needs splitting, killing, or it spills again. When a fifth of every sprint is recycled carryover, your velocity is quietly over-promising — because velocity re-counts the same recommitted points lap after lap. Counting each ticket once, in the sprint it actually finishes, tells you the honest number to plan the next sprint around.

The pattern behind all four

Notice what these causes share. None of them is exotic. Each one is already recorded — in the issue links, the changelog, the review timestamps, the sprint history. What is missing is not data. It is someone with the time to read every ticket and every pull request, every morning, across every team, and connect the dots into a sentence a delivery lead can act on before standup ends. That is exactly the job KalMatrix was built to do: read your Jira and GitHub together, forecast each active sprint against your team’s own history, and surface the specific thing that is dragging it — the blocker and its blast radius, the scope that snuck in, the reviewer holding the queue, the carryover that will spill again.

Sprints do not have to be a coin flip you re-lose every two weeks. The causes are knowable, and they are knowable early — while a slip is still recoverable, not after it has been reported upward and become a broken promise. For the forecasting side of this, see why late work hurts more than its point count suggests. For the reporting side, see how a board can be green on the surface and red in the code.