Methodology
Where the numbers come from
Every figure on this site — the 4.6× miss, the 11–18 stories per sprint, the quality gates — traces back to one methodology, refined across real shipped deliveries rather than derived from theory. This page documents the method itself: how estimates are calibrated, how scope changes are controlled, and how quality is graded. It's the same method the five free Factory skills encode, so you can verify a claim instead of taking it on faith.
Where it started
A 4.6× miss on one epic
On a real multi-tenant SaaS delivery, the billing epic — subscription management, invoicing, plan changes — was scoped at 14 hours. It took 64. Every other epic in that same backlog landed within a normal estimation error band; billing alone missed by 4.6×.
The instinct is to treat that as a one-off — a story someone sized badly. Looking across the delivery record instead, the pattern wasn't random: every epic that missed badly touched the same kind of work. Authentication. Payments. Webhooks. Background jobs. Feature screens — CRUD, dashboards, forms — estimated close to actual almost every time. Infrastructure didn't.
That's the origin of the correction factor: not a rule of thumb applied uniformly, but a multiplier scoped narrowly to the categories that earned it.
The correction factor, by category
- Authentication flows (new providers, SSO)×4
- Payment processing (Stripe, escrow, refunds)×4
- SaaS billing & subscription management×4
- Webhook infrastructure (new in/outbound systems)×4
- Background job systems (cron, queues)×3
Applied at the backlog stage, before a story is quoted — not as a post-hoc excuse once a sprint runs over.
wireframe-to-backlog
A five-pass read, not one
Turning a wireframe into an estimated backlog in a single pass is how omission happens — a screen gets a story, but the infrastructure underneath it doesn't. The method is deliberately five separate passes, each with one job.
-
Screen inventory
Every screen, modal, panel, and state gets logged before a single story is written. This number predicts backlog size — skipping it is the single biggest cause of an incomplete backlog.
-
Epic grouping
Screens are grouped into coherent, independently deliverable functional areas, each scoped, phased, and dependency-mapped against the others.
-
Story breakdown
Each epic decomposes into PR-sized stories against a fixed sizing table (S/M/L/XL), with the infrastructure correction factor applied to the categories that earn it.
-
Sprint assignment
Stories are sequenced against dependency order and sprint capacity, with a 15% buffer left for carry-overs — and an explicit Phase 1/Phase 2 line.
-
Backlog production
The backlog is produced as a structured, versioned document with a blank "Done" column and a blank "CR#" column — turning it from a plan into a delivery ledger from day one.
The discovery-gaps report
The fifth pass also produces a second artifact: a list of stories that are always required but never appear in a wireframe — CI/CD, error monitoring, seed data, role-based access control, i18n infrastructure — plus any wireframe screen with no story attached, flagged for the client to confirm as intentional or an oversight. This is the part that directly answers "what did the estimate forget," which matters more than getting a listed story's hours exactly right.
change-request-impact
Why scope changes have a formal test
On the same delivery, two epics were added to the backlog post-contract with no formal change request — because nothing forced the question. Both were reasonable client asks. Both silently mixed new-scope hours into the velocity baseline the next phase's price was based on, corrupting that estimate too.
The fix isn't a heavier process — it's a lighter, mandatory one. A change is formal when it does one of three things:
- Adds a story not in the approved backlogFormal CR
- Increases complexity by more than one size step (S→L, M→XL)Formal CR
- Introduces a new epicFormal CR
Everything else — wording, minor UI, configuration decisions — is absorbed inside sprint hours, no process required. When a formal CR does trigger, it runs an absorbability test: it fits in the current sprint only if it's within 80% of remaining capacity, displaces no blocked story, and needs no new architectural decision. If any of those fail, it's deferred or split — never silently squeezed in. Every CR-scope hour is tagged separately, so it never contaminates the original-scope velocity the next fixed price is quoted from.
The phase model
Why the price comes after the data, not before it
Quoting a full build from a wireframe and a feeling means the fixed price is set before anyone has measured how fast the team actually moves on that specific codebase, stack, and client. The method splits every engagement instead:
Phase 1 builds real scope and measures real velocity — hours per story, pull requests, carry-overs, test density — against the actual project, not an industry average. Phase 2 is priced from those actuals, with the infrastructure correction factor calibrated to what was actually measured rather than assumed up front.
This is also why single-phase planning is a known failure mode: committing a whole build's price before any real velocity data exists produces the same optimism the correction factor exists to fix, just at a larger scale.
Quality grading
Graded against published frameworks, not our own opinion
At phase close, the codebase is scored against three established, external frameworks in combination — no single one is sufficient alone:
- ISO/IEC 25010 — product quality, 8 characteristicsA–E
- DORA — delivery operational health, 4 metricsElite–Low
- SonarQube-style static gate — 5 metricsA–E
Every grade above a bare pass carries an explicit confidence level — measured, projected pending a tool run, or not yet earned — and every rating that depends on real production load stays asterisked until real customers exist to earn it. A DORA "Elite" rating with zero live customers means the pipeline is built right, not that the system has proven itself under load; the scorecard says which one it is, because the difference is the whole point of grading against a framework instead of an adjective.
The full grading model, and the numeric gates each phase closes against, are on the consulting page.
In short
This is what the five free skills encode
None of the above requires our involvement to use. The correction factor, the five-pass backlog method, the change-request test, and the discovery-gaps report are built into the free Factory skills on the official Anthropic marketplace — this page just shows the work behind the numbers.