Special Sprints: Agile Banditry or Risk Management?

Published on
5 minute read

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 Purpose of Agile: Delivering Usable, Working Products

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.

Traditional Risk Management vs. Agile Risk Management

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.

Case Study: The Azure DevOps Team

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 Problem With Safety Nets

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.

The Solution: No More Safety Nets

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.

Why Special Sprints Are Agile Banditry

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.

The Safety Net Trap

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.

How to Avoid Agile Banditry in Your Team

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:

1. Eliminate Special Sprints

  • 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?”

2. Pay Off Technical Debt Early

  • Don’t let technical debt build up over multiple sprints. Make it a priority to clean up code, fix bugs, and address issues as they arise.

3. Set Clear Expectations

  • Make it clear to the team that every sprint must produce a usable product. There’s no such thing as “we’ll fix it next time.”

4. Continuously Improve

  • Use retrospectives to identify where your team is cutting corners or deferring work. Address these issues head-on.

Agile Bandits Beware!

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.

You can’t have spent any time in the agile space without encountering people doing some kind of special Sprints. They might be doing Sprint zeros, they might be doing refactoring sprints, they might be doing bugfix sprints, they may be doing hardening Sprints. Whatever special type of Sprint they’re doing, it is absolutely agile banditry, and those that are doing it are just bandits. They’re not doing good things. Special Sprints reduce and dilute our ability to deliver usable working product.

So the whole purpose across the board, the whole purpose of agile practices is to enable that visibility and connection with the stakeholders with continuous delivery of usable working product, and that’s how we manage risk in agile. In the old traditional model, we managed risk by having a detailed plan, right? That was our management of risk. Here’s my full detailed plan because things aren’t going to change that much; this plan will work.

But in the complex cognitive space that we tend to operate in, when there are more unknowns than known, you need a different way of managing risk. In all of agile, we do that by creating usable working product. That’s our key risk mitigator because we can’t document everything that’s going to happen because there are too many surprises. So having those usable working products mitigating that risk, no special Sprints is key there.

A great example of that is a scenario that happened to the Azure DevOps team when they first started moving towards this agile thing. They were kind of moving towards this scrum thing, and they decided initially that they would have six Sprints, six three-week Sprints, and then they would do a kind of hardening bug fixing, you know, safety net, some kind of safety net Sprint. I don’t remember specifically what they called it; it was some kind of safety net Sprint.

What they expected to happen was, as each Sprint started and completed, that you would have a kind of ebb and flow of undone work, right? Whatever you want to call it, of undone work, of technical debt, of things that weren’t quite right. They would have this little uptick, and then towards the end of the Sprint, it would come back down again. Then the next Sprint would have a little bit undone, and then it would come back down again. Maybe there’d be a little bit left over at the end of a Sprint, but then we’d pay it back the next Sprint.

But because they had that safety net, and because every single member of every single team knew that they had that safety net, they thought constantly, “Well, I’ll just leave that for our safety net. We’ll leave that for our safety net Sprint.” It happened so much that instead of that kind of ebb and flow of undone work, they ended up with a nice little upward curve trajectory of undone work. They got to that sixth Sprint and realised that they had more work that they could do in the safety net to pay it back and create a usable working product. It wasn’t working.

So what did they do? They restarted the whole thing. “Let’s start again, and we’re just going to do three-week Sprints, and at the end of every three-week Sprint, we’re going to ship to production.” Not a maybe; we’re going to. So we have to have good quality, we have to have paid back our technical debt, we have to have as little undone work as possible going into the next Sprint because there is no safety net.

People who have safety nets take risks, and if you have a safety net, that’s agile banditry. If you’re being ambushed by agile bandits in your organisation, then my team at Naked Agility can help you, or we can help you find a consultant or expert who can. You can set up a no-obligation consultation using the links below. Don’t forget to like and subscribe if you enjoyed this video.

People and Process Agile Project Management Agile Product Management Value Delivery Product Delivery Agile Transformation Scrum Product Development Agile Philosophy Agile Planning Agile Frameworks

Connect with Martin Hinshelwood

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.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

SuperControl Logo
Bistech Logo
Workday Logo
Flowmaster (a Mentor Graphics Company) Logo
Boeing Logo
Illumina Logo
ProgramUtvikling Logo
DFDS Logo
Schlumberger Logo
Jack Links Logo
Milliman Logo
Big Data for Humans Logo
MacDonald Humfrey (Automation) Ltd. Logo
Genus Breeding Ltd Logo
Alignment Healthcare Logo

CR2

Freadom Logo

NIT A/S

Ghana Police Service Logo
Nottingham County Council Logo
Department of Work and Pensions (UK) Logo
Washington Department of Transport Logo
New Hampshire Supreme Court Logo
Washington Department of Enterprise Services Logo
Higher Education Statistics Agency Logo
Emerson Process Management Logo
ProgramUtvikling Logo
Milliman Logo
Philips Logo
Slicedbread Logo