You can’t spend much time in the Agile space without encountering teams doing some kind of special sprints. Whether it’s Sprint Zero, refactoring sprints, bug-fix sprints, or hardening sprints, these so-called “special sprints” are quite common. However, let’s cut to the chase: special sprints are agile banditry, and those practicing them are bandits in disguise. Here’s why they dilute your team’s ability to deliver usable, working products, and how you can avoid falling into the same trap.
The core principle of Agile is to deliver usable working products at the end of every sprint. That’s it. Everything we do in Agile, from daily stand-ups to retrospectives, supports this goal.
Agile is all about visibility and stakeholder engagement.
It focuses on continuous delivery of usable products.
This practice reduces risk and increases adaptability.
When we adhere to these principles, we’re continuously improving our product, gathering feedback, and adjusting as we go. The aim is always to keep the product in a usable state, meaning that at any point, what we deliver can be shipped to production. This is the key to managing risk in Agile.
In traditional project management, risk was mitigated through detailed planning. Teams would lay out extensive project plans and milestones that they believed wouldn’t change much over time. This method worked in predictable environments, but in today’s complex and uncertain landscapes, this level of detailed foresight is impossible.
In Agile, we manage risk by delivering incremental, usable products.
Instead of relying on rigid, long-term plans, we adjust based on what’s actually happening in real-time.
That’s why special sprints (like bug-fix or hardening sprints) are problematic. They offer a false sense of security—a “safety net”—that undermines the core Agile principle of delivering usable work every sprint.
A great example of this issue comes from the Azure DevOps team when they first transitioned to Scrum. They initially planned to run six regular sprints followed by a “hardening” or “safety net” sprint, where they’d fix bugs, clean up technical debt, and ensure everything was in good shape.
The team expected that as they worked through each sprint, they’d have an ebb and flow of incomplete tasks, or “undone work.” They imagined that by the time they reached their final safety net sprint, they’d be able to fix everything.
But here’s what really happened:
Because the team knew there was a safety net, they consistently deferred work, thinking, “We’ll fix that in the safety net sprint.”
This created a mountain of undone work, growing bigger with each sprint.
By the time they reached the safety net sprint, the work backlog was so overwhelming they couldn’t fix it all.
Realizing their mistake, the team restarted their approach. They shifted to a model of three-week sprints with no safety net at the end.
At the end of every sprint, they had to ship to production.
There was no “maybe we’ll ship”; it was an absolute must.
As a result, they were forced to pay off technical debt during each sprint, ensure high quality, and reduce the amount of undone work.
This approach led to a much healthier workflow and helped the team truly embrace Agile principles.
When teams rely on special sprints, they’re taking risks they shouldn’t be taking. They’re kicking the can down the road, hoping they’ll have time to clean up the mess later. But Agile isn’t about delaying responsibility—it’s about continuous improvement and delivering value every single sprint.
Here’s why special sprints are a problem:
They dilute focus: Teams shift from building usable products to thinking they have time to fix everything later.
They create hidden risks: The longer you delay fixing technical debt or bugs, the bigger the risks grow.
They undermine agility: Agile is about quick adjustments. Special sprints make teams slower to react because they’re piling up problems for later.
As we saw with the Azure DevOps team, safety nets lead to reckless behavior. When teams know they have a chance to clean things up later, they tend to cut corners and take more risks. This isn’t just inefficient; it’s dangerous.
Imagine a tightrope walker—if they know there’s a net below them, they might be tempted to take more chances. But if there’s no net, they’ll walk with focus and precision, knowing that every step counts. The same goes for Agile teams. When there’s no safety net, every sprint must be treated like it matters—because it does.
If you’re noticing that your team is falling into the trap of special sprints or safety nets, here are some practical steps you can take:
No Sprint Zero, no hardening sprints: Treat every sprint as a step towards a usable, deliverable product.
Focus on deliverable value: Ask your team, “What can we ship at the end of this sprint?”
If you’re being ambushed by agile bandits in your organization—those pushing for special sprints or other shortcuts—stand your ground. Agile isn’t about taking risks; it’s about mitigating them by delivering small, usable, and valuable products every sprint. If you need help eliminating these pitfalls, feel free to reach out to my team at Naked Agility, or contact a consultant who can guide your team towards true agility. Together, we can create real value, sprint by sprint—without any safety nets.
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​
CR2
