Sprints Aren’t Just for Runners
How Time-Boxing saves your team
📖 Story Time
🏃♂️ Why Marathon Training Made Me a Better Agile Coach
Ever trained for a marathon? Then you already understand Agile Sprints—whether you realize it or not.
In both running and nimble working, a Sprint is a focused, time-boxed effort designed to push your limits. In agile ways of working, teams work in short cycles (often two weeks) to complete a specific goal before stopping to reflect and adjust. In running, Sprints are high-intensity intervals where you target a set speed or distance—followed by recovery and evaluation.
I love running. It’s what my body was made to do, and I feel at peace when I’m out on the road. One of the most rewarding experiences I’ve had was completing my first marathon. But here’s the thing—training for a marathon is far harder than race day itself. And one part of training, in particular, stands out as a perfect parallel to how we manage work: Sprinting.
During one session, I had to run 8 intervals of 10 seconds each at a 5-minute pace. For a 43-year-old like me, that was near my top-end speed—pushing my limits every time. But the beauty of Sprints? They always end. For these, after ten seconds. Not 9. Not 11. Ten seconds of intense running followed by a recovery interval where I could assess my performance before the next interval.
There is a similar experience in the world of managing work.
One of the practices I teach teams working in a agile fashion is to time box their feedback loops using quick working cycles, also referred to as Sprints. Similar to the running exercise, Sprints only last for a specific period of time, during which the team hyper focuses on a very specific goal.
Have you ever wanted to reorganize your garage? If you’ve ever set aside a day with the single commitment to do as much reorganizing of your garage as possible, you’ve done a Sprint. Want to launch a new website? If you’ve ever gotten all the people in the same room that were needed to launch that new site, you’ve done a Sprint.
If you’ve done any versions of a Sprint, you know the second most enjoyable aspect after doing the Sprint is…ending the Sprint. That’s right, there is no more satisfying feature of a Sprint than the fact it will always end when the given time period is over. That’s how they work. You determine the time, and that’s it. One Sprint ends, and the next one begins.
How many teams then would you guess have multiple sprints going at the same time? If you thought, “zero” you would be wrong.
I had the pleasure of coaching a friend of mine through an “Agile” journey his team was on. He was struggling because, as he put it, his team was currently in the middle of trying to finish 3 Sprints. You read that correctly. If a Sprint is defined by a specific time frame, how in the world could a team be currently working in 3 different weeks? Was this some Doctor Strange and the Multiverse of Madness type craziness?
🛬 Landing the Plane
💰 The Cost of Ignoring the Time Box
As cool as that sounds, it was not. They had made the same human error most teams I work with make. They mistook the idea of delivering the work they committed to in a Sprint as the definition of a Sprint.
But here’s the real problem: when teams ignore the time box, they fall right back into the same old ways of working—overburdened, juggling too much at once, and constantly switching focus.
Think about it—if a Sprint only ends when the work is "done," then what’s the point of calling it a Sprint? Instead of gaining clarity and focus, the team stays stuck in the endless cycle of multitasking, shifting priorities, and unfinished work. It’s like a marathoner who sprints at random points during a race without ever checking their pacing. They feel like they’re making progress, but in reality, they’re burning out before the finish line.
This is why the time box matters. It forces discipline. It forces reflection. And most importantly, it forces teams to work in a way that is sustainable, not just fast.
In other words, this team, like other teams I coach, thought the Sprint ended when the work they committed to ended. But that’s not how it works. A Sprint ends when the clock runs out. Period.
When teams violate the time box, they’re right back where they started—overburdened, switching from task to task, and never truly finishing anything. Suddenly, they’re not working in sprints at all—they’re stuck in the chaos of multitasking with no clear end in sight.
For my marathon training, I never extended a 10-second sprint just because I felt like I had to go longer. Why? Because that would undermine the entire point of structured training. The same is true for Agile Sprints. They exist to create focus, urgency, and discipline—but only if you respect the time box. When you don’t, you lose the very thing that makes them effective.
When setting a goal, adding a time frame is not about setting a due date to complete all of the work, it's about deciding how long you will focus on creating the desired outcome. This shift allows teams to work within a set period, concentrating on delivering value rather than merely ticking off tasks against a deadline.
So, the next time your team is tempted to stretch a Sprint because the work isn’t done, ask yourself: Are we running Sprints? Or are we just running in circles?
Until next time, Keep Learning, Keep Growing.
A little redundant at times but it helped sell the value of time boxing a goal or outcome. Solid work dude.