Estimation and Planning

The hardest part of Agile in practice. Interviewers ask “how do you estimate?” because the answer reveals how a candidate thinks about uncertainty.

Why estimate at all

Estimates serve a few purposes:

The last is where estimation gets political. Estimates given for “trigger conversation” purposes become “commitments” in someone else’s spreadsheet. This is the source of much pain.

Estimation techniques

Most teams use story points + velocity (Scrum) or count + cycle time (Kanban).

Story points — what they actually are

Abstract effort estimates, typically on a modified Fibonacci scale: 1, 2, 3, 5, 8, 13, 21, ?

The points encode three dimensions:

• Effort — how much work.
• Complexity — how hard to think through.
• Uncertainty — how much you don’t know.

A “3-point story” means roughly the size of other 3-pointers the team has done. They’re team-relative, not transferable across teams.

Why Fibonacci-ish?

Estimation uncertainty grows with size. Fibonacci’s gaps (1, 2, 3, 5, 8, 13) match the granularity humans can usefully distinguish. You can tell a 1 from a 2; you can’t reliably tell an 8 from a 9.

The “?” at the end is important: items too uncertain to estimate need to be broken down or spiked before estimation.

Planning Poker

Each developer privately picks a card; reveal simultaneously. Discrepancies (someone said 3, someone said 13) trigger discussion. Re-vote.

Purpose isn’t averaging — it’s surfacing different mental models. The 13 reflects something the 3 doesn’t see (or vice versa). Discussion reveals the unknown.

Story points antipatterns

• Points = hours: “8 points = 8 days.” Defeats the abstraction. Velocity becomes a hours forecast.
• Comparing teams by velocity: Team A does 30, B does 20. Means nothing — they’re different scales.
• Velocity as performance metric: gamified. Teams inflate points. Velocity goes up; throughput doesn’t.
• Points carry over between sprints: “this 5-pointer is now a 3-pointer because we did half.” Misses the point of points as upfront estimates.
• Re-estimating completed work: ignore. Velocity uses the original estimate.

Velocity

Average story points completed per sprint, over the last 3–6 sprints. Used for forecasting:

30 points/sprint average × 5 sprints = 150 points
Backlog has 130 points of "must" + 50 points of "should"
→ "We can probably finish must + most should in 5 sprints"

Velocity is a planning tool, not a performance metric. The moment it’s used to evaluate teams or individuals, it stops being useful (people will inflate).

Cycle-time-based forecasting

Skip story points; use cycle time data.

1. Track how long each completed item took (cycle time).
2. Build a distribution (often right-skewed; median ≪ 85th percentile).
3. Forecast: “85% of items finish in ≤ X days.”

Combined with Monte Carlo simulation:

“Given history, there’s an 85% probability we finish these 30 items in 8–11 weeks.”

Probabilistic forecasts are more honest than point estimates. “We’ll deliver by March 15” implies certainty; “85% probability by March 15, 50% by March 1” lets stakeholders make risk-adjusted decisions.

Tools: ActionableAgile, FlowMetrics, Hadar — or homegrown spreadsheets.

#NoEstimates

A movement (Vasco Duarte and others) arguing estimates are wasteful. The pitch:

1. Slice work small (1–5 days max).
2. Count items, not points.
3. Use historical throughput to forecast.

Works when:

• Slicing discipline is high.
• Items are similar in size.
• The team has stable throughput.

Falls apart when:

• Items vary wildly in size.
• Customer demands “how big is this feature” before commitment.
• Estimation IS the conversation that surfaces design.

For interview: know it exists; have an opinion. “Estimation as conversation surfacer” is a defensible middle ground.

Estimation at the project / quarter scale

Smaller estimates roll up into bigger commitments. Patterns:

The longer the horizon, the more honest a range or “now/next/later” categorization is. False precision damages trust.

Spike — when you can’t estimate

A spike is a time-boxed investigation to reduce uncertainty:

