Turning a Team’s Hatred of Estimation into a More Productive, Less Stressful Practice
If you’ve worked in Scrum for any length of time, you’ve probably noticed that estimation is one of the most universally disliked activities in software development. It’s not that people are lazy—it’s that estimating is tricky business. It feels like predicting the weather for a place you’ve never been to, three months in advance, while stakeholders hold an umbrella over your head waiting to see if you’re wrong.
For one of my past teams, estimation frustration was at an all-time high. In particular, I had a teammate who despised doing it. And honestly, I couldn’t blame them.
Why Estimation Can Be Painful
There are a few common reasons estimation makes people twitch:
- Inaccuracy feels inevitable. The work often changes as you get into it, so nailing down an “exact” number feels like guesswork.
- Historical misuse. Stakeholders sometimes take estimates as hard promises, then weaponize missed deadlines in performance discussions.
- It interrupts flow. Many developers just want to code, not debate whether something is a “3” or a “5” on the Fibonacci scale.
This was exactly the situation my teammate was in. Every estimation meeting was like pulling teeth. I knew if we kept forcing them through the same process, we’d get resentment instead of insight.
Shifting the Conversation
Scrum is a framework, not a rigid rulebook. Its foundational principles—transparency, inspection, and adaptation—exist so you can experiment and improve. So I decided to adapt.
Instead of asking the team for a single number that tried to capture all factors of an item’s “size,” I broke estimation into three separate categories:
- Effort – How much actual work does this feel like?
- Risk – How many unknowns or potential blockers are lurking here?
- Complexity – How tricky is the logic, architecture, or integration work?
Instead of numbers, we used T-shirt sizes: XS, S, M, L, XL.
This took away some of the pressure to be “exact” while also letting people separate different dimensions of the work.
Building Trust with Data
Here’s where it got interesting: I didn’t stop at collecting estimates. I tracked the actual time it took for each task over about a quarter. This gave me a small but meaningful dataset to work from.
From there, I created thresholds for each T-shirt size in each category based on reality, not gut feel. For example:
- An “M” Effort item was often 3–4 days of work.
- An “L” Risk item usually introduced 1–2 days of delays.
- An “S” Complexity item had minimal architectural review.
Now, when I spoke with stakeholders, I didn’t expose the raw T-shirt sizes directly. Instead, I translated those into safe, high-level ranges that protected the team from micromanagement while still giving leadership a roadmap they could plan against.
The Results
- Team morale improved. Estimation went from an annoying guessing game to a more meaningful conversation about the nature of the work.
- Stakeholder trust increased. My forecasts became more reliable because they were based on both subjective team input and objective historical data.
- We adapted together. The team began suggesting tweaks to the categories and size ranges over time, making the process even better.
Final Thought
Scrum isn’t about rigidly following ceremonies—it’s about using its principles to help your team work better together. By changing the way we approached estimation, we not only improved accuracy but also reduced frustration.
And maybe most importantly?
That teammate who hated estimation stopped rolling their eyes every time the topic came up.
If you want, I can also prepare a visual diagram of the “Effort, Risk, Complexity → T-Shirt Size → Data Threshold → Stakeholder Estimate” flow so it’s easier to share in a blog or LinkedIn post. That would really make this piece stand out.