Better Software Estimation

By Michael Samuel Naeem · December 31, 2025 · 5 min read

"We estimated thirteen points so it fits the sprint" is not estimation — it is sprint Tetris. Story points were meant to capture relative effort and uncertainty, but teams routinely convert them to management commitments, velocity targets, and performance metrics that distort the numbers until they mean nothing. Better estimation accepts that novel software work has irreducible uncertainty, sizes work against concrete references, and forecasts dates from how fast work actually flowed historically — not from summed guesses on a Monday planning call.

Why points break down

Story points fail when:

• Used as productivity comparison across teams (different scales)
• Summed to imply calendar accuracy ("34 points = 34/velocity weeks")
• Inflated to win arguments or deflated to look heroic
• Assigned by managers without implementer input

Points can still help a single team discuss relative size — but only without velocity-as-KPI culture.

Reference stories anchor reality

Maintain a living catalog:

New ticket discussion: "This feels like R2 plus unknown vendor API docs — call it R2.5, spike first if auth model unclear."

Spikes are first-class — time-boxed investigation with explicit decision output, not pretend precision.

Three-point estimates for uncertainty

When leadership needs ranges, use optimistic / likely / pessimistic with explicit assumptions:

## OAuth provider swap
- Best: 4 days — drop-in SDK, same scopes
- Likely: 8 days — refresh token migration edge cases
- Worst: 15 days — undocumented enterprise IdP behavior

Assumptions documented; worst case triggers if SAML fallback required.

Wide spread signals unknowns — schedule spike before committing roadmap date.

Flow metrics beat point sums

Track from your issue tracker:

• Cycle time — started → done (per work type)
• Throughput — items completed per week
• Work in progress — Little's Law: more WIP → longer cycle time

# simplified Monte Carlo forecast
import numpy as np

remaining_items = 28
historical_throughput = [3, 5, 4, 6, 4, 5, 3, 4]  # items/week, last 8 weeks
simulations = 10_000
weeks_to_finish = []

for _ in range(simulations):
    weeks = 0
    done = 0
    while done < remaining_items:
        weeks += 1
        done += np.random.choice(historical_throughput)
    weeks_to_finish.append(weeks)

p50 = np.percentile(weeks_to_finish, 50)
p85 = np.percentile(weeks_to_finish, 85)
print(f"50% chance within {p50:.0f} weeks; 85% within {p85:.0f} weeks")

Report "85% confidence by week 9" instead of "due March 3."

Tools: ActionableAgile, Jira plugins, or spreadsheet — methodology matters more than tooling.

Planning poker done minimally

If you keep points:

1. Discuss scope until shared understanding
2. Compare to reference story, not abstract "8 means hard"
3. Do not rewrite points to fit capacity — split or defer work
4. Never tie points to individual performance reviews

Alternative #noestimates for mature teams: break work small, prioritize queue, forecast from throughput only.

Estimation in roadmap conversations

Translate technical uncertainty for PMs:

• Known work — bounded tasks with reference analogs
• Known unknowns — spike required (name duration)
• Unknown unknowns — buffer at initiative level, not per ticket lie

Commit to learning milestones: "After two-week spike, we re-forecast with 85% interval."

Monte Carlo forecasting

Use historical throughput data to forecast completion dates probabilistically:

import numpy as np

# Last 20 completed story throughputs (stories per sprint)
throughputs = [12, 15, 11, 14, 13, 16, 12, 14, 15, 13,
               11, 14, 12, 15, 13, 14, 12, 16, 11, 14]

remaining_stories = 45
simulations = 10000

results = []
for _ in range(simulations):
    sprints = 0
    remaining = remaining_stories
    while remaining > 0:
        remaining -= np.random.choice(throughputs)
        sprints += 1
    results.append(sprints)

print(f"50th percentile: {np.percentile(results, 50):.0f} sprints")
print(f"85th percentile: {np.percentile(results, 85):.0f} sprints")
print(f"95th percentile: {np.percentile(results, 95):.0f} sprints")

Report "45 stories remaining: 3 sprints (50%), 4 sprints (85% confidence)" — not "3 sprints exactly."

Cycle time vs velocity

Velocity (story points per sprint) is a capacity planning tool. Cycle time (days from start to done) is a forecasting tool:

Measure cycle time per work item type (bug, feature, spike) — they have different distributions. Aggregating all types produces meaningless forecasts.

Anti-patterns in estimation meetings

• Planning poker anchoring — senior engineer speaks first; others adjust to match
• Points as deadline — "8 points = 8 days" destroys the abstraction
• Velocity as performance metric — teams inflate points to look productive
• Estimating research spikes — unknown work gets a number instead of a time-box
• Re-estimating completed work — retroactively changing points to match actuals

If estimation meetings take more than 30 minutes per sprint, work items are too large — split before estimating.

Failure modes

• Single-point estimates communicated as certainty — "3 sprints" without confidence interval
• Velocity compared across teams — different scales, different work types
• No throughput history — Monte Carlo impossible; fall back to gut feel
• Spike without time-box — research expands indefinitely
• Points tied to performance reviews — gaming and sandbagging

Production checklist

• Forecasts reported with confidence interval (50th, 85th percentile)
• Cycle time tracked per work item type
• Spikes time-boxed with explicit learning milestone
• Velocity used for capacity planning only, not performance
• Work items small enough to estimate in <5 minutes
• Monte Carlo simulation updated each sprint with new throughput data

Resources

• Forecasting Using Data (Vacanti)
• User Story Mapping (Jeff Patton)
• Monte Carlo simulation for forecasts (Focus on Delivering)
• Software Estimation Without Guessing (George Stepanek)
• Cycle time vs velocity (Dan Vacanti)