A Sprint Is a Commitment
Execution Insights
By: Brandy Brown
Custom CSS
Add your custom CSS code below
We tend to misunderstand what a sprint actually is.
It’s not a container for tickets.
It’s not a planning exercise.
It’s not a timebox to “try to get work done.”
It’s a commitment.
A sprint is an agreement the team makes to deliver a defined outcome.
Not a list of tasks.
An outcome.
The Goal Matters More Than the Tickets
Teams that commit to tickets lose sight of the outcome.
Teams that commit to a goal can adapt how they get there.
The goal is the commitment. The tickets are the path.
And if something needs to change during the sprint, the path can adapt.
But the goal shouldn’t move without intention.
Ownership Is Collective
A sprint isn’t “your work” and “my work.”
It’s ours.
The team commits together.
The team delivers together.
The team misses together.
When this breaks, you see it immediately:
work gets stuck
people stay in their lanes
no one steps in
If the commitment isn’t shared, it won’t be met.
Commitment Means Protection
When something is a commitment, you don’t treat it casually.
You protect it.
You don’t let just any request come in.
You don’t continuously reshape the work.
You don’t default to saying yes.
Because every new request has a cost.
If something new comes in, something else has to move.
Breaking the Commitment Should Be Intentional
Protecting the sprint doesn’t mean ignoring reality.
There are cases where the commitment should be broken.
But those cases should be defined—not improvised.
A team should agree on what qualifies as an acceptable interruption. For example:
- Production issues impacting functionality
- Revenue-impacting incidents
- Severity/Priority levels
Not:
- new ideas
- stakeholder preferences
- “quick asks”
If everything is urgent, nothing is protected.
When interruption criteria aren’t defined, teams default to reacting.
And over time:
the sprint loses meaning
priorities shift constantly
commitments stop being real
When You’re Ahead, Don’t Get Random
The opposite problem also shows up.
The team gets ahead.
And instead of being intentional, work becomes… opportunistic.
Engineers start:
- picking random backlog items
- fixing things that have been bothering them
- pulling in work that isn’t actually the highest priority
Progress doesn’t mean you abandon prioritization.
This is where backlog discipline matters.
The “up next” work should already be clear.
Not because it’s all product features.
Not because it’s all tech debt.
But because the team has already agreed:
this is the most important work to do next.
So when capacity opens up, the team isn’t guessing.
They’re continuing to execute against a shared understanding of priority.
If people are choosing work individually, you don’t have prioritization—you have preference.
Accountability Makes the Commitment Real
If a sprint is truly a commitment, it has to be evaluated like one.
At the end of the sprint, the question isn’t:
“Did we stay busy?”
“Did we complete some tickets?”
It’s:
"Did we deliver what we said we would?"
This shows up in simple ways:
- Did we achieve the sprint goal?
- What was our completion rate?
- What didn’t get done—and why?
Not as blame—but as signal.
A commitment that isn’t measured is just a plan.
Closing
This isn’t unique to the sprint.
The system only works if each part is treated like a commitment—planning, execution, and review.
Most teams follow the structure.
Very few treat it that way.
And the sprint is where it becomes visible.
A sprint only works if the team treats it like a real commitment.
Something they agree to.
Something they protect.
Something they evaluate honestly.
If you don’t protect it, it’s not a commitment.
If you don’t measure it, it’s not a commitment.
And if it’s not a commitment—
it’s not a sprint.