Spike: 1 day. Investigate how the legacy auth system handles SSO callbacks.
Output: doc, recommendation, sizing for follow-up work.

Outcome: another story, now estimable. Spikes don’t deliver value directly; they enable future work.

Three-point estimate

For risky / unknown work:

Best case: 2 days
Most likely: 5 days
Worst case: 14 days

PERT formula: (best + 4×likely + worst) / 6 = 5.67 days. Or just present the range.

The range is the point. “5–14 days” tells stakeholders the uncertainty; “5.67 days” pretends precision that isn’t there.

Padding

Engineers pad estimates to account for the gap between “writing the code” and “shipping it” (review, QA, code freezes, deploy windows). Common formula: estimate × 2 (or × 3 for unfamiliar work).

The cynical version: pad to cover yourself if it slips. Better: be explicit about what’s included. “5 days of coding, plus review/test/deploy adds another 3–5” is more honest than “10 days” pretending the buffer is the work.

Buffer the project, not the task

For multi-month projects: hold a project-level buffer rather than padding every task. Use the buffer when needed; report status against the goal.

This is the “Critical Chain” approach (Eli Goldratt) — buffer the path, not the steps.

Reference-class forecasting

“How big is this?” → “What’s a similar past project, and how long did it take?”

Powerful at the strategic level. Don’t estimate from first principles (“design phase: 3 weeks, build: 6 weeks”) — find analogs and use historical actuals.

Daniel Kahneman’s research showed reference-class forecasts beat task-by-task estimation in many domains.

The “Cone of Uncertainty”

Steve McConnell’s observation: at project start, estimates have ~4× error in both directions. As the project progresses, the cone narrows.

Implication: early estimates are wide ranges, not points. Demanding precise commitments at the start guarantees disappointment.

Communicating estimates to stakeholders

Bad:

“It’ll take 4 weeks.”

Better:

“It’ll take 3–6 weeks. The risk is the integration with X.”

Best:

“70% confidence it ships by Feb 28, 95% by Mar 31. Largest risk: integration with X — if that’s complicated we slip 2–4 weeks.”

Stakeholders want certainty; honest engineers provide calibrated uncertainty. The middle is uncomfortable for both sides.

When estimates fail

Common failure modes:

The healthy pattern: estimates roughly match outcomes most of the time, but ~10% of items dramatically over or under. The over/unders should be evenly split — if everything’s over, there’s systematic optimism; if everything’s under, padding.

Interview angle

• “How do you estimate stories?” — typically story points on Fibonacci scale (1, 2, 3, 5, 8, 13). Planning poker for new stories to surface different mental models. Points are team-relative; not transferable.
• “What are story points?” — abstract estimates combining effort, complexity, and uncertainty. NOT hours. Used with velocity for forecasting; not for performance evaluation.
• “What’s velocity?” — average story points completed per sprint over recent sprints. Forecasting tool (“we have 150 points of work; velocity 30 → 5 sprints”). Bad uses: comparing teams, judging individuals, treating as performance metric.
• “What’s #NoEstimates?” — movement arguing estimates are waste; instead slice work small (similar-sized stories) and use historical throughput to forecast. Works with strong slicing discipline; harder when items vary wildly.
• “How do you communicate uncertain estimates to stakeholders?” — ranges or confidence levels: “70% by Feb 28, 95% by Mar 31; largest risk is X.” Honest > falsely precise. Stakeholders learn over time that ranges aren’t waffling; they’re calibration.
• “How do you handle a story you can’t estimate?” — spike it: time-boxed investigation (e.g. 1 day) to reduce uncertainty. Output is a doc + estimate for the follow-up work.
• “What’s the Cone of Uncertainty?” — at project start, estimates have ~4× error in both directions; cone narrows as the project progresses. Implication: early commitments should be ranges, not points.
• “What’s a common antipattern with story points?” — treating them as hours (8 points = 8 days), comparing across teams, using velocity as a performance metric → inflation, gaming.