---
title: "Estimation Model"
slug: estimation-model
section: Delivery
status: active
description: "How we size and schedule a body of work now that AI agents write most of the code."
last-updated: 2026-10-07
---

# Estimation Model

How we size and schedule a body of work now that AI agents write most of the code. This is the planning language for Delivery — the same model that backs the `gateway_estimate_feature` operation agents call. Constants dated **2026-08-19**, calibrated from BackOfficePrototype plus eight Alliance-Strategies repos (8,706 commits, 1,276 merged units).

## Why estimation is different with AI

When agents produce the code, the thing that used to dominate an estimate — how long it takes to *type* the change — nearly disappears, and it parallelizes. What is left is the work only a person can do: deciding what to build, reviewing what came back, and accepting it. Estimating in "developer-days" hides that shift and produces dates that are either wildly optimistic (ignoring review) or padded past usefulness. The model below separates the parts that are cheap from the one part that is scarce, and only sizes against the scarce one.

## The three clocks

"How long will it take" is really three separate clocks. Only the middle one is the constraint — never collapse them into a single number.

| Clock | What it is | Planning value | The constraint? |
| --- | --- | --- | --- |
| C1 — agent wall-clock | first to last commit of a unit | 0.3–2 h, runs in parallel | No — nearly free |
| C2 — attended orchestration | spec + review + accept per merged unit | about 1 h per unit | Yes |
| C3 — calendar-to-hardened | merge to fix-tail quiet + promotion soak | +1 wk if ≥ M, +2 wk if XL | For release dates |

Plan capacity and sprints in **C2 attended hours** — that is the real cost and the thing you run out of. Quote release dates off **C3 calendar-to-hardened**, never off C1. Agent wall-clock (C1) is not a planning input; it is nearly free and it overlaps.

## Calibrated constants

These are the single source of truth. The `gateway_estimate_feature` operation and the `estimation-model` agent skill carry the same numbers; all three move together on each refit.

- Class to M-equivalents: **XS 0.1 · S 0.3 · M 1 · L 3 · XL 10**
- Rework multiplier: **×1.3** when patterns exist · **×1.6** with no pattern or a new external contract
- **1.1 M-eq per attended hour** (conservative; measured 1.55)
- **10 M-eq per orchestrator-week** sustained
- Stabilization soak added to the calendar: **+1 week** if the largest task is ≥ M, **+2 weeks** if XL
- Promotion soak (dev to qa to prod): **5–10 calendar days**

An "orchestrator" is a person doing spec + review + accept. One gives roughly 20 attended hours a week to this work.

## How an estimate is built

1. **Decompose** the feature into PR-sized tasks. A step that will not classify as XS through M has not been decomposed yet.
2. **Classify by shape, not lines of code** — layers touched, migration yes/no, external contract yes/no, novel versus pattern-following.
3. **Weight to M-eq** and apply the adjusters: a named pattern on an L or XL de-escalates it (×0.6); a new external contract escalates it (×1.6); undefined scope raises a **spike** that must be resolved first.
4. **Multiply by rework, then divide by 1.1** to get attended hours — the cost. Calendar time is the greater of the velocity-bound and the attended-hours-bound weeks; add the stabilization soak and the promotion window for calendar-to-hardened.
5. **Guardrails:** never quote a date for a single unit — unit-level variance is about 90× — estimate in batches. Spikes close before the tasks they gate are committed.

## Reading an estimate

An estimate keeps the three clocks separate and adds the numbers a planner actually uses:

- **attended_hours** — the real cost; use it for capacity and sprint planning.
- **committed_days** / **committed_weeks** — the release date to quote (high band plus a small buffer).
- **confidence.usable_for_commitment** — false for a single unit; the model refuses to certify a lone task for a date. Estimate batches.
- **risk** and **prioritization.spikes_first** — sequence the spikes before the work they gate; rank a backlog by business value ÷ attended_hours.
- **model_version** — stamped on every estimate so a stale-constants answer is detectable and the estimate-vs-actual ledger stays clean.

## Getting an estimate

Agents get an estimate by calling the `gateway_estimate_feature` operation on the Alliance MCP Gateway with a decomposed, shape-classified feature; it returns the planning object above. The method itself is published as the `estimation-model` gateway skill, which an agent loads before quoting any date, effort, or capacity number. For a person planning a body of work, the same model is what turns a rough scope into the attended-hours and calendar figures used on the Delivery board.

## Honesty & recalibration

The constants are a **local** fit to Alliance repos, not a universal law — the *structure* of the model transfers, the *numbers* need refitting elsewhere. A monthly job re-fits the constants from the estimate-vs-actual ledger (the operation's own call log) and bumps the date at the top of this page. A brand-new (greenfield) repo starts at early-era economics — roughly half the velocity and the ×1.6 rework tax — until it accumulates enough history to earn its own calibration.