--- status: demonstration audience: public-demonstration fixture: kibble-and-co (fictional) --- # 9. Estimation Scaffold — Required Bid Format The bid is returned in the format below, so a like-for-like evaluation against the scope baseline is possible. A bid that departs from this format must map its own structure back to this one; unmappable bids are returned for rework. ## 9.1 What to return 1. **Fixed-scope estimate for the MVP phase** — every MVP-tagged story in [07-work-breakdown.md](07-work-breakdown.md), estimated at epic granularity using the grid in 9.2. 2. **Options pricing** for the deferred scope groups in [08-scope-boundary-and-engagement-model.md](08-scope-boundary-and-engagement-model.md) §8.3, at domain granularity. 3. **Solution-approach positions** for each native-build decision point in [05-platform-integration-contract.md](05-platform-integration-contract.md) §5.2 — for each: chosen approach, alternative considered, and the effort delta between them. 4. **Assumptions register** — every assumption that materially moves an estimate, numbered, so Kibble & Co.'s approval or correction of an assumption re-prices the affected rows mechanically rather than reopening the bid. 5. **Risk register** — top delivery risks with probability, cost exposure, and the mitigation priced into the bid (or explicitly not priced, stated as such). 6. **Team composition & continuity plan** per 9.5. 7. **Knowledge-transfer plan** per 9.5 — a scored deliverable, not an appendix. 8. **Delivery timeline** — phased milestones with the acceptance events from 08 §8.8 attached to each. ## 9.2 Estimation grid (per epic) One row per epic (28 rows), MVP-phase stories only; deferred phases estimate at domain level in the options section. Person-weeks by discipline; state your week/hour convention once. | Epic | Domain | MVP stories | Complexity drivers you see | BE | FE | QA | DevOps/SRE | PM/BA | Total (pw) | Assumption refs | Confidence (H/M/L) | |---|---|---|---|---|---|---|---|---|---|---|---| | 1 — Platform authentication & processor onboarding | Onboarding | | | | | | | | | | | | 10 — Charge scheduling & execution | Billing | | | | | | | | | | | | … all 28 epics, in register order … | | | | | | | | | | | | Rules: - **Estimate against the written ACs**, not against the section prose. The requirements export accompanying this package carries the full AC text per US-ID. - **No blended "integration tax" row.** Platform-integration effort lands inside the epic that incurs it; the 05 §5.2 decision points carry their own deltas. - **Confidence drives contingency.** Low-confidence rows carry their contingency visibly in the row, not pooled invisibly at the bottom. ## 9.3 Complexity signals already known These are the areas the requirements themselves mark as dense; treat cheap estimates here as a red flag in your own internal review: - **Billing engine and dunning state machine** (Billing domain) — auto-ship scheduling, retry ladders, soft/hard decline classification, idempotency under partial failure. The deepest pure-engineering work in the build. - **Payments rail correctness** (Billing + Onboarding) — CIT/MIT semantics, stored-credential indicators, capture timing, and processor abstraction (Kibble runs card and digital-wallet rails through separate processors). Correctness failures here are compliance failures, not bugs. - **Order generation fidelity** (Orders domain) — renewal-time recalculation of inventory (kibble and treat bag stock), tax, and shipping against live platform state; the policy matrix in 08 §8.4 items 1–4. - **Three distinct user surfaces** (Catalog/Operations + Purchase + Self-Service) — Kibble & Co.'s merchant admin inside the platform control panel, storefront auto-ship purchase experience, and the pet-owner self-service portal. Three UX stacks' worth of design, accessibility, and test surface. - **Event fan-out and integration surface** (Platform domain) — inbound platform webhooks, inbound processor webhooks, outbound webhook/event contracts for third parties, and the developer-facing API. - **Notification matrix** (Platform domain) — the largest single epic by story count; lifecycle × channel × configuration combinatorics (order renewal reminders, decline recovery, skip/pause confirmations). ## 9.4 Reference planning figures (non-binding) For calibration only: Kibble & Co.'s internal engineering team sketched a 16-week MVP-scope plan followed by two ~10-week expansion phases, as a single-team plan. *Illustrative — invented for this demonstration; not a real planning figure.* This is not a bid ceiling or floor and will not be used to score bids mechanically; it exists so that a bid an order of magnitude away from it arrives with its reasoning attached. Every duration in this section is invented for the fictional Kibble & Co. scope; do not quote it as a benchmark for a real subscriptions build. ## 9.5 Team composition & continuity requirements - **Vendor proposes the team**; Kibble & Co. does not dictate roles. The bid names the accountable **solution architect** and **delivery lead** as individuals, with relevant platform/commerce background stated. - **Named-lead continuity**: replacement of named leads during the engagement requires Kibble & Co. approval; the bid states the vendor's bench/continuity approach up front. - **SME pairing**: Kibble & Co. pairs bounded product/architecture SMEs with the vendor team (08 §8.7). The bid states how the vendor consumes that channel — cadence, artifacts, decision turnaround expectations. - **Knowledge transfer is a first-class deliverable**: the capability will be owned, operated, and extended by Kibble & Co.'s engineering team after handover. The KT plan states audience, artifacts, shadowing/reverse-shadowing structure, and the acceptance test for "transfer complete" (08 §8.8 item 5). ## 9.6 How bids are evaluated In descending weight: 1. **Coverage integrity** — every MVP story and every 05 §5.2 decision point is priced; nothing silently excluded or double-counted. 2. **Assumption quality** — assumptions are specific, testable, and priced; an assumptions register that shifts all risk to Kibble & Co. scores poorly. 3. **Solution credibility** — the decision-point positions and complexity-signal responses read like the vendor has built commerce/billing systems before. 4. **Continuity & KT plan** — per 9.5. 5. **Timeline realism** — including how the plan absorbs the acceptance events of 08 §8.8 (they are inside the timeline, not appended after it). 6. **Price.** ## 9.7 Commercial-terms placeholders Outcome-based delivery incentives (early-delivery bonus, milestone holdbacks) are under consideration and will be finalized by Kibble & Co.'s finance function in the contracting stage. Bids should be constructed so milestone boundaries align with the acceptance events in 08 §8.8, which is where any such terms would attach. Do not price incentive mechanics into the base bid. --- Kibble & Co. is a fictional demo merchant. This package is an independent demonstration by Nino Chavez of a scoping method — not a BigCommerce product, and not a real procurement.