Agile methodologies like Scrum emphasize delivering working software in short, iterative cycles called sprints. Each sprint is usually two to four weeks long and is designed to produce a potentially shippable increment of the product. During sprint planning, the team selects a set of user stories from the backlog and commits to completing them within the sprint. But what happens when, despite the best efforts of the team, a story isn’t completed?

This is a common scenario in Agile teams — and how it’s handled says a lot about the maturity of the team and the understanding of Agile principles. In this article, we’ll explore the reasons stories may remain unfinished, the potential consequences, and best practices for managing incomplete work.

1. Why Stories Don’t Get Completed

Several factors can prevent a team from completing a story:

• Overcommitment: The team may have taken on too many stories during sprint planning.

• Unexpected Complexity: Sometimes, technical or business challenges emerge that were not anticipated.

• Changing Requirements: Stakeholders may adjust or add to the scope during the sprint.

• Dependencies: A story may be blocked because another task, team, or resource wasn’t available in time.

• Underestimation: The team may have miscalculated the effort required.

• Team Capacity Issues: Illness, vacations, or unexpected absences can reduce the team’s ability to deliver.

Recognizing these causes is critical for improving future sprint planning and backlog management.

2. Agile Principles Around Incomplete Stories

In Agile, unfinished work is treated as a learning opportunity rather than a failure. The Agile Manifesto values responding to change over following a plan, which means adaptation is built into the framework. However, leaving stories incomplete must be carefully handled to avoid eroding predictability and stakeholder trust.

The key principle: only completed, “done” work counts toward velocity. Incomplete stories should not be partially credited.

3. What To Do With Incomplete Stories

When a story isn’t finished by the end of the sprint, teams typically have three options:

a. Move It Back to the Product Backlog

The most common approach is to return the story to the backlog. From there, the product owner can decide whether it should be re-prioritized for the next sprint or adjusted before being scheduled again.

b. Split the Story

If part of the story was completed, it may be split into two:

• The completed portion could potentially be released if it meets the “definition of done.”

• The unfinished portion becomes a new story or task for the backlog.

c. Carry It Over to the Next Sprint

In some cases, teams decide to simply carry the unfinished story into the next sprint. While simple, this approach can be problematic if it becomes a recurring pattern, as it blurs the line of what “done” means.

4. The Role of the Sprint Review

During the sprint review, the team demonstrates what was accomplished. If a story isn’t complete, it should not be presented as finished, even if 90% is done. Instead, stakeholders should be updated on the progress and what remains. Transparency is critical here — showing incomplete work as “done” undermines trust and Agile principles.

5. Lessons for the Team

An unfinished story is a signal, not a failure. It prompts questions like:

• Did we overcommit during sprint planning?

• Did we underestimate complexity?

• Are our user stories too large (epics disguised as stories)?

• Do we have too many external dependencies?

• Are we refining the backlog enough before sprint planning?

Retrospectives are the right place to reflect on these issues and implement adjustments.

6. Best Practices for Handling Incomplete Stories

a. Write Smaller Stories

Large stories are harder to estimate and complete in a sprint. Breaking them down into smaller, testable units increases the likelihood of completion.

b. Improve Backlog Refinement

Ensure that stories are well-defined, with acceptance criteria, before they enter a sprint. Ambiguity often leads to delays.

c. Commit Based on Capacity, Not Pressure

The team should base sprint commitments on historical velocity and actual availability, not on external pressure from stakeholders.

d. Limit Work in Progress (WIP)

Teams often fail to complete stories because they start too many at once. Focusing on fewer stories at a time increases the chance of completion.

e. Use Spikes When Needed

If uncertainty about technical feasibility exists, the team can schedule a “spike” — a time-boxed research activity — before committing to building the feature.

7. Impact on Velocity and Planning

Velocity is a measure of how many story points (or units of work) a team completes in a sprint. If incomplete stories were counted, velocity would be artificially inflated, leading to unrealistic future planning. That’s why the Agile rule is clear: only finished stories count.

This also means that a sprint with unfinished stories might show lower velocity than expected. That’s not a failure — it’s a reflection of reality and an opportunity to adjust planning next time.

8. Stakeholder Communication

When a story isn’t completed, stakeholders may worry about delays. Clear communication is key:

• Explain what progress was made.

• Highlight what blocked or slowed down the work.

• Share the plan for completing the story (next sprint, split, or deprioritized).

This builds trust and reinforces that Agile is about transparency, not perfection.

9. When Incomplete Stories Become a Pattern

If a team consistently leaves stories unfinished, it’s a sign of deeper issues:

• Poor estimation practices

• Lack of refinement

• Unrealistic stakeholder expectations

• Insufficient collaboration within the team

In these cases, the Scrum Master or Agile coach should facilitate deeper analysis and help the team improve its planning and execution processes.

10. Conclusion

Unfinished user stories are a normal part of Agile development. They shouldn’t be hidden, ignored, or “fudged” into velocity metrics. Instead, they should be treated as a chance to learn and adapt.

By returning stories to the backlog, splitting them into smaller units, or carefully carrying them forward, teams maintain transparency and integrity. Most importantly, they use the experience to improve future sprint planning and execution.

Agile isn’t about completing every commitment perfectly — it’s about delivering value incrementally, learning continuously, and being transparent along the way.