Why “No Carry-Over” Policies Are a Bad Idea

14 Jan, 2025

I recently saw a discussion about a company that declared no user stories could ever carry over from one sprint to the next. If you don’t finish your story by the sprint’s end—tough luck. Start over or face consequences. Here’s my personal opinion on why this approach is misguided and how I think it hurts everyone involved.

The Policy That Makes No Sense

First of all, I find it absurd to pretend that every single piece of work can be perfectly sized and finished within a two-week window (or whatever sprint length you use). Real software development involves surprises, blockers, and last-minute changes. If a story doesn’t fit the sprint, that doesn’t magically mean it’s worthless or that the team failed. Sometimes it just needs more time.

Why It Hurts Developers

When managers issue a decree that “nothing can carry over,” it basically means:

• Cranking up the pressure: People start feeling anxious about not hitting arbitrary deadlines.
• Cutting corners: To avoid being punished for carrying a story over, teams may skip writing tests or refactoring properly.
• Working longer hours: Many developers will put in extra time to save face. That quickly leads to burnout.

In my opinion, nobody wins when quality plummets and the dev team is on the brink of mental collapse.

“Agile” Done Wrong

Managers who enforce this no-carry-over mandate often cite “Agile” or “Scrum” as justification. But that’s not how it’s supposed to work. True Agile is about adapting to change and delivering incrementally. It’s not about rigid sprint boundaries that magically fix scope. If you can never adjust your plan, you’re basically doing the opposite of Agile.

How Teams React (And Why It’s Bad)

I’ve noticed teams under these policies start gaming the system:

1. Inflated Estimates
   Triple the story points so the work looks smaller relative to the sprint.

2. Micro-Stories
   Splitting tasks into the tiniest slivers possible so they can say “finished!”

3. Low Quality
   Declaring a feature “done” with minimal testing or review just to avoid carry-over.

These coping strategies kill real transparency. Everyone ends up lying to each other to survive the process.

My Advice for Managers

• Stop Punishing Carry-Overs
  If a story doesn’t fit, it doesn’t fit. It’s not always laziness or incompetence—it’s reality.

• Collaborate on Commitments
  Let the team decide what they can actually finish. Don’t force them to meet unrealistic goals.

• Focus on Real Value
  Worry less about tracking how many stories are “done” and more about the value you’re delivering.

My Advice for Developers

• Document Everything
  Email your estimates, raise concerns early, and leave a paper trail. If there’s a blow-up later, you’ll have proof you flagged issues.

• Push Back (Politely)
  Explain that rushing or skipping tests to meet these arbitrary rules hurts the company long-term.

• Consider Other Options
  If management won’t budge and your health is on the line, it might be time to look elsewhere. Sometimes the only fix is leaving.

Final Thoughts

In my opinion, a “no-carry-over” policy is a toxic approach that fails both the team and the business. You can’t change reality by pretending stories magically become smaller just because you said so. Good Agile means adapting to unexpected problems, not punishing the people who discover them. The best way forward is honest estimates, collaborative planning, and a culture that values real progress over cosmetic metrics.