Estimation Pitfalls in Scrum: A Checklist to Dodge Them This Sprint
Estimation is one of the most misused practices in Scrum. The Scrum Guide does not mandate story points, planning poker, or any particular technique — it simply says the Developers are responsible for sizing the work and that the Product Owner and Developers refine the Product Backlog so items are ready. Yet teams routinely turn estimation into a source of pressure, false precision, and friction. By 2021, with most planning happening over video calls, the quiet distortions in how teams estimate had only grown harder to spot.
Below is a checklist you can apply in your next Sprint Planning or refinement session. It will not make estimates perfect — nothing does — but it will keep them honest and useful.
The estimation checklist
Estimate as a team, not as individuals. The point of techniques like planning poker is to surface differing assumptions. When the loudest voice or the senior developer sets the number, you lose the conversation that makes the estimate worth anything.
Treat estimates as relative, not as hours in disguise. Story points compare effort and complexity between items. The moment someone declares 'a point equals a day,' you have rebuilt time estimation with extra steps and lost the value.
Refine before planning, not during it. Items dragged into Sprint Planning with no prior discussion get guessed at. Ongoing refinement means the team has already wrestled with the big unknowns.
Split anything too big to reason about. A huge estimate is the team telling you they do not understand the item. Break it into pieces small enough that the uncertainty becomes visible and discussable.
Use velocity to forecast, never to judge. Velocity helps the team plan how much to pull into a Sprint. The moment it becomes a performance target, people inflate estimates and the number stops meaning anything.
Re-estimate when you learn something. An estimate is a snapshot of what you knew at the time. When new information lands, update it rather than defending a stale guess.
Warning signs to watch for
Estimates that never change, which usually means the team is reverse-engineering them to fit expectations.
Managers comparing point velocities across different teams as though they were the same currency.
Long debates over whether something is a three or a five, when the gap rarely affects the decision.
A Product Owner negotiating estimates downward, which corrupts the only honest signal the Developers can give.
The healthiest way to think about estimation is as a conversation, not a number. The discussion that produces a five — surfacing a hidden dependency, a testing concern, an unclear requirement — is usually worth more than the five itself. If your sessions produce numbers without that conversation, you are measuring agreement to move on, not shared understanding.
Pick two or three items from this checklist and apply them in your next session. You will likely find that the goal was never accuracy. It was a team that understands the work well enough to commit to a Sprint Goal with confidence.
If your teams want to sharpen how they plan, estimate, and deliver, XNM's program & project delivery advisory can help you build agile practices that hold up under real pressure.