Estimation & Risk

Estimation gives product planning realistic expectations. Rust work hides risk in migrations, async refactors, FFI boundaries, and compile-time CI - honest ranges, explicit unknowns, and spike budgets beat single-point promises.

Recipe

Quick-reference recipe card - copy-paste ready.

## Estimate card
**Work type:** feature | platform | migration
**T-shirt:** S / M / L / XL
**Range (eng-days):** 3-5 (50% confidence) / 8 (90% if spike fails)
**Unknowns:** sqlx migration phase, legacy crate test coverage
**Spike:** 2 days max before sprint commit
**Dependencies:** security review, DBA window

When to reach for this:

Sprint planning and roadmap dates
Customer commitment requests
Cross-team dependencies
High-risk Rust migrations

Working Example

## Estimate: Async export worker (M)
 
**Known:** Axum endpoint + serde types (2d), S3 upload helper exists (0.5d)
**Unknown:** PDF lib memory at 500 docs (spike 1d)
**Range:** 5-8 eng-days (50-90%)
**Risks:**
- R1: OOM on large batch → mitigation: stream + limit in spec
- R2: DBA migration window slips → mitigation: expand-only phase 1
 
**Commitment:** Sprint after spike; not before.

// Spike outcome example documented in ticket
#[test]
fn spike_pdf_batch_memory_bounded() {
    // prototype: 500 small PDFs stay under 512MB in test harness
    assert!(true);
}

Deep Dive

T-Shirt Calibration (Rust squad)

Size	Typical scope
S	Single Axum route, tests, no migration
M	Feature + worker + observability
L	Cross-crate refactor or migration expand phase
XL	Edition bump, FFI rewrite - split into program

Buffers

Add 20-30% for review churn and CI flakes on L+.
Migration work: add explicit DBA and rollback rehearsal days.
New crate evaluation: spike before including in sprint commitment.

Communication

Present ranges to PM: "5-8 days, 50% confidence; 12 if spike shows OOM issue." Update when learning changes - early, not at demo.

Gotchas

Single number for PM slide - False precision. Fix: Range + confidence + assumptions list.
Estimate without spec - Order-of-magnitude error. Fix: Spec or spike first for M+.
Ignoring test/rollout - "Done" at merge. Fix: Include staging, flag, docs in estimate.
No re-estimate on scope creep - Fix: Change request triggers new card.
Optimism on unsafe FFI - Fix: Security review line item mandatory.

Alternatives

Alternative	Use When	Don't Use When
No estimates, flow metrics	Kanban mature team	Fixed-date contractual launch
Monte Carlo forecasting	Many similar stories	Tiny team, few data points
Reference class forecasting	Repeated migration type	Novel greenfield
#NoEstimates + SLO	Strong trust	External deadline pressure

FAQs

Story points vs days?

Either works; Rust teams often prefer eng-days for PM clarity on migrations.

Who owns risk register?

Tech lead maintains; PM reviews in planning.

Spike time box?

1-3 days; binary exit criteria in ticket.

Estimate CLI + API together?

Separate cards unless shared crate dominates effort.

Polars ETL estimates?

Include data volume probe and memory spike; often underestimated.

Pad for compile CI?

Yes on L+ workspace changes; cite recent lead time data.

Customer hard date?

Reduce scope or add staff; do not compress testing/migration phases silently.

Velocity for new Rust team?

Lower initial velocity 2-3 sprints; calibrate with retro data.

Document estimate assumptions?

In ticket comment; link spec and spike PRs.

Missed estimate retro?

Blameless: wrong unknown, scope change, or interrupt load - adjust process.

Requirements to Technical Specs - scope input
Stakeholder Communication - bad news early
Spikes, PoCs & Adopting New Crates - de-risk
Making the Process Work - sprint norms
Product Collaboration Best Practices - summary

Stack versions: This page was written for Rust 1.97.0 (edition 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, and Polars 0.46+.

Recipe

Quick-reference recipe card - copy-paste ready.

## Estimate card
**Work type:** feature | platform | migration
**T-shirt:** S / M / L / XL
**Range (eng-days):** 3-5 (50% confidence) / 8 (90% if spike fails)
**Unknowns:** sqlx migration phase, legacy crate test coverage
**Spike:** 2 days max before sprint commit
**Dependencies:** security review, DBA window

When to reach for this:

Sprint planning and roadmap dates
Customer commitment requests
Cross-team dependencies
High-risk Rust migrations

Working Example

## Estimate: Async export worker (M)
 
**Known:** Axum endpoint + serde types (2d), S3 upload helper exists (0.5d)
**Unknown:** PDF lib memory at 500 docs (spike 1d)
**Range:** 5-8 eng-days (50-90%)
**Risks:**
- R1: OOM on large batch → mitigation: stream + limit in spec
- R2: DBA migration window slips → mitigation: expand-only phase 1
 
**Commitment:** Sprint after spike; not before.

// Spike outcome example documented in ticket
#[test]
fn spike_pdf_batch_memory_bounded() {
    // prototype: 500 small PDFs stay under 512MB in test harness
    assert!(true);
}

Deep Dive

T-Shirt Calibration (Rust squad)

Size	Typical scope
S	Single Axum route, tests, no migration
M	Feature + worker + observability
L	Cross-crate refactor or migration expand phase
XL	Edition bump, FFI rewrite - split into program

Buffers

Add 20-30% for review churn and CI flakes on L+.
Migration work: add explicit DBA and rollback rehearsal days.
New crate evaluation: spike before including in sprint commitment.

Communication

Present ranges to PM: "5-8 days, 50% confidence; 12 if spike shows OOM issue." Update when learning changes - early, not at demo.

Gotchas

Single number for PM slide - False precision. Fix: Range + confidence + assumptions list.
Estimate without spec - Order-of-magnitude error. Fix: Spec or spike first for M+.
Ignoring test/rollout - "Done" at merge. Fix: Include staging, flag, docs in estimate.
No re-estimate on scope creep - Fix: Change request triggers new card.
Optimism on unsafe FFI - Fix: Security review line item mandatory.

Alternatives

Alternative	Use When	Don't Use When
No estimates, flow metrics	Kanban mature team	Fixed-date contractual launch
Monte Carlo forecasting	Many similar stories	Tiny team, few data points
Reference class forecasting	Repeated migration type	Novel greenfield
#NoEstimates + SLO	Strong trust	External deadline pressure

FAQs

Story points vs days?

Either works; Rust teams often prefer eng-days for PM clarity on migrations.

Who owns risk register?

Tech lead maintains; PM reviews in planning.

Spike time box?

1-3 days; binary exit criteria in ticket.

Estimate CLI + API together?

Separate cards unless shared crate dominates effort.

Polars ETL estimates?

Include data volume probe and memory spike; often underestimated.

Pad for compile CI?

Yes on L+ workspace changes; cite recent lead time data.

Customer hard date?

Reduce scope or add staff; do not compress testing/migration phases silently.

Velocity for new Rust team?

Lower initial velocity 2-3 sprints; calibrate with retro data.

Document estimate assumptions?

In ticket comment; link spec and spike PRs.

Missed estimate retro?

Blameless: wrong unknown, scope change, or interrupt load - adjust process.

Requirements to Technical Specs - scope input
Stakeholder Communication - bad news early
Spikes, PoCs & Adopting New Crates - de-risk
Making the Process Work - sprint norms
Product Collaboration Best Practices - summary

Stack versions: This page was written for Rust 1.97.0 (edition 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, and Polars 0.46+.

Estimation & Risk

Search Documentation

Estimation & Risk