The Sprint Commitment Trap: Why Your Team Works Like Strangers on a Train
We need to have an uncomfortable conversation about sprints. Not the kind where we debate story points or argue about whether that bug is a 3 or a 5. No, we need to talk about how we’ve weaponized sprint planning into something that actively prevents the very collaboration Agile was supposed to foster.
An agile coach recently shared something with me that hit hard. When I was lamenting about the bystander effect in engineering orgs, he said most of the time people don’t step up because they feel time pressure from deadlines. But here’s where it gets interesting — he follows Kent Beck’s approach of simply not answering “when will it be done?” questions. Instead, he questions where this need comes from and whether it’s actually needed.
Why does Beck do this? It’s not stubbornness — it’s about protecting his team from a no-win psychological trap. Here’s the story he tells: His manager kept asking “when will it be done?” for a project spanning 50 US states, each one different, undocumented, unpredictable. Beck refused to answer. Not once, not twice, but three times over six weeks.
His reasoning was brutal in its honesty: “If I give you a date, my team now has downside if they miss the date and they have no upside. If they hit the date, they get a pat on the head, but that’s it. And I’m not going to put my team in that position.”
Think about that for a second. We’ve created a system where meeting an estimate gets you nothing but missing it gets you blamed. As behavioral economist Daniel Kahneman showed us, humans feel losses twice as powerfully as gains. We’re literally weaponizing human psychology against our own teams.
But it gets worse. Beck identified the core dysfunction: the subtle slide from request to commitment. Someone asks “how long do you think that’ll take?” — sounds like they want information, right? But then they walk away treating it as a blood oath, never having told you that was their intent. Your estimate becomes their deadline, and suddenly you’re accountable for a promise you never made.
The real questions Beck asks instead are illuminating:
**Who wants to know?What decision rests on our answer?**Because here’s the thing — when someone asks “when will it be done?” they’re rarely asking for a calendar date. As Kevlin Henney points out, they might be asking “is this days or months?” They want to know if it’s a bicycle or a car they’re buying, not the exact delivery time down to the minute.
One developer worked with was anguishing over whether something would take 4.5 or 5.3 days, while the product manager just wanted to know if it was weeks or quarters. The developer was torturing themselves over decimal points while the manager just needed magnitude — “less than half” or “more than half” would have been enough.
Beck’s approach forces the uncomfortable conversation: Why do you need to know? Is there a real external deadline (regulatory requirement, conference demo, competitor launch)? Or is it just organizational theater — arbitrary dates that make everyone feel like they’re in control?
As the economist John Maynard Keynes observed: “The difficulty lies not so much in developing new ideas as in escaping from old ones.” The old idea is that software development is predictable. The new idea is that we should optimize for learning and adaptation instead of predictability. We left waterfall 20 years ago.
The Fractal Nightmare of Software Measurement
Here’s what non-engineers don’t understand: software has what Beck calls “the fractal measurement problem.” The closer you get to actually writing the code, the bigger the work becomes. Not just appears bigger — actually IS bigger. Every feature you implement spawns two more things you need to implement that you couldn’t have known about until you got there.
Beck puts it beautifully: “It’s like if it took you a month to weigh a baby elephant — it’s going to be bigger when you’re finished than when you started.”
And yet we ask engineers to commit to dates based on our initial, most ignorant understanding of the problem. It’s like asking someone to predict their exact arrival time for a journey to a place they’ve never been, on roads that haven’t been built yet, in a vehicle that’s still being designed. Then holding them accountable when reality doesn’t match the fantasy.
The psychological toll this takes on engineers is devastating. We jump straight to “what number is going to be on the calendar” — the naive engineering response — when what’s really being asked might be “is this bigger than that?” But because we’ve been burned so many times by estimates becoming commitments, we torture ourselves over precision nobody actually needs.
We need to distinguish between:
Targets: “We need this by 12th of July of we get a billion dollar fine from the EU” — throw things out until we can hit itCommitments: What we’re actually promising to deliver to our clients or internal teams — they may accept delays, but we need to understand who they are so we can askEstimates: A probability distribution with a ridiculously long tail, so they should be used for short term planningThe problem? Most estimates in software aren’t normally distributed as they get into the larger range. If a technical effort my engineers tell me will take a quarter it’ll be 2 minimum, if the estimate 2 Quarters, then its years. Withing a week its gets better, and this is why i think Kent encourages 1 weeks cadences with XP, 2 weeks in scrum is the norm, i think this stretches it a bit into the reins of harder to estimate what will go wrong.
This led me down a rabbit hole. Every sprint, we commit to getting X done. We call it a “commitment” but let’s be honest — it’s a deadline wearing a Halloween costume. And it’s almost worse than a traditional deadline because it comes around every two weeks like some sort of Groundhog Day of disappointment.
The No Carry-Over Revolution
Here’s what actually works, and it’s going to feel wrong at first. Teams need to be encouraged to finish whatever they take within the sprint — but not based on fixed scope. This means:
All work gets estimated in refinement, but those estimates aren’t used to criticize teams about delivery. This naturally encourages them to take fewer items. Yes, fewer. I know it feels like heresy.No commitment to planned items — as long as they don’t start working on any item without finishing it. No carry-over work from sprint to sprint. None. Zero. Zilch.Definition of done must include testing as far as technically possible. If it’s not tested, it’s not done. If it’s not done, it doesn’t move to the next sprint — it goes back to the backlog.The effect? Reduction of work-in-progress. But here’s the catch — it depends heavily on learning new collaborative practices. We’re talking TDD, pair programming, continuous integration. The stuff we all say we’ll do “when we have time.”
How to fail at this though?
Last month, I did an analysis of how my teams break down their work. What I found would make Kent Beck weep into his extreme programming manifesto. Teams were taking a single story and surgically dissecting it into six parts — each carefully crafted so one developer could work on it in complete isolation for 4–5 days. Six separate branches. Six separate worlds. One awkward merge party at the end of the week where we pray to the git gods that nothing explodes.
Each was its own story, this helps with their sprint completion, but not with “done”.
The COVID Hangover Nobody Talks About
Here’s the thing — I understand why we got here. We hired graduates during COVID whose first professional experience was working remotely, learning to code in isolation, celebrating their first production deployment over Slack. They optimized for the only thing they knew: working alone. And now, even with two days in the office, we’re still coding like we’re in separate bunkers, coordinating via smoke signals.
The Miro Rebellion
Almost all successful teams I’ve seen have ditched Jira for sprint execution. They’re using Miro with digital post-its for sprint planning and tracking. Jira might still lurk in the background for product backlog management, but for the actual sprint? It’s Miro all the way.
Why? Because Jira tends to prevent collaboration inside teams. It’s built for individual task tracking, not team coordination. It’s like using Excel to plan a dinner party — technically possible, but you’re missing the point.
This helps with the previous point some what, as teams usually do things like put screenshots and system diagrams, so they look at what they are building more holistically rather than a bunch of storying points adding up on their jira score board.
The Action Plan
So what do we do? Here’s the uncomfortable truth: this transformation takes time. Teams need to unlearn individual optimization patterns they’ve spent years perfecting. But we can start:
Immediately:
Stop treating sprint scope as blood oathsMake it explicitly okay to not finish all planned items (as long as you don’t start new ones)Push everyone onto the same branch (yes, even if it hurts)One story per feature, break it down in MiroIf you have to use Jira, use epics to track your features, and focus the team on “done” at this level, dont reward people for undone work.Next Sprint:
Move sprint tracking to Miro (keep the backlog in Jira if you must)Break stories into smaller, jointly-workable pieces in Miro, and fit feature to a sprint, if you features are two big, look at how you can release them in increments with less functionality.Introduce virtual collaboration tools for remote workLong Term:
Review performance assessments that reward individual contributionsInvest in collaborative practices (and actually use them)Schedule regular in-person workshops, even in remote-first environments
The Bottom Line
We’ve created a perfect storm of dysfunction: sprint commitments that feel like deadlines, remote work patterns that encourage isolation, and performance systems that reward individual contribution over team success. Then we wonder why nobody volunteers to fix the build.
The physicist Niels Bohr once said, “Prediction is very difficult, especially about the future.” So let’s stop pretending we can predict when things will be done. Let’s stop breaking work into individual silos. Let’s stop measuring success by how many story points we “committed” to.
Instead, let’s focus on what actually matters: delivering value continuously, working as actual teams (not just groups of individuals who happen to share a Slack channel), and creating systems that encourage stepping up rather than standing by.
Your teams aren’t broken. They’re responding rationally to the system you’ve created. Want different results? Change the system.
Now, if you’ll excuse me, I need to go convince my team to work on the same branch. Wish me luck — I’m going to need it. But at least we’ll fail together, which beats succeeding alone any day of the week.
Note: The conversations and insights shared here come from real discussions with agile coaches and observations from teams at Agoda, DKatalis, and other organizations navigating similar challenges. Sometimes the best insights come from admitting we’re all struggling with the same problems.