Every Scrum team eventually hits the same moment: the sprint review is tomorrow and two or three stories are not done. On LinkedIn the debate keeps resurfacing under labels like “sprint spillover” and “carryover” — Allen Holub has argued there is no such thing as a sprint “spillover” at all, while others call it a natural outcome of running sprints. This guide gives a practical answer to the real question underneath: what do you do with unfinished work at the end of a sprint, and how do you plan so there is less of it next time?

Why unfinished work at the end of a sprint happens

Unfinished stories are a symptom, not a crime. The most common causes are:

• Planning on velocity alone. The team pulled in last sprint’s average without subtracting PTO, holidays, support rotation, or meetings.
• Stories that were too big. Items entered the sprint without being sliced or refined to a size the team could finish in a few days.
• No real sprint goal. When the sprint is a list of tickets instead of an outcome, there is nothing to trade scope against when surprises arrive.
• Unplanned work. Production issues and “quick asks” consume capacity nobody reserved.

What the Scrum Guide implies you should do

The Scrum Guide says that when a sprint ends, incomplete Product Backlog items go back to the Product Backlog for future consideration. There is no automatic “roll over.” That small rule is the key to handling unfinished work well, because it forces a fresh decision instead of a reflex.

A five-step routine for the last day of the sprint

1. Check the sprint goal first. Was the goal met even though some items were not? If yes, the unfinished items may be lower priority than they looked.
2. Return every unfinished item to the Product Backlog. Do not mark partial work as done and do not split points to “claim” progress.
3. Let the Product Owner re-rank it. Some items will go straight back into the next sprint; others will drop down because priorities moved.
4. Re-size the remaining work. Whether to re-estimate is a team choice — we cover the trade-offs in Should You Re-Estimate Carryover Stories?
5. Bring the cause to the retrospective. Name the root cause (capacity, size, unplanned work, dependency) and pick one change for next sprint.

How to plan the next sprint so less work is left unfinished

The fix lives in sprint planning. Our Sprint Planning Guide covers the full process; for unfinished work specifically, three habits matter most:

• Plan to capacity, not to hope. Start from the hours each person actually has this sprint, then compare with velocity. Capacity tells you what fits; velocity tells you what is typical.
• Write a goal you can trade scope against. See How to Write a Sprint Goal. A clear outcome lets the team drop a low-value item mid-sprint without failing the sprint.
• Refine before you commit. Stories should arrive at planning sliced, estimated, and with acceptance criteria. Use the Sprint Planning Checklist as the entry gate.

Repeated carryover is also one of the common sprint planning mistakes we see. If it shows up three sprints in a row, the problem is the plan, not the people.

Doing this in Jira with Divim

Jira shows you which issues were not completed when you close a sprint, but it does not show whether the sprint was overloaded to begin with. Divim’s Sprint Planning, Capacity & Resource Planning for Jira puts each team member’s available capacity — minus days off and other commitments — next to the work assigned to them, so overload is visible during planning instead of at the sprint review. When unfinished items return to the backlog, Backlog Refinement for Jira helps the team re-size and re-order them before the next planning session.

Key takeaways

• Unfinished work at the end of a sprint goes back to the Product Backlog — it does not roll over automatically.
• Judge the sprint by its goal, not by the ticket count.
• Prevent repeat carryover by planning to real capacity and refining stories before they enter the sprint.

Want to see your team’s real capacity before the next sprint starts? Try Sprint Planning, Capacity & Resource Planning free on the Atlassian Marketplace.