Are Sprints Still Worth It?

March 2026

I've been thinking about sprints lately. Not in the way people usually think about them — whether to do one-week or two-week cycles, how to run better standups, which flavour of agile is correct. I mean something more basic: is the whole idea of working in fixed time boxes still the right way to build software?

I'm not sure it is. And I think the reason is more interesting than most people realise.

Sprints were invented to solve a real problem. Before agile, software projects were waterfall nightmares. You'd spend six months writing a requirements document, six months building, and then discover at the end that you'd built the wrong thing. Sprints were the antidote. Break the work into small chunks. Ship every two weeks. Get feedback. Adjust.

This was a genuine improvement. Compared to what came before, sprints were a miracle. They gave teams a rhythm. They created natural checkpoints. They forced the question "is this actually what the user wanted?" at regular intervals instead of once at the end.

But here's what I think happened: the sprint went from being a useful tool to being an unquestioned assumption. It became the water that software teams swim in. Nobody asks whether we should work in two-week cycles. They do, because that's how software gets built. It's like asking whether you should breathe.

I want to ask the question.

The core promise of the sprint is predictability. You plan what you'll build in the next two weeks, you build it, you ship it. Stakeholders know what to expect. Managers can track progress. Everyone has a shared sense of what "on track" looks like.

Predictability is a nice thing to have. But there's a cost to it that nobody talks about, and the cost is this: the best product decisions are inherently unpredictable.

Think about the last time you built something truly good — not just functional, but good. Did it follow a plan? Or did it emerge from a sequence of surprises? You built a prototype, showed it to someone, they used it in a way you didn't expect, that revealed a better version of the product, so you threw out half your work and chased the new idea.

That process — the messy, nonlinear, follow-the-thread process — is how great products get made. And it's almost impossible to do inside a sprint.

Here's why. A sprint requires you to decide in advance what you'll build. You write tickets. You estimate points. You commit to a scope. And then the clock starts.

But what if, three days into the sprint, you discover that the thing you committed to building is the wrong thing? What if you show an early version to a user and their reaction tells you the whole approach is off?

Agile purists will say: the framework handles this. Sprints are supposed to be adaptive. A good scrum master would welcome mid-sprint scope changes. And in theory, that's right — nothing in the Scrum Guide says you can't change course. But theory isn't practice. In practice, you have a sprint commitment, a velocity to maintain, and a standup tomorrow where you need to report progress against the plan. In practice, the retro becomes about why the estimate was wrong, not about what was learned.

The framework permits flexibility. The culture it creates punishes it.

So you keep building the planned thing. You file the insight away as "something for the next sprint." You stay on track.

I watched this play out at a payments company last year. A team had committed to building a new reconciliation dashboard — two-week sprint, tickets written, points estimated. On day three, the lead engineer sat down with a finance ops manager to walk through an early version. The ops manager barely glanced at the dashboard. "I don't reconcile in the app," she said. "I export to a spreadsheet and reconcile there. What I need is the export to not be broken."

The actual problem was a CSV export that silently dropped transactions over a certain age. A fix that would take maybe a day. But the team had committed to the dashboard. The dashboard had been estimated, scoped, and blessed by leadership. Switching to the export fix would mean the sprint was "incomplete." The velocity chart would take a hit. Someone would have to explain in the review why the planned work didn't ship.

So they finished the dashboard. It shipped at the end of the sprint. It looked great in the demo. Almost nobody used it. The export bug got fixed three sprints later, after two more finance people escalated it through support tickets.

The team knew — on day three — what the right thing to build was. The sprint didn't prevent them from knowing. It prevented them from acting on what they knew.

Staying on track is the whole point of a sprint. But staying on track only makes sense if you're on the right track. And the most important moments in product development are the moments when you discover you're on the wrong track — and need to pivot immediately, not in two weeks.

Sprints optimise for finishing what you started. Building great products requires the freedom to stop what you started the moment you learn something new.

When a team finishes all their sprint tickets, what have they proven? That they can estimate work accurately and execute against a plan. That's a project management skill. It tells you the team is predictable. It tells you nothing about whether what they built mattered.

I've seen teams with perfect sprint velocity ship products that nobody uses. And I've seen messy, chaotic teams with no process at all ship products that users love. The correlation between sprint execution and product quality is weaker than anyone in the industry wants to admit.

This is because sprints measure output — did we build what we said we'd build? — when what matters is outcome — did we solve the user's problem? Product people have been saying this for years. The output-versus-outcome distinction is well-worn territory in the product management world. But knowing the distinction and building your process around it are very different things, and sprints structurally push you toward the wrong one.

When you optimise for output, you incentivise teams to pick safe, well-defined tickets. You punish exploration, because exploration is unpredictable. You punish pivoting, because pivoting means admitting the sprint plan was wrong. You create an environment where "we shipped 47 story points" feels like success even if none of those points solved a problem for a single user.

There's a deeper issue here, and it's the most uncomfortable one.

Sprints are, at their core, a management tool. They exist to make the work visible and measurable.

They let someone outside the team — a VP, a stakeholder, a board member — look at a dashboard and feel confident that things are moving forward.

That's a legitimate need. But it's a management need, not a building need. And when you design your entire way of working around making the work visible to managers, you subtly distort the work itself. You break it into pieces that are easy to estimate rather than pieces that make sense. You write tickets that are trackable rather than tickets that are true. You optimise for the legibility of the work rather than the quality of the product.

The best people I know at building software have an almost allergic reaction to this. Not because they're against accountability, but because they can feel how it warps the work. When you're deep in a problem, following a thread of insight wherever it leads, the last thing you want is to stop and ask yourself "is this going to look good in the sprint review?"

I want to be fair to sprints, because the problem they solve doesn't go away when you stop using them.

Without some structure, teams drift. Work expands to fill the time available. People spend weeks polishing things that don't matter. The sprint's two-week deadline creates urgency, and urgency — in moderation — is useful. It forces decisions. It prevents the perfect from being the enemy of the good. It creates a cadence of shipping, and shipping regularly is genuinely important.

The sprint is also a coordination tool. When you have multiple people working on different parts of a system, you need synchronisation points. You need moments where everyone comes together and asks: where are we? What's blocked? What changed? Sprints provide that rhythm.

These are real benefits, and I don't think you can throw them away. The question isn't whether to have any structure. It's whether the specific structure of the sprint — fixed time box, upfront commitment, velocity tracking — is still the right structure for how software gets built today.

And I think the answer is: increasingly, no.

Here's what's changed. Building is getting faster. Dramatically faster. When a prototype that used to take two weeks now takes two hours, the sprint cycle stops matching the speed of the work. You don't need a two-week box to build a feature when the feature takes an afternoon. What you need is a fast loop: build, show, learn, adjust. Build, show, learn, adjust. Over and over, as fast as you can.

That loop might happen three times in a single day. Or it might happen over a month, if the problem is deep enough. The right cadence depends on the work, not on the calendar. Imposing a fixed two-week cycle on top of that is like putting a metronome on a jazz musician. It gives you rhythm, but it kills the improvisation that makes the music good.

The teams I see building the best products right now don't work in sprints. They work in loops. Short, variable-length cycles driven by what they're learning, not by what the calendar says. They ship when something's ready, not when the sprint ends. They change direction the moment they discover something, not at the next planning session.

Here's what this looks like concretely. A team picks a problem — not a ticket, a problem. "Merchants are churning after their first failed transaction." They build a prototype of a retry flow and put it in front of a real merchant within hours. The merchant ignores the retry button and asks why the error message says "transaction declined" with no explanation. So the next loop isn't about retry at all — it's about surfacing the decline reason. That takes a day. The loop after that, where they rethink the whole failed-transaction screen, takes three.

Coordination happens through the work itself — short, frequent demos, not formal sprint reviews but "hey, look at this" moments. Priorities are held loosely: everyone knows what problem they're solving, but nobody has committed to a specific solution two weeks in advance. When someone discovers the problem is different than they thought, changing direction doesn't require a process. It requires a conversation.

You can't easily graph learning velocity. But you can see the results: the team working in loops ships the thing that matters in a week. The team working in sprints ships the thing they committed to — which may or may not be the thing that matters — in two.

It looks less organised. It probably gives project managers anxiety. But it produces better products, because it optimises for the thing that matters: the speed at which you learn and respond to what you learn.

So what replaces sprints?

I don't think there's a single answer, because I don't think the problem calls for a framework. Frameworks are what got us here — the idea that there's one correct way to organise software development, and if you follow the steps, good products come out.

What I'd suggest instead is a principle: organise around learning, not around shipping.

Shipping is a byproduct of learning. When you truly understand a problem and you have the tools to solve it, shipping happens naturally. You don't need a two-week deadline to force it. But learning requires flexibility. It requires the freedom to chase a thread, to throw away work that isn't right, to change direction mid-stride.

Some version of this might still involve regular check-ins, demos, and shared goals. It might look like sprints from the outside, if you squint. But the orientation is different. Instead of asking "did we finish what we committed to?" you ask "what did we learn, and how did the product change because of it?"

That shift — from measuring output to measuring learning — is small in theory and enormous in practice. It changes what you celebrate, what you punish, and what you consider a good week.

I don't think sprints are evil. They were the right tool for a particular era — an era when building was slow, feedback was expensive, and teams needed guardrails against the chaos of open-ended development.

But the era is changing. Building is faster. Feedback is cheaper. And the chaos of open-ended development is starting to look less like a problem to be managed and more like the natural state of doing creative work.

Maybe the question isn't "are sprints still worth it?" Maybe the question is: what would we do if we organised around the speed at which we can now learn?

I think we'd stop committing to plans two weeks out. We'd start committing to problems, and letting the solutions change shape as fast as our understanding does. And we'd discover that the chaos we've been managing was never chaos at all — it was the work trying to find its right form.