Why your team overcommits every sprint (and it's not optimism)
The usual explanation for overcommitment is "engineers are optimistic." That's not wrong, but it's not the root cause. Blaming optimism makes overcommitment a personality trait, which makes it unfixable. It isn't.
Here are the real causes, roughly in the order they bite.
1. Unclear capacity
If planning starts from the backlog instead of from available time, there's no constraint. You pull in issues until someone says "that feels like enough" — and "enough" is always higher than deliverable. No one is calculating capacity; they're calibrating to a vibe.
This is the single biggest cause and the one least discussed. Fix the input and most of the rest improves.
2. Last cycle looked better than it was
Carry-over issues get silently closed, rescoped, or moved. The team looks at last cycle's "completed" count and plans similar. But a chunk of that "completed" was half-done work that finished in the first 2 days of the next cycle. The real delivery number was lower — you're planning against a mirage.
3. Invisible work
On-call, meetings, interviews, reviews, production support, mentoring, hiring. None of it's on the board. None of it's estimated. At planning you act like the cycle is 100% delivery time. It isn't — on a typical team it's more like 55%.
4. Sunk-cost estimates
An issue estimated at 5 points two cycles ago is still sitting in the backlog at 5 points. Nobody re-estimates. It's now actually 8 (scope crept) or 3 (the team learned something). Planning with old estimates is planning with lies told with a straight face.
5. Pressure to show up with commitment
If leadership treats the commit as a promise, teams commit to avoid the hard conversation. Then they miss. Then trust erodes. Then the next commit is even more defensive. The fix isn't willpower — it's the social contract around what "commit" means.
6. Rescoping pretending to be re-planning
Something urgent drops in. Instead of taking something planned out, the team just adds it. The committed list still looks the same on paper, but something else is now going to slip. Nobody updates Linear; at cycle end, nobody understands what happened.
7. No cycle goal, only a list
"Finish these issues" isn't a goal — it's an inventory. Without a goal, there's no answer to "can we drop this one?" So nothing drops. So the list stays too long.
How to fix each one
- Unclear capacity: compute it before opening the backlog. If the number's scary, the number's right.
- Last-cycle misreading: review committed vs delivered, not just delivered. Carry-over is data, not noise.
- Invisible work: create Linear issues for it. Visible work can be planned against.
- Sunk-cost estimates: re-estimate at planning for anything older than one cycle.
- Pressure: commit to a cycle goal (one outcome), not a list of issues. Much easier to renegotiate.
- Rescoping: every urgent add means an explicit cut. Update Linear in both directions.
- No cycle goal: one sentence, decided before issues are selected.
The thing to change first
If you only change one thing, change the starting point of planning. Start from capacity, not from backlog. Everything else is downstream of that.
Teams don't fix overcommitment by "being more realistic." They fix it by building planning that makes realism the default.