Estimating a Migration With Conflicting Velocity Data
You must estimate a database migration: 14 tables, 3 of them over 200 million rows, plus a cutover window. Your team's historical velocity is 34 story points per two-week sprint, but that average includes four sprints where a senior engineer was on parental leave. Excluding those, velocity was 41. The migration is estimated at 55 points for schema work, 34 for backfill tooling, 21 for dual-write and reconciliation, and 13 for cutover rehearsal. A dependent team must finish an API change before your cutover, and their last three deliverables slipped by 2, 5, and 3 weeks. Leadership wants a single date.
1. Produce a defensible duration estimate and explain which velocity figure you used and why.
Read the worked answer
Scope: 55 + 34 + 21 + 13 = 123 points.
Velocity choice. Use 34, not 41. The 41 figure excludes the four sprints where a senior engineer was absent - but that absence is not a one-off anomaly, it is a foreseeable staffing condition. Estimating from the best-case subset produces a plan that only works if nothing goes wrong, which is not a plan. 34 is the observed throughput under normal conditions, including normal attrition. If the senior engineer is confirmed present for the whole migration, you can revisit, but the default should be the inclusive number.
Base duration: 123 / 34 = 3.6 sprints, so 4 sprints (8 weeks) of team effort, rounded up because partial sprints don't ship.
Dependency risk. The dependent team's slips were 2, 5, and 3 weeks - mean 3.3, worst 5. Their API change gates your cutover rehearsal, so the 8-week team estimate is not the project estimate. Add the dependency buffer to the cutover, not to the schema work: schema and backfill can proceed in parallel with the API change, but rehearsal cannot start until it lands.
Realistic range: 8 weeks of team work, plus 3-5 weeks of dependency wait overlapping the backfill phase, giving a 10-13 week window with the rehearsal and cutover at the end.
2. Leadership demands a single date. How do you respond, and what do you commit to?
Read the worked answer
Give a date and the conditions attached to it. A single number with no stated assumptions is not more honest than a range - it is a range with the uncertainty hidden.
Commit to: a target date at the 13-week end of the range, presented as the plan of record, with the 10-week figure labeled 'earliest credible' and explicitly conditional.
State the assumptions in writing:
- Velocity holds at 34 points/sprint (the inclusive figure).
- The dependent team's API change lands within 5 weeks of their committed date.
- The senior engineer is available for the full migration.
- Cutover rehearsal gets a full sprint; no compression there.
Define the trigger for re-planning. The most useful thing you can give leadership is not a date but a tripwire: if the API change has not landed by week 5, the target date moves by the size of the slip. That converts an argument about estimates into a scheduled check.
Explain the cost of the alternative. If leadership wants the 10-week date committed unconditionally, the only way to hit it is to compress the cutover rehearsal from 13 points to near zero - and cutover rehearsal is the step that catches the failures you cannot recover from in production. Name that trade-off explicitly so the decision is theirs, made with the risk visible, rather than yours, made by quietly dropping the rehearsal.
Refuse one thing: do not present the 41-point velocity as the basis. It will produce a date you cannot hold, and the first slip will cost more credibility than the honest range would have.