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 windowWhen 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
unsafeFFI - 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.
Related
- 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+.