Cause one: items are too big to finish inside a Sprint
If a single item takes most of the Sprint, one bad day is enough to push it over the line. Teams often notice this only at Sprint Review, when the item is ninety percent complete and has been ninety percent complete for four days.
The practical fix is slicing by outcome rather than by layer. An item that delivers a thin, usable slice end to end can finish. An item split into 'backend', 'frontend' and 'tests' cannot finish until all three land, which puts the whole thing at risk right up to the last hour.
- Set a working rule that no item should take more than a third of the Sprint
- Split by user-visible outcome, not by technical layer
- Treat any item still open after half the Sprint as a planning signal, not a status update
Cause two: there is no Sprint Goal, so nothing can be dropped
A Sprint without a goal is a list of unrelated tickets. When the team gets squeezed, there is no basis for deciding what to cut, so everything stays in and everything slips a little. A real Sprint Goal makes that decision easy: work that serves the goal stays, work that does not can move without an argument.
You can test this in one question at the next Daily Scrum. Ask the team what the Sprint Goal is. If you get four different answers, carry-over is the predictable outcome, not bad luck.
Cause three: work starts before it is ready
Items that arrive in the Sprint with open questions spend their first days waiting for an answer. The clock is running the whole time. Teams that refine continuously, in small doses, rather than in one long session before planning, tend to start Sprints with items that are actually workable.
A simple entry check helps: does the team understand what done looks like, is any dependency identified and has someone confirmed the external piece is available. Three yes answers beat an elaborate Definition of Ready document nobody reads.
Cause four: interruptions are absorbed silently
Production issues, support escalations and favours for another team are real work. When they are handled off the board, the Sprint looks like it failed for no reason. Making them visible does not slow anyone down; it changes the conversation at the Retrospective from 'we were slow' to 'thirty percent of our capacity went somewhere we never planned for'.
Some teams reserve explicit capacity for this. Others log the interruption as an item the moment it starts. Both work. Pretending it did not happen does not.
What to change first
Pick one Sprint and change one thing: agree a Sprint Goal you can say in a sentence, and slice every item so it can finish in a few days. Do not add process on top. Most teams see carry-over drop within two Sprints, and the ones that do not usually discover their real constraint is interruptions, which is a much easier conversation to have once the other two causes are ruled out.
Not sure which of these is actually happening in your team?
The team assessment asks everyone the same questions anonymously and shows you where people disagree about how the team really works. It takes about twelve minutes per person.
Run a team assessmentFrequently asked questions
Is carrying work over between Sprints against Scrum?
No. The Scrum Guide expects unfinished items to return to the Product Backlog so the Product Owner can reorder them. What matters is whether it happens every Sprint, which usually points at item size, a missing Sprint Goal or unplanned work.
Should we re-estimate carried-over work?
Only if what remains is genuinely different from what was planned. Re-estimating the remaining slice can help forecasting, but subtracting 'work already done' from an estimate tends to turn planning into accounting and adds little.
Does carry-over mean the Sprint failed?
Not on its own. A Sprint succeeds or fails on its Sprint Goal, not on ticket completion. A team can finish every item and still miss the goal, and a team can carry one item over and still deliver what mattered.
How do we stop half-finished items piling up?
Limit how many items are in progress at once. Teams that start five things and finish one carry four over. Teams that start two and finish two carry nothing over, with the same people and the same hours.