Should we review estimation accuracy in sprint retrospectives?
Our team has been consistently over or under-estimating stories for the past few sprints. We're using planning poker with Fibonacci, but our estimates are all over the place compared to actual time spent.
I'm thinking we should spend time in retrospectives analyzing which estimates were off and why. Maybe look at stories we thought were 5s but took as long as 13s, and vice versa.
But I'm worried this creates a blame culture where people feel judged for their estimates. How do other teams handle this? Should estimation accuracy be part of retrospectives?
Yes, absolutely review estimation accuracy in retrospectives - but frame it correctly. It's about learning, not blame.
What works:
- Focus on outliers: Pick 2-3 stories with the biggest estimation gaps
- Ask learning questions: "What hidden work emerged?" not "Who estimated this wrong?"
- Team discussion: Whole team reflects together, not individual post-mortems
- Pattern hunting: Look for types of work consistently mis-estimated (UI work, integrations, etc.)
Questions to ask:
- What assumptions turned out to be wrong?
- What complexity did we not see during planning?
- Were there external blockers or dependencies we missed?
- Did we have the right people in planning poker to spot risks?
What to avoid:
- Don't track individual estimation accuracy
- Don't make it a KPI or performance metric
- Don't spend more than 10 minutes on it
- Don't review every story - only the outliers
The goal is to calibrate the team's shared understanding of complexity, not to "get better at guessing." When your team discusses why a story took longer, everyone learns something about your codebase, dependencies, or testing requirements.
I've seen teams improve estimation accuracy by 30-40% over 3-4 sprints just by doing this simple retrospective exercise.
We do this and it's incredibly valuable. One pattern we discovered: our backend devs consistently underestimated database migration work because they didn't account for data cleanup time.
Now we have a checklist in planning: "Does this touch the database? Add 20% for migration safety." Simple fix that came from retrospective discussions.
This is super helpful! I like the idea of focusing on outliers and asking "what did we learn" instead of "who was wrong."
I'll propose we add a 5-minute estimation review to our next retrospective and see how the team responds. Thanks everyone!
One thing I'd add: track your velocity trends, but don't obsess over individual sprint estimates. If your velocity is stable even though individual stories are mis-estimated, your overall planning is working fine.
The goal isn't perfect estimates - it's predictable delivery. Sometimes overestimates and underestimates cancel out.