The problem with most sprints

It already starts with the name.

Sprint: a burst of speed.

That is at least what comes to mind for me when I hear the term. And if you think of an actual sprint in sports, the mismatch shows up pretty quickly.

There is one thing that has always annoyed me about the word sprint in Scrum: the burst part.

Who does a two week sprint, immediately followed by another one?
And another one?
And another one after that?

The sprints I know from sports require preparation, training, and regeneration. They are short by definition. They are intense by definition. And they only work because they are bounded.

Where is that in Scrum?

That does not automatically make it useless. Timeboxes can still be helpful. Planning can still be helpful. Review and retros can still be helpful.

But calling it a sprint always felt a bit off to me.

What many teams call a sprint feels more like a never ending treadmill you can only step off of and call it a day. The calendar says “two weeks,” so everyone agrees to pretend this is a burst of focused execution. But structurally it often looks more like continuous moderate-intensity output. And of course, the ritual comes with it.

Recently, I experienced something with coding that felt much closer to an actual sprint: 20 issues, 2 hours of work, and a first iteration live on the dev system.

This is what the work looked like in practice: a prepared milestone, linked issues, and a merge request ready to move quickly without extra coordination overhead.

That felt like a burst.

Not because I suddenly became a 10x engineer after drinking the sacred AI potion. And not because prompting is some new industrial religion. It felt like a sprint because the system was prepared to absorb one.

That preparation matters more than the burst itself.

The repo was in a state where fast iteration was possible. The tasks were already set up. The architecture had enough guardrails. CI/CD existed. The output was reviewable. There was a path from “do the work” to “see the result” with incredibly little friction.

That is much more useful to me than “two weeks passed and we have some Jira statistics to discuss.”

A sprint should not just be a block on the calendar.

A sprint should feel like a sprint.