A Scrum Team begins each Sprint with a Sprint Goal and a selection of Product Backlog items it expects to complete. However, unexpected technical problems, unclear requirements, dependencies, capacity changes or overly ambitious planning can sometimes leave work unfinished when the Sprint ends.
So, what happens to unfinished work at the end of a Sprint?
It does not automatically become part of the next Sprint, and it cannot be included in the completed Increment. Instead, the unfinished Product Backlog item returns to the Product Backlog, where it can be reviewed, reordered and considered for future work.
What Does “Unfinished Work” Mean in Scrum?
In Scrum, work is considered complete only when it meets the Scrum Team’s Definition of Done.
The Definition of Done is a shared description of the quality standards that must be satisfied before work can become part of a usable Increment. These standards may include development, testing, documentation, security checks, code review and integration.
A Product Backlog item that meets most acceptance criteria but has not passed testing is still unfinished. Similarly, an item that is coded but not integrated, reviewed or ready for use cannot be considered Done.
The Scrum Guide states that work cannot be considered part of an Increment unless it meets the Definition of Done. An incomplete Product Backlog item cannot be released or presented as completed work during the Sprint Review. It returns to the Product Backlog for future consideration.
Does Unfinished Work Automatically Move to the Next Sprint?
No. Unfinished work should not automatically carry over to the next Sprint.
At the end of the Sprint, the item returns to the Product Backlog. The Product Owner then reviews its value, urgency and relevance alongside all other Product Backlog items.
The Product Owner may decide to:
- Prioritise the item for the next Sprint.
- Schedule it for a later Sprint.
- Split it into smaller Product Backlog items.
- Clarify or revise its requirements.
- Reorder it based on new business priorities.
- Remove it if it is no longer valuable.
This decision matters because priorities may change during the Sprint. A new customer requirement, market opportunity, technical issue or stakeholder request may now be more valuable than completing the unfinished item.
Automatically moving the work forward would bypass Product Backlog ordering and reduce the team’s ability to adapt.
What Happens During the Sprint Review?
The Sprint Review is used to inspect the outcome of the Sprint and discuss future adaptations with stakeholders.
The Scrum Team presents the completed results and reviews progress toward the Product Goal. Stakeholders and the Scrum Team can also discuss changing priorities, market conditions and possible next steps.
The team should be transparent about unfinished work, but it should not present that work as part of the completed Increment. According to the Scrum Guide, only work that meets the Definition of Done can be included in an Increment.
The unfinished item can still be discussed to explain:
- What prevented completion.
- What the team learned.
- Whether the item remains valuable.
- What changes may be required.
- How the Product Backlog may be adapted.
The purpose is not to hide incomplete work or blame individuals. It is to create transparency and support better decisions.
Should the Team Receive Partial Credit?
A Product Backlog item is either Done or not Done according to the agreed Definition of Done.
Teams should generally avoid counting partial story points or treating an item as 80% or 90% complete. Partial completion does not create a usable Increment and may give stakeholders an inaccurate view of progress.
For example, suppose an eight-point user story is developed but has not passed testing. Counting six points as completed would suggest that value was delivered, even though the feature is not yet usable.
When the item returns to the Product Backlog, the Developers can reassess its remaining work. They may keep the original item, split it into smaller items or resize the remaining work based on what has been learned.
Story points and velocity are optional planning techniques rather than mandatory parts of Scrum. The team should use them to improve forecasting, not to reward activity or measure individual performance.
Can an Unfinished Item Be Split?
Yes, but splitting should reflect meaningful and potentially valuable outcomes.
For example, imagine a Product Backlog item covering customer registration, email verification and profile creation. If registration and email verification meet the Definition of Done but profile creation does not, the team may separate the completed and unfinished portions—provided the completed portion is genuinely usable and independently meets the Definition of Done.
The remaining profile work can return to the Product Backlog as a separate item.
However, teams should not split work merely to make reports look better. Technical tasks that cannot deliver usable value independently should not be presented as completed product functionality.
Does Unfinished Work Mean the Sprint Failed?
Not necessarily.
The success of a Sprint is primarily evaluated by progress toward the Sprint Goal, not by whether every selected Product Backlog item was completed.
The Sprint Goal provides flexibility regarding the exact work required. During the Sprint, Developers can collaborate with the Product Owner to clarify or renegotiate scope without endangering the Sprint Goal.
A team may leave one lower-priority item unfinished while still achieving the Sprint Goal and delivering a valuable Increment.
However, regularly carrying significant amounts of unfinished work may indicate deeper problems, such as:
- Selecting too much work during Sprint Planning.
- Product Backlog items being too large.
- Requirements lacking clarity.
- Dependencies not being identified early.
- Insufficient testing or review capacity.
- Frequent interruptions during the Sprint.
- Weak collaboration within the Scrum Team.
- Impediments remaining unresolved.
- An unrealistic or incomplete Definition of Done.
These patterns should be examined rather than normalised.
How Should the Team Address Unfinished Work in the Retrospective?
The Sprint Retrospective gives the Scrum Team an opportunity to understand why work remained unfinished and identify practical improvements.
The conversation should focus on the team’s system of work rather than assigning blame. Helpful questions include:
- Was the item too large for one Sprint?
- Did the team understand the requirements?
- Were dependencies identified before selection?
- Did unexpected work interrupt the Sprint?
- Was testing left until the final days?
- Did the team collaborate or work in isolated roles?
- Were impediments raised early enough?
- Did the team select work based on capacity?
- Was the Sprint Goal clear?
The Scrum Guide explains that the team uses the Sprint Retrospective to inspect its processes, interactions, tools and Definition of Done, and then identify changes that can improve quality and effectiveness.
The outcome should be one or two realistic improvements rather than a long list of actions that the team cannot complete.
How Can Scrum Teams Reduce Unfinished Work?
Scrum Teams cannot guarantee that every forecasted item will always be completed. Complex work contains uncertainty. However, teams can reduce unfinished work through better planning and execution.
Create smaller Product Backlog items
Smaller items are easier to understand, complete, test and integrate within a Sprint. Product Backlog refinement should break large items into more precise and manageable units.
Plan according to actual capacity
Consider holidays, planned leave, support responsibilities, meetings and other commitments before selecting work.
Focus on finishing before starting
Teams should avoid having too many items in progress at the same time. Collaborating to finish the most valuable item before starting another can reduce partially completed work.
Test throughout the Sprint
Testing, review, integration and documentation should happen continuously rather than being delayed until the final days.
Inspect progress daily
The Daily Scrum helps Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog. It should identify emerging risks early enough for the team to respond.
Renegotiate scope when necessary
When work becomes more complex than expected, Developers should collaborate with the Product Owner to adjust the Sprint Backlog while protecting the Sprint Goal.
Strengthen the Definition of Done
A clear Definition of Done prevents confusion about whether an item is genuinely complete. It also helps the team make more realistic Sprint forecasts.
Common Mistakes to Avoid
When handling unfinished work at the end of a Sprint, Scrum Teams should avoid:
- Automatically extending the Sprint.
- Moving every incomplete item directly into the next Sprint.
- Marking almost-complete work as Done.
- Counting partial story points as completed.
- Lowering quality standards to finish more items.
- Hiding unfinished work from stakeholders.
- Blaming individual team members.
- Treating consistent carryover as normal.
- Starting several new items while existing work remains incomplete.
A Sprint has a fixed duration. Extending it to finish planned work weakens the regular inspection and adaptation cycle that Scrum is designed to create.
Final Thoughts
Unfinished work at the end of a Sprint is not included in the Increment because it has not met the Definition of Done. It returns to the Product Backlog, where the Product Owner can reconsider its value and order it appropriately.
The item may be selected for the next Sprint, divided into smaller pieces, revised, delayed or removed. It should never automatically carry forward without inspection and prioritisation.
Occasional unfinished work can occur because Scrum deals with complex and uncertain problems. Repeated carryover, however, should encourage the team to inspect its planning, collaboration, item size, workflow and Definition of Done.
The objective is not to maximise the number of tasks marked complete. It is to create valuable, usable Increments while continuously improving the team’s ability to forecast and deliver.
