"How to estimate software engineering work accurately"

"Most engineering estimates fail because they only account for coding time and ignore the other 40-60% of the work: code review, testing, deployment, documentation, meetings, and unplanned interruptions. Use a multiplier approach: estimate the core coding work, then multiply by 2-3x for a realistic delivery timeline. Break work into chunks no larger than 3 days — anything bigger needs decomposition before estimation. Track your actual-vs-estimated ratio over time and calibrate. The most accurate teams I've worked with estimate in ranges (2-4 days) rather than points, and they plan sprints at 70% capacity."

How to Estimate Engineering Work Without Getting It Wrong Every Time

I’ve never met an engineering team that consistently estimates well. I’ve met plenty that consistently estimate badly in the same direction — always optimistic, always surprised when things take longer than planned, always making the same correction in retrospectives that they forget by next planning session.

Here’s the thing: they’re not bad at estimating the coding work. They’re bad at estimating everything else.

Why Estimates Are Always Wrong

When an engineer says “that’s a three-day task,” they’re almost always estimating the time it takes to write the code. They’re not including:

Code review cycles (write the PR, wait for review, address comments, wait for re-review)
Testing beyond the happy path (edge cases, error handling, integration testing)
Environment and deployment work (configuration, migrations, feature flags)
The meeting tax (standups, sprint ceremonies, cross-team syncs)
Context switching (Slack messages, production issues, helping a teammate debug something)
The discovery work they’ll do once they start and realize the problem is slightly different than expected

That “three-day task” is three days of uninterrupted coding in a world where engineers get maybe four to five hours of focused coding time per day. In reality, it’s a five-to-eight-day task. And that’s not a failure of the engineer — it’s a failure of the estimation process.

The Multiplier Approach

The simplest fix I’ve found: estimate the coding work, then apply a multiplier.

2x multiplier for work in a well-understood part of the codebase with clear requirements, existing patterns to follow, and good test coverage. This is “I’ve built something very similar before.”

3x multiplier for work that involves unfamiliar code, new integrations, ambiguous requirements, or technology the team hasn’t used before. This is “I know roughly how to do this but I’ll hit some unknowns.”

4x multiplier for work that requires research, architectural decisions, coordination with other teams, or technology exploration. This is “I think this is possible but I’m not sure how.”

A senior engineer who tells you the coding work is two days will deliver in four days with a 2x multiplier. That’s not sandbagging — that’s accounting for reality.

Break It Down Until It’s Small

The single most effective estimation technique is decomposition. No task should be estimated at larger than three days of work. If someone says “that’s a two-week task,” it means they haven’t broken it down enough to understand it, and their estimate is really just a guess wearing a number’s clothing.

Force decomposition: “What are the individual steps? What needs to happen first? What could you ship independently?” A two-week task that breaks down into eight subtasks suddenly has eight smaller estimates, and the aggregate is almost always more accurate than the single big guess.

This also reveals hidden work. “Build the API endpoint” decomposes into: write the endpoint, add authentication, add validation, add error handling, write unit tests, write integration tests, update the API docs, add monitoring. That’s eight pieces of work, not one.

Stop Using Story Points (Or At Least Understand What They Are)

Story points were designed to be a relative sizing tool, not a time estimate. A 5-point story should be roughly five times the effort of a 1-point story. In practice, every team I’ve encountered treats them as disguised time estimates — a 5-point story means “about a week.”

If you’re going to estimate in time, estimate in time. Don’t add a layer of indirection that makes everyone less confident in the numbers. I’ve moved multiple client teams from story points to simple day-range estimates (2-4 days, 1-2 days, etc.) and the accuracy improved because everyone stopped debating what a “point” means.

Plan at 70% Capacity

Even with perfect task-level estimates, your sprint plan will fail if you plan at 100% capacity. No team has 100% of their time available for planned work. There’s always unplanned work — production issues, support escalations, urgent bug fixes, that compliance audit question that takes half a day.

Plan your sprint at 70% of available capacity. If you have five engineers working two-week sprints, that’s 50 engineer-days of total capacity. Plan 35 days of work. The remaining 15 days absorb the unplanned work, sick days, and the estimation error that’s inevitable even with good practices.

Teams that do this consistently hit their sprint commitments. Teams that plan at 100% consistently miss. The math isn’t complicated.

Track and Calibrate

The only way to get better at estimation is to measure your accuracy and adjust. After each sprint, compare estimated vs. actual for every task. Calculate your ratio. If your team consistently estimates at 60% of actual, you know your multiplier needs to increase.

Over time, patterns emerge. “Anything involving the payment system takes 2x longer than estimated.” “Front-end work is usually accurate but back-end integration work is always off by 50%.” These patterns become team knowledge that makes future estimates better.

The teams that estimate best aren’t the ones with the most sophisticated estimation process. They’re the ones that track their accuracy and learn from it.

The Honest Conversation

The most powerful estimation tool is honesty. When a stakeholder asks “when will this be done?” and you don’t know, say “I don’t know yet — I need two days to break it down and I’ll give you a range.” A range delivered with confidence is more useful than a precise number delivered with hope.

Under-promise, over-deliver. Always.