Time-Based Estimates

---

Origins

Time-based estimation predates Agile by decades. Construction, manufacturing, and engineering projects have always estimated tasks in hours, days, or weeks. Software inherited the practice; the Agile movement complicated it by pointing out the ways time-based estimates of unknown work tend to fail.

The complaint isn't that estimating in time is always wrong. It's that estimating in time pretends precision the team usually doesn't have for software work, especially work that involves discovery, integration, or anything new to the team. The relative-estimation alternatives (story points, T-shirts) emerged to acknowledge that pretend-precision.

What Time-Based Estimates Do Well

Time-based estimates work well in specific conditions:

• Well-understood, repetitive work: tasks the team has done many times. "Set up a new test environment: 4 hours" can be calibrated from history.
• Hard external deadlines: when the stakeholder needs to know "can we get this done by Friday?" Time estimates answer the question directly.
• Resource planning: when allocating people to projects, time estimates feed capacity calculations.
• Short tasks with clear scope: small, well-defined work where the estimate's uncertainty is bounded.

Where Time-Based Estimates Break Down

The practice fails in conditions that describe most product software work:

• Discovery-heavy work: estimates assume the team knows what to build; discovery work explicitly doesn't.
• Integration with unknowns: a "two-day" integration with an unfamiliar system routinely consumes weeks once the team discovers what the system actually does.
• Multi-person tasks: "16 hours" of work doesn't take 16 person-hours when split across two developers — it takes longer because of coordination overhead.
• Calendar vs. clock time: 8 hours of focused work consumes a full calendar day for most people; estimates that don't reflect this are systematically optimistic.
• Unknown unknowns: time estimates depend on knowing what tasks exist. Tasks the team didn't know existed add to the duration without changing the estimate.

Why Time Estimates Get Padded

Teams that produce time-based estimates eventually learn to pad them. The padding compensates for the systematic optimism above, but it creates new problems:

• The padding is invisible — stakeholders read the padded number as the team's actual estimate.
• The padding gets eaten by work that expands to fill it (Parkinson's Law).
• The padding grows over time as teams learn how often estimates were too optimistic.
• The padding makes future estimates harder to calibrate — was this task actually 16 hours, or 8 hours plus padding?

The pattern is well-known enough that mature estimation practices acknowledge it openly: estimate optimistically, communicate ranges, expect to be wrong.

Cone of Uncertainty

Steve McConnell's Cone of Uncertainty¹ captures the reality: early estimates have wide ranges (0.25x to 4x the actual time), and the range narrows as the team learns. A "two-week" estimate at project start might actually be six weeks; a "two-week" estimate after three weeks of work is usually closer to the truth.

Time-based estimates work better when communicated with the cone explicitly. "Best case 8 hours, expected 16 hours, worst case 40 hours" is honest. "16 hours" pretends a confidence the team rarely has.

The Alternative: Relative Estimation

Planning Poker, T-shirt sizing, and Roman Estimation avoid time units entirely. They estimate relative size — this story is twice as big as that one — and let velocity or throughput convert size into time.

Why this works better:

• The team is usually better at "this is bigger than that" than at "this will take 8 hours."
• The conversion from size to time uses real data (velocity), not estimation.
• Relative estimates are less sensitive to who's doing the work.
• The format doesn't pretend to absolute precision.

The Further Alternative: NoEstimates

The NoEstimates movement argues for skipping per-item estimation entirely and forecasting from throughput. The team commits to keeping items small, measures how many they complete per period, and forecasts based on completion rate. No story points, no hours.

Works when items are reliably small. Breaks down when item size varies significantly.

When Time-Based Estimates Are Still the Right Tool

• Specific tasks within a known story: "this story will take about three days; the breakdown is integration (1 day), implementation (1 day), testing (1 day)." Useful for planning within a sprint.
• Short-horizon commitments: "this can be done by Friday" for a small piece of work the team has done variants of before.
• Operational work: incident response, maintenance, support — categories where time estimates have historical baselines.
• Resource allocation conversations: cross-team capacity planning needs time units; relative estimates don't aggregate across teams.

Common Pitfalls

• Single-point estimates without ranges: pretending precision the team doesn't have. Honest estimation includes the range.
• Padded estimates communicated as raw: the team pads to protect themselves, stakeholders read the padded number, work expands to fill it.
• Time estimates for discovery work: applying time-based estimation to work whose scope the team doesn't yet know. Systematically wrong.
• Time estimates without historical calibration: estimates pulled from intuition without checking against past data. The team's optimism stays uncalibrated.
• Confusing person-hours with calendar time: 16 person-hours rarely means 2 calendar days. Account for meetings, context switching, and coordination.

Coaching Tips

Always Communicate Ranges

Best case, expected, worst case. Single-point estimates lie about confidence the team doesn't have.

Calibrate Against History

Track estimated vs. actual time on past work. Most teams systematically underestimate; knowing the multiplier helps.

Separate Person-Hours from Calendar Time

16 person-hours rarely means 2 days. Meetings, context-switching, and review consume real time the estimate often ignores.

Match Estimation to Work Type

Time estimates for routine tasks; relative for stories; flow forecasting for releases. Don't use one technique for all of it.

Surface Padding Honestly

Teams pad. Pretending they don't makes the padding invisible. Surface it as "padding for uncertainty" and stakeholders react more honestly.

Refuse to Estimate Unknowns

When the team is asked to estimate work whose scope they don't yet know, the right answer is "we need to do discovery first." Estimating fiction breeds eroded trust.

Summary

Time-based estimates are not always wrong, but they're frequently misapplied. The mistake is treating estimates as predictions when they're closer to bets. Stakeholders demand precision the team can't honestly provide; the team produces single-point estimates anyway; reality fails to honor those estimates; trust erodes.

The honest practice is acknowledging what estimates actually are: probabilistic guesses about uncertain work. Communicate ranges. Calibrate against history. Use relative estimation where it works better. Use NoEstimates where small uniform items make per-item estimation unnecessary. Use time-based estimates where the conditions genuinely support them. The goal isn't to win the estimation debate — it's to give stakeholders honest forecasts they can plan around.

Back to Agile Delivery