Improving Results Through Agile Estimation

Agile estimation is important, but not for the reasons most people think. It’s not about predicting the future accurately, that’s impossible. It’s about having structured conversations that surface risks, align understanding, and enable better planning.

Teams that understand this build estimation practices that actually serve them. Teams that chase accuracy spend endless cycles on estimates that will be wrong anyway.

The Evolution of Agile Estimation

Estimation in software development has evolved significantly. We’ve moved from detailed upfront estimation (days for each task) to relative sizing (like story points), to some teams abandoning estimation entirely in favour of throughput forecasting.

Current best practice recognises that estimation serves multiple purposes:

Communication: Forcing conversations about scope, complexity, and risk
Planning: Enabling roughly right capacity planning
Calibration: Building team intuition about work through prediction and reflection

Each purpose suggests different approaches. If you’re estimating primarily for communication, the discussion matters more than the number. If you’re estimating for planning, aggregate accuracy matters more than item-level precision.

Implementation Approach

Best Practices

Estimate for the purpose: Be explicit about why you’re estimating. “We need this estimate to inform the quarterly planning conversation” suggests different precision than “We need this estimate to understand what’s complex.”

Relative over absolute: Humans are terrible at absolute time estimation but reasonable at relative comparison. “This is bigger than that” is more reliable than “This will take four days.”

Team-based estimation: Estimates should come from the people doing the work, working together. Individual estimates miss perspectives; team estimation surfaces disagreements that reveal complexity.

Use reference points: Anchor estimates to work you’ve done before. “This is similar to the authentication project” is more meaningful than abstract sizing.

Decompose large items: Large items are inherently harder to estimate. Break them down until pieces are small enough to understand. If you can’t decompose, that’s a signal the work isn’t well enough understood.

Re-estimate when you learn: Estimates made before work begins are less accurate than estimates after some exploration. If early work reveals surprises, update estimates rather than defending the original ones.

Track and improve: Compare estimates to actuals, not to punish people, but to calibrate. Over time, this feedback loop improves estimation accuracy for the whole team.

Tooling and Process

Planning poker remains effective for team estimation. The process of revealing estimates simultaneously and discussing disagreements surfaces risk and builds shared understanding.

T-shirt sizing (S, M, L, XL) works well for early-stage estimation when precision isn’t the point. It’s fast, accessible, and focuses conversation on order of magnitude rather than false precision.

Reference class forecasting uses historical data from similar work to inform estimates. If authentication projects typically take 3-5 weeks, a new authentication project probably will too.

Monte Carlo simulation uses historical throughput data to forecast completion ranges. This acknowledges uncertainty explicitly rather than hiding it behind point estimates.

For tooling, most project management tools support estimation workflows. The specific tool matters less than consistent process. Pick something your team will actually use.

“The best estimation sessions I’ve attended weren’t about getting the right number. They were about surfacing the right questions: What don’t we understand? What could go wrong? What are we assuming?”

The Development Context

Technical Considerations

Technical complexity makes estimation hard in software. Unlike physical construction where similar projects behave similarly, software projects encounter unique combinations of existing code, integrations, and edge cases.

Account for this by:

Distinguishing known and unknown complexity: Some work is complex but predictable. Other work involves uncertainty that can’t be estimated away. Make this distinction explicit.

Building in discovery time: For work with significant unknowns, include time to learn before committing to detailed estimates. A spike or prototype can reduce uncertainty dramatically.

Acknowledging dependencies: Work that depends on other teams, systems, or decisions carries additional uncertainty. Surface dependencies explicitly in estimation discussions.

Factoring in technical debt: Estimates in clean codebases differ from estimates in legacy systems. Be realistic about the environment you’re working in.

Team Dynamics

Estimation is a team activity, and team dynamics affect quality:

Create safety for honest estimation: If people feel punished for “high” estimates, they’ll estimate low and miss. Create an environment where realistic estimation is rewarded.

Address expertise imbalance: More experienced team members often estimate lower because they know how to solve problems. Less experienced members estimate higher because they’re accounting for learning time. Both perspectives are valid - neither should dominate.

Manage anchoring: Once someone states an estimate, others anchor to it. Planning poker’s simultaneous reveal exists to prevent this. Respect the process.

Use disagreement productively: When estimates diverge significantly, that’s a signal worth exploring. What is one person seeing that the other isn’t?

Scaling What Works

Growth Considerations

Estimation practices that work for small teams often break as teams grow:

Cross-team estimation: When work spans multiple teams, estimation becomes coordination. You need mechanisms for teams to estimate their portions without waiting for full context.

Portfolio-level estimation: Leadership needs estimates at a different granularity than teams do. Create translation layers that provide portfolio views without requiring teams to estimate everything twice.

Estimation culture scaling: New team members need to learn your estimation norms. Document your practices and calibrate new joiners explicitly.

Maintaining Quality

Estimation quality degrades without attention:

Regular calibration: Compare estimates to actuals periodically. Share learnings team-wide. This feedback loop is how teams improve.

Process consistency: When estimation happens inconsistently, accuracy suffers. Build estimation into your regular rhythms rather than doing it ad-hoc.

Estimate refresh: Old estimates for work that hasn’t started yet may be outdated. Refresh estimates before committing to work, not just when items were created.

Resist pressure inflation: Under deadline pressure, there’s temptation to estimate aggressively. This creates the illusion of faster delivery while guaranteeing misses later.

Key Takeaways

Estimation serves communication and planning, not prediction—structure your practice accordingly
Relative sizing is more reliable than absolute time estimation
Team-based estimation surfaces complexity and builds shared understanding
Create psychological safety for honest estimation - punishing “high” estimates guarantees underestimates
Track estimates versus actuals to calibrate and improve over time

Next Steps This Week

For your next estimation session, try this: After reaching estimates, ask the team “What could make this take twice as long?” Document the answers.

You’ve just surfaced risks that the estimates don’t account for. Some will be worth addressing upfront; others are acceptable. But now they’re visible rather than hidden in optimistic estimates.

That visibility is the real value of good estimation practice.

Have questions or thoughts? Get in touch - I’d love to hear from you!