Trading sprint theater for real progress
When was the last time your team actually finished everything they committed to in a sprint?
I mean really finished — not that “eh, close enough” kind of finished where you sidestep process at the last second so you don’t have work following you to the next sprint.
“Proper testing and documentation be damned — ship it!”
If you’re thinking “well, actually” — hold that thought. Let me guess, you also found a way to inbox zero and never procrastinate, right? (If that’s seriously you, teach me your wizardly ways.)
When it comes to sprint completion, many of us are stuck in a cycle of self-deception. We plan like optimists, execute like realists, and report like creative writing majors.
But the problem isn’t that we’re bad at completing sprints — it’s that we’re measuring the wrong things and setting ourselves up for failure.
The real secret to sprint effectiveness isn’t about checking every box by Sprint Review day; it’s about delivering consistent value while maintaining team sanity and stakeholder trust.
Perfect sprint completion itself is a vanity metric.
The idealism of completed sprints
Here’s what we tell ourselves during Sprint Planning (regardless of what past experience continuously tries to teach us):
- Team carefully estimates work
- Team commits to exactly the right amount
- Team executes flawlessly
- Everything gets done on time
- ???? Product manager rides off into the sunset on a unicorn ????
Of course, here’s what actually happens:
- Team guesstimates while multitasking (does it count as multitasking if the other “task” is mentally preparing for lunch?)
- Product manager sneaks in “oh just one more thing” that’s actually three (large) things
- Unexpected production issues eat two days — not to mention the escalations that, sorry Brian, were definitely not urgent enough to be escalated
- Two people get sick, and one forgets to mention during Planning that they’ll be out for a long weekend
- Sprint Review becomes a creative writing exercise in explaining how everything that’s certainly not done is actually definitely totally justifiably done enough to count as done
Sound familiar?
We’re all out here treating sprint completion like it’s some sort of holy grail. We know it’s easier said than done, nigh impossible even (with good reason), yet we act surprised and frustrated when reality doesn’t match our perfect-world scenarios. It’s the equivalent of expecting your GPS estimates to be accurate during a rush hour ice storm (like the inch of snow that completely wrecked DC commuters in Jan 2016, which I am intimately familiar with… because I was there… in my car… for a very, very long time).
A better way forward
Now that we’ve acknowledge the pitifulness of our collective sprint completion records…
Let’s talk solutions.
But before you reach for that “Agile Transformation in 10 Easy Steps” ebook, please remember this: “fixing” sprint completion isn’t about adding more process. It’s about accepting reality and working with it instead of against it.
Here’s how to stop playing sprint theater (the broader agile theater is a conversation for another day) and start getting real work done.
1. Embrace reality-based planning
Most teams treat sprint capacity like a game of car-packing Tetris where every space must be perfectly filled to maximize throughput. But this strategy is destined to lead to unrealistic commitments and inevitable disappointment. Instead of playing a weird game of capacity chicken with your sprint, try this on for size:
- Estimate work more reasonably — it’s never as easy as it seems — some teams like to multiply by anywhere between 2 and 4, and some specifically prefer π because [engineers], but at the absolute minimum round up if there’s any debate about difficulty level and time needed
- Plan for 80% capacity (because life happens) — you can always increase this again once you get a better handle on what is realistic and what is far from it
- Stop pretending that meetings don’t exist (and get rid of the ones that don’t matter, and reorganize the ones that remain to maximize flow) — seriously, do some math with me here, if each engineer can do 10 points per sprint, but meetings take up 50% of their time (and destroy any hope for flow during the other 50%), then how many points do you think they’ll actually get done?
- Acknowledge that if everything is P0 then nothing is, and also acknowledge that that means stack ranking is the way of the world (at the end of the day, you can only do one thing at a time) — just because you squeezed those three extra super important bugs into the sprint, doesn’t mean they’re going to actually get done if you keep them at the bottom of the queue
- Accept that all the above means less committed work, but also more reliably completed work and better expectation management for anyone with any visibility into the goings-on of the team
Yes, your sprint will look emptier on paper. But you’ll be amazed at how much gets done when you quit acting like your team can bend the space-time continuum.
2. Measure what matters
Sprint completion is a nice target, don’t get me wrong. But it’s not the end-all and be-all you need to be focused on. And if you’ve already done the above step 1 (reality-based planning), it won’t continue to be the bane of your poor expectation management existence, which means you can focus on more important matters:
- Value delivered to customers — if you do nothing else, do this, because at the end of the day, without value you can’t differentiate, and without differentiation you won’t survive
- Velocity & momentum — I’m not going to argue that number of points completed is more important than the difficult-to-quantify-in-the-short-term value which users actually need from you, but it’s still a decent indicator for how much you’re getting done (you just need to also separately make sure the stuff you’re doing is actually useful) — so, how much work are you getting done, and are you doing it consistently?
- Team sustainability — there are sprints, and there are sprints — don’t expect your team to always be running at Usain Bolt speeds; burnout is real, painful, and morale-destroying — you’ll do much more harm in the long term than any gains you made in the short term
- Prediction accuracy — even if those predictions don’t match your (initial) hopes and dreams, having a realistic idea of when code will deploy / features will ship / customers will be made happy / etc. is going to make everyone’s life a bit more manageable — plus, as you track how well you’re doing over time, you can gradually improve those predictions and plan even better
- Quality of output — because rushing to check boxes just to call the sprint done really just means you’re cutting corners that shouldn’t be cut
These metrics might be harder to track than a simple burndown chart, but they’ll be more informative as to what’s really going on with your team’s effectiveness and health.
3. Create better feedback loops
Your agile ceremonies shouldn’t feel like a series of status reports and guilt trips. On the contrary, they should be opportunities for genuine collaboration and improvement. A little meeting transformation may be in order:
- Daily Standups should be about accomplishments and obstacles, not mechanical status updates
- Retrospectives should offer an opportunity to dig into systemic issues, not turn into rant sessions about individual tickets
- Backlog Grooming should be a chance to question assumptions and trim fat, not a rubber-stamp session for every idea that crosses someone’s mind
- Sprint Planning should focus on understanding the work, not playing estimation poker until someone gives up
- Technical discussions should surface dependencies and risks early, not become design-by-committee marathons
- Stakeholder updates should celebrate progress and learning, not become a finger-pointing exercise about what’s (or who’s) to blame for projects running long
When you shift from “why isn’t this done?” to “what’s getting in our way?”, you’ll start seeing real improvements in how your team works together.
4. Reset expectations
It’s straightforward to change processes — it’s a bit more difficult to get everyone in the company to adapt to new processes. This includes not just your team, but also the stakeholders who are paying (perhaps a bit too much) attention to what your team is doing. Have honest and transparent conversations to clarify the new way of working; discuss:
- What “done” really means — this goes beyond definition of done into a mentality that boxes being technically checked does not necessarily count
- Why estimates are called estimates — everyone deep downs knows this, but explicitly saying it out loud can be cathartic and get everyone to stop pretending
- How uncertainty is normal and expected — more often than not, work will proceed more slowly than expected; build in some buffer room and always round up
- When it’s okay to say “I don’t know” — it’s better to know what’s unknown than to have everyone lying to themselves about what they claim to know, which also has a horrible downstream affect of impacting other work and plans
These conversations can be uncomfortable at first, but you need to rip off the proverbial band-aid. Stakeholders might not love hearing that work will take longer than they’d like, but they’ll appreciate not being sold a fantasy. And meanwhile, your team should be able to breathe easier knowing they have the space to do their job (and do it well).
Sprint toward success
Back to the titular question. Does anyone really ever “complete” a sprint? Of course they do — but that doesn’t mean things are going well.
After all, would you rather:
A) Complete 100% of a sprint that delivers minimal value
B) Complete 70% of a sprint that moves the needle
(Please tell me you picked B.)
So, instead of chasing that perfect sprint, stay focused on:
- Planning based on reality (i.e., consider how things tend to go down in the real world)
- Delivering consistent value and measuring true metrics of success (for the product, the team, and the company)
- Learning and improving (continuously, forever)
- Managing expectations well (through trust and transparency)
If you do all this, you may indeed end up with some of those coveted perfect sprints.
But that’ll just be a bonus.
The real win will be the maximal value you provided your customers along the way.
Does Anyone Really Ever “Complete” a Sprint was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.
