Learning Objectives
By the end of this lesson you will be able to:
- Distinguish between under-commitment and over-commitment and their different root causes
- Explain the psychology behind sandbagging and scope creep
- Apply historical velocity and capacity calculation to set realistic sprint commitments
- Describe three techniques for protecting sprint commitments once set
The Commitment Paradox
Sprint commitment seems simple: put in what you can do, do what you put in. But teams consistently fail at this in both directions — committing too little (under-commitment) or too much (over-commitment) — and for surprisingly different reasons.
Getting commitment right isn't about motivation or effort. It's about the system your team operates in.
Under-commitment: The Sandbagging Trap
Under-commitment is when a team consistently completes their sprint goal with days to spare, or routinely pulls in only a fraction of what they could handle.
Why It Happens
Risk aversion after failure: A team that over-committed for three sprints and got burned learns to protect itself. Padding estimates and pulling in fewer stories is a rational response to irrational pressure.
Sandbag culture: If management uses velocity as a performance target ("you must hit 40 points"), teams rationally learn to report a lower number and consistently "exceed" it. This is gaming, not planning.
Lack of backlog depth: The team can't commit to more because there aren't enough refined, ready stories available. The bottleneck isn't capacity — it's preparation.
The Cost
Under-commitment wastes capacity. Stakeholders lose trust in forecasts ("they always finish early, why can't they do more?"). And when teams never stretch, they miss the improvement feedback that comes from occasionally being slightly ambitious.
Pro Tip: If your team consistently finishes with 2+ days to spare, your real problem is probably the backlog, not the team. Is there always a ready-to-pull stack of refined stories?
Over-commitment: The Optimism Trap
Over-commitment is when a team commits to more than they can realistically deliver — and then either drops stories, "finishes" them partially, or burns out trying to complete everything.
Why It Happens
Optimism bias: Humans consistently underestimate how long tasks take (planning fallacy). Without historical data as a corrective, teams plan based on "if everything goes perfectly."
External pressure: Management, POs, or stakeholders push for a committed scope. The team agrees to keep the peace rather than push back honestly.
Unplanned work not accounted for: Bug fixes, urgent requests, team member absence, and technical debt repayment consistently consume 20-30% of sprint capacity. If your plan assumes 100% capacity, it's already wrong.
Velocity that hasn't been adjusted for change: A new team member means velocity resets lower. A key person off for a week means capacity drops. If you plan based on last sprint's velocity without adjusting, you're setting up for failure.
The Cost
Missed sprint goals erode trust. The Scrum principle of predictability breaks. Teams start heroically pushing to "close" stories by Friday — creating the partial-credit and scope-slimming patterns that corrupt your metrics.
Building Commitments That Hold
Technique 1: Capacity Calculation
Don't use velocity alone. Calculate actual available capacity:
Available capacity = (team size × sprint days) - planned absences - known ceremonies - buffer for unplanned work
A typical buffer for unplanned work is 20-25% of total capacity. If you have 5 developers × 10 days = 50 dev-days, plan for ~37-40 dev-days of story work.
Technique 2: Historical Focus Factor
Track your team's "Focus Factor" — the percentage of raw capacity that converts to completed story points:
Focus Factor = (velocity for sprint N) / (total team capacity in days for sprint N)
Average this over 3-5 sprints. Use it to convert capacity to realistic velocity. A Focus Factor of 0.7 means a 50-day capacity sprint should target ~35 story points.
Technique 3: The Commitment Conversation
When pressure to over-commit comes from outside the team, use the scope/time/quality triangle explicitly:
"We can commit to 35 points reliably. If the 40-point target is non-negotiable, we need to discuss either extending the sprint by one day, reducing quality expectations on these specific stories, or removing these two stories from the sprint."
This isn't refusing to work. It's negotiating with data.
Summary
Under-commitment and over-commitment have different root causes but share the same solution: commitments grounded in historical data, realistic capacity calculation, and honest negotiation. Teams that build this discipline make Scrum's predictability promise real — which is ultimately what gives product teams and stakeholders the confidence to plan ahead.