Activities - Estimate the Project

#	Name	Abbrev.	Guidance	Actions
Elaboration 8
1	Assess Estimation Readiness	EST-1	Purpose Determine what inputs are available, choose the appropriate estimation level (Level 1 SWAG vs. …	Read the 'EST-1 Assess Estimation Readiness' activity from playbook 'Junior Edda' (workflow 'Estimate the Project'). Follow its guidance when assisting me. ## Purpose Determine what inputs are available, choose the appropriate estimation level (Level 1 SWAG vs. Level 2 Detailed), and produce an Estimation Strategy document that governs the rest of the workflow. ## Prerequisites - Project idea, vision document, or feature files exist - Stakeholder available to answer risk-profile questions ## Steps ### Step 1: Inventory Available Inputs Check which artifacts exist and record their status: \| Artifact \| Location \| Status \| \|---\|---\|---\| \| BDD Feature Files \| `docs/features/` \| exists / partial / missing \| \| Software Architecture Overview \| `docs/architecture/SAO.md` \| exists / missing \| \| User Journey \| `docs/features/user_journey.md` \| exists / missing \| \| Previous Sprint Actuals \| Reference Table \| exists / missing \| \| Reference Story Calibration \| Reference Table \| calibrated / uncalibrated \| ### Step 1.5: Check Project Bootstrap and Process Setup Status Verify whether the project has been bootstrapped (BSP workflow) and whether the AI IDE has been configured (DSP workflow): BSP check — is the project runnable? \| Check \| What to Look For \| Status \| \|-------\|------------------\|--------\| \| Git repository \| `.git/` directory exists \| exists / missing \| \| Project entry point \| `manage.py`, `package.json`, `Cargo.toml`, etc. \| exists / missing \| \| Dependency file \| `requirements.txt`, `package.json`, `Cargo.toml` \| exists / missing \| \| Makefile \| `Makefile` with `provision`, `run`, `test` targets \| exists / missing \| \| Source directories \| Application code directories per SAO.md structure \| exists / missing \| If 3+ BSP checks are missing → project is not bootstrapped. Action for non-bootstrapped projects: Ask user: "Project is not bootstrapped. Include BSP + DSP setup in the estimate as Sprint 0 overhead?" - Yes → Add Sprint 0 overhead to estimation: - Create a "Sprint 0: Project Setup" line item in the WBS and Client Quote - BSP overhead: 10 FP (8 activities — see REFERENCE_TABLE §7) - DSP overhead: 5 FP (6 activities — see REFERENCE_TABLE §7) - Total Sprint 0: ~15 FP (before Stack × Org adjustment) - Record in ESTIMATION_STRATEGY.md: "Sprint 0 bootstrap overhead included: 15 FP" - No → Redirect to BSP workflow: - Stop EST workflow - Direct user: "Please run BSP (Bootstrap Project) workflow first, then return to EST" - Record in ESTIMATION_STRATEGY.md: "Bootstrap deferred — not included in estimates" DSP check — is the AI IDE configured? \| Check \| What to Look For \| Status \| \|-------\|------------------\|--------\| \| CLAUDE.md \| `CLAUDE.md` exists in project root \| exists / missing \| \| Copilot instructions \| `.github/copilot-instructions.md` exists \| exists / missing \| \| Windsurf/Cursor rules \| `.windsurf/rules/` or `.cursor/rules/` exists \| exists / missing \| If DSP artifacts are missing and BSP is being quoted: include DSP FP in the Sprint 0 overhead (already in the 15 FP above). If BSP is done but DSP is missing: add DSP as a 5 FP line item in Sprint 1. If project is fully bootstrapped and DSP is done → proceed to Step 2 (no action needed). ### Step 2: Run Boehm & Turner 5-Factor Risk Assessment Rate each factor on the appropriate scale. Circle the home ground that applies. \| Factor \| Agile Home Ground \| Plan-Driven Home Ground \| This Project \| \|---\|---\|---\|---\| \| Team Size \| ≤10 \| ≥20 \| ___ \| \| Criticality \| Low (comfort) \| High (money/life) \| ___ \| \| Requirements Dynamism \| High change rate \| Stable \| ___ \| \| Culture \| Chaos-tolerant \| Order-preferring \| ___ \| \| Personnel \| All senior/CRACK \| Mixed skill levels \| ___ \| Identify dominant risk type: - A-risks dominate (too agile) → lean toward more process/Level 2 - P-risks dominate (too plan-driven) → stay Level 1, iterate fast - Mixed → Level 1 now, schedule Level 2 after Sprint 1 ### Step 3: Select Estimation Level Level 1 SWAG — use when: - Feature files exist but SAO.MD is absent - Project is in early discovery - Team size ≤ 5, low criticality - First sprint (always start here) Level 1 + Level 2 Detailed — use when: - `docs/architecture/SAO.md` exists and is current - Requirements stability ≥ 80% (McConnell prerequisite) - Team size > 10 or criticality is high - Stakeholder requires commitment-quality estimates Both levels produce the same Excel output; Level 2 simply populates additional tabs (WBS Features + Detailed Estimates) and enables the Client Quote tab (AFP pricing). ### Step 4: Document Estimation Strategy Create or update `docs/plans/ESTIMATION_STRATEGY.md` with: - Estimation level chosen and rationale - Risk profile summary (5-factor ratings) - Sprint 0 overhead included? (BSP/DSP FP count) - Gate condition for upgrading to Level 2 (e.g., "after SAO.MD is complete") - Sprint refinement cadence (default: every sprint close) - Reference Table location ### Step 5: Open Excel Estimation Template Open `docs/plans/ESTIMATION_TEMPLATE.xlsx`. Verify all tabs are present: 0. Client Quote 1. Setup 2. Scenario List 3. ECF 4. TCF 5. Rough Estimates 6. Monte Carlo 7. WBS Features 8. Detailed Estimates If file does not exist, copy from `forge/templates/ESTIMATION_TEMPLATE.xlsx`. ## Rules to Follow ### I. Prerequisites Before Estimating Never produce token or duration estimates without first completing Steps 1–3. An estimate produced without a risk assessment is a guess, not engineering. ### II. Level Decision is Reversible Choosing Level 1 does not prevent upgrading to Level 2 later. Record the upgrade gate condition explicitly so it is not forgotten. ### III. McConnell Prerequisite Checklist Before Level 2: confirm problem definition is documented, requirements are ≥ 80% complete, and architecture is sketched. Without these, Level 2 adds false precision, not real accuracy. ### IV. Sprint 0 Is Always Quoted Separately BSP and DSP overhead FP must appear as a separate line item on the Client Quote — never blended into feature delivery FPs. The client must see the setup cost explicitly. ## Success Criteria - Input inventory complete - Bootstrap and DSP status checked; Sprint 0 overhead FP recorded if applicable - 5-factor risk assessment documented - Estimation level selected with rationale - ESTIMATION_STRATEGY.md created/updated - Excel template open and verified
2	Calibrate Reference Stories	EST-2	Purpose Define concrete reference stories at each T-shirt size, assign K-token baselines (tokens per story …	Read the 'EST-2 Calibrate Reference Stories' activity from playbook 'Junior Edda' (workflow 'Estimate the Project'). Follow its guidance when assisting me. ## Purpose Define concrete reference stories at each T-shirt size, assign K-token baselines (tokens per story point) to anchor token budget estimates, and assign FP weights to anchor client-facing AFP pricing. This calibration baseline governs both internal estimates and client quotes for the entire project. ## Prerequisites - EST-01 complete - Reference Table accessible (or being created for first time) ## Steps ### Step 1: Define Reference Stories A reference story is a concrete, completed BDD scenario that the team agrees represents a given size. Every future scenario is sized relative to these anchors. Populate the Setup tab of ESTIMATION_TEMPLATE.xlsx with reference stories: \| Size \| SP (internal) \| FP weight (client) \| Example Reference Story \| K Tokens (min) \| K Tokens (exp) \| K Tokens (max) \| \|------\|:-------------:\|:------------------:\|-------------------------\|---------------:\|---------------:\|---------------:\| \| XS \| 0.5 \| 0.5 \| Read-only list view, no filtering, single model \| — \| — \| — \| \| S \| 1 \| 1 \| Single CRUD operation, one model, 3–5 scenarios \| — \| — \| — \| \| M \| 2 \| 2 \| Feature with 2 models, service layer, 6–10 scenarios \| — \| — \| — \| \| L \| 5 \| 3 \| Multi-model feature with integrations, 10–15 scenarios \| — \| — \| — \| \| XL \| 8 \| 5 \| Complex subsystem, external API, >15 scenarios \| — \| — \| — \| SP vs FP — keep them separate: - SP (Story Points) — internal effort measure. Used to compute token budget and duration. Never on client quote. - FP (Function Points) — client-facing deliverable measure. Used in AFP formula. Goes on the invoice. - L and XL FP weights are lower than SP because complex internal effort does not translate 1:1 to delivered client value. Reference stories must be real scenarios from either: - This project's own backlog (preferred once Sprint 1 completes) - The Reference Table from prior projects ### Step 2: Assign K-Token Baselines K tokens = total tokens (input + output) consumed by the AI to implement one story point, across all BPE activities for that scenario size. If Reference Table has prior data: - Copy K-token values (min/expected/max) per size tier from Reference Table §1 - Note the project and sprint they came from - Adjust if tech stack or AI model differs If no prior data (first project / calibration sprint): Use seed estimates from Reference Table §1: - XS (0.5 SP): min=12K, expected=22K, max=36K tokens - S (1 SP): min=25K, expected=45K, max=72K tokens - M (2 SP): min=60K, expected=100K, max=160K tokens - L (5 SP): min=155K, expected=250K, max=410K tokens - XL (8 SP): min=275K, expected=440K, max=720K tokens These are PERT seed values — mark as "uncalibrated" until Sprint 1 actuals are collected. ### Step 3: Document AI Productivity Adjustment Factor (PAF) Record in Setup tab: - AI Model in use (Claude Sonnet 4.x, GPT-4o, etc.) - PAF: 1.3–1.6× speed gain over traditional (per Peng et al. 2023, GitHub 2024) - Rework surcharge: +10–15% of coding tokens (41% higher churn rate, Ziegler 2024) - Net PAF applied: ___ ### Step 4: Define Sprint Parameters In Setup tab, record: - Sprint duration: ___ days (default: 1 day for AI-assisted development) - Working hours per day: ___ (default: 8h) - Token budget per sprint: ___ K (from stakeholder constraint or derived) - Max SP per sprint: ___ (from capacity) ### Step 5: Record Pricing Calibration Status In Setup tab, record: - $/FP rate: ___ (SEED default: $250 — see Reference Table §6) - Status: SEED / CALIBRATED (SEED until 3 sprints of actuals) - Stack Factor selected: ___ (from Reference Table §4 — applies to AFP) - Org Factor selected: ___ (from Reference Table §5 — applies to AFP) These inputs feed the Client Quote tab (Tab 0). ### Step 6: Flag Calibration Status Mark each K-token row in the Setup tab as one of: - CALIBRATED — based on ≥3 actual sprints for this size tier - SEED — using reference table baseline, not yet validated - BORROWED — from Reference Table of a different project Estimates from SEED or BORROWED sources carry wider PERT ranges. The Monte Carlo simulation will reflect this uncertainty. ## Rules to Follow ### I. Reference Stories Must Be Concrete Vague reference stories produce vague estimates. If no suitable reference story exists, the first sprint is a calibration sprint — its primary output is validated K-token values, not features. ### II. Never Flatten to Single-Point Estimates Always record min/expected/max. Single-point K-token values underestimate variance and defeat the purpose of Monte Carlo. ### III. SP and FP Are Different Units — Never Conflate SP measures effort. FP measures deliverable capability. Both are needed: SP drives internal token budget, FP drives the client quote. Record both in the Setup tab. ### IV. Calibration Improves Sprint-by-Sprint After each sprint close (EST-08), update K-token actuals and $/FP_actual. After 3+ sprints per size tier, mark as CALIBRATED and narrow the PERT range. ## Success Criteria - Reference stories defined for all active size tiers - Both SP and FP weight recorded per size tier - K-token baselines populated (SEED or CALIBRATED) with min/expected/max - AI productivity adjustment factor documented - Sprint parameters set - $/FP, Stack Factor, Org Factor recorded in Setup tab - Setup tab of ESTIMATION_TEMPLATE.xlsx complete ## Inputs Read these before starting this activity. They are produced earlier in the playbook and are authoritative — raise a drift event instead of deviating. - GitHub Release (Other, Optional) — produced by Close Iteration (#118). - Lessons Learned Document (Document, Optional) — produced by Close Iteration (#118).
3	Size Scenarios (Level 1 SWAG)	EST-3	Purpose Assign a T-shirt size (XS → XL) to every BDD scenario using the reference …	Read the 'EST-3 Size Scenarios (Level 1 SWAG)' activity from playbook 'Junior Edda' (workflow 'Estimate the Project'). Follow its guidance when assisting me. ## Purpose Assign a T-shirt size (XS → XL) to every BDD scenario using the reference stories as anchors. Record both SP (for token budget) and FP weight (for client AFP). Produce story point totals per feature and per sprint. Populate the Scenario List tab of ESTIMATION_TEMPLATE.xlsx. ## Prerequisites - EST-02 complete (reference stories defined, K-token baselines set, SP and FP weights recorded) - BDD feature files exist in `docs/features/` ## Steps ### Step 1: Enumerate All Scenarios Read all `.feature` files in `docs/features/`. For each scenario, record: - Scenario ID (e.g., `FOB-PLAYBOOKS-LIST+FIND-01`) - Feature name - Act/group - One-line description (from Scenario title) Paste the list into the Scenario List tab, one row per scenario. ### Step 2: Size Each Scenario Against Reference Stories For each scenario, compare to the reference stories defined in EST-02: Sizing heuristics: \| Ask This \| Size \| SP \| FP \| \|----------\|------\|:--:\|:--:\| \| Single read-only view, no writes? \| XS \| 0.5 \| 0.5 \| \| One model, one CRUD operation, happy path? \| S \| 1 \| 1 \| \| Two models or one model with complex logic? \| M \| 2 \| 2 \| \| Multiple models, service layer, or external call? \| L \| 5 \| 3 \| \| Multi-subsystem, external API, complex orchestration? \| XL \| 8 \| 5 \| \| Clearly larger than XL? \| Split first \| — \| — \| For each scenario, record: assigned size, SP value, FP weight, and a one-line sizing rationale. Anti-patterns — never do these: \| Anti-pattern \| Why Wrong \| Correct Approach \| \|---\|---\|---\| \| Size by scenario count (10 scenarios → L or XL) \| Scenario count measures test breadth, not implementation effort \| Size by code complexity and reuse, not test count \| \| Size 2nd/3rd CRUD entity same as 1st \| Pattern reuse cuts effort 3–5× \| Downgrade reused entities: first entity S→M, 2nd+ XS→S \| \| Size all config/bootstrap steps as S or M \| Config-heavy work is code-light \| Config work is XS; infrastructure overhead goes in Sprint 0 \| \| Treat reuse as free \| EXTEND still consumes tokens to read/modify \| Apply 0.6× EXTEND multiplier in Level 2 (EST-06) \| ### Step 3: Challenge Outliers Before finalizing, review: - Any scenario sized XL → can it be split into two L scenarios? - Any scenario sized > XL → must be split (McConnell rule: no single unit > 1.5× reference L) - Any cluster of XS scenarios that share a model → consider whether they belong to one M Propose splits/merges to user for approval before proceeding. ### Step 4: Group by Feature and Sprint In the Scenario List tab: 1. Group rows by Feature (sub-total SP and FP per feature) 2. Assign scenarios to sprints based on: - Dependencies (parent model before child, auth before protected endpoints) - Priority (must-have before nice-to-have) - Sprint capacity (SP per sprint from Setup tab) 3. Record: Sprint #, SP allocated, FP allocated, cumulative SP, cumulative FP ### Step 5: Compute Totals In the Scenario List tab, compute and record: - Total scenarios: ___ - Total SP: ___ (drives token budget in EST-05) - Total FP: ___ (drives AFP quote in Client Quote tab) - SP per sprint (sum per sprint column) - FP per sprint (sum per sprint column) - Estimated number of sprints ### Step 6: Flag Assumptions For any scenario where sizing is uncertain, add a flag column entry: - `ASSUMPTION: sized M because requirements unclear for error handling` - `ASSUMPTION: sized L but may be M if third-party API has SDK` These assumptions become the first risk items to address in Sprint 1. ## Rules to Follow ### I. Size Relative to Reference, Not Absolute Never size in hours or days. Size by comparing to the reference story. The reference story is the unit of measure. ### II. One Scenario Per Row Do not aggregate scenarios into epics in this tab. The Monte Carlo simulation operates at the scenario level. Aggregation happens only in the sprint grouping columns. ### III. Record Both SP and FP Every row must have both SP (for internal token budget) and FP weight (for client quote). They differ for L and XL — do not conflate them. ### IV. Scenario Must Be Independently Executable If a scenario cannot be tested in isolation, split it or make the dependency explicit. ### V. No Hidden Work Every piece of work that will consume tokens must map to a scenario. Infrastructure, CI/CD, devops scaffolding → Sprint 0 overhead line item (BSP/DSP FPs from EST-01). ## Success Criteria - All BDD scenarios enumerated and sized - Both SP and FP weight recorded per scenario - No unresolved XL+ scenarios (all split or explicitly approved) - Scenarios grouped into sprints respecting dependencies and capacity - SP and FP totals computed per feature, per sprint, project total - Assumptions flagged - Scenario List tab of ESTIMATION_TEMPLATE.xlsx complete
4	Assess Risk Multipliers	EST-4	Purpose Two separate multiplier assessments are performed here: Section A — Internal (ECF/TCF): Rate Environmental …	Read the 'EST-4 Assess Risk Multipliers' activity from playbook 'Junior Edda' (workflow 'Estimate the Project'). Follow its guidance when assisting me. ## Purpose Two separate multiplier assessments are performed here: Section A — Internal (ECF/TCF): Rate Environmental and Technical Complexity Factors to produce the combined multiplier that adjusts raw SP-based token estimates. These factors also calibrate the $/FP rate. Never shown to client. Section B — Client-Facing (Stack Factor / Org Factor): Select the Stack Factor and Org Factor that go into the AFP formula on the Client Quote. These encode the same real-world friction in commercially legible terms. Shown on quote. The two assessments are done together because they are informed by the same project context, but they produce separate outputs. ## Prerequisites - EST-03 complete (scenarios sized) - Stakeholder available to validate risk ratings --- ## Section A — Internal: ECF / TCF ### Step A1: Rate ECF Factors Open the ECF tab in ESTIMATION_TEMPLATE.xlsx. Rate each factor from 0 (no influence) to 5 (strong influence). Environmental Complexity Factors: \| # \| Factor \| Weight \| Rating (0–5) \| Weighted \| \|---\|---\|---\|---\|---\| \| E1 \| Familiarity with the AI model/tooling used \| 1.5 \| \| \| \| E2 \| Part-time participation (interruptions, context switching) \| -1.0 \| \| \| \| E3 \| Analyst / prompt engineering experience \| 0.5 \| \| \| \| E4 \| Lead developer application experience \| 0.5 \| \| \| \| E5 \| Motivation of team \| 1.0 \| \| \| \| E6 \| Stability of requirements \| 2.0 \| \| \| \| E7 \| Part-time users / product owners \| -1.0 \| \| \| \| E8 \| Difficulty of programming language / stack \| -1.0 \| \| \| ECF Formula: `ECF = 1.4 + (-0.03 × Σ(Weight × Rating))` A value < 1.0 means favorable environment (fewer tokens). A value > 1.0 means challenging (more tokens). AI-Specific Extension (add to ECF tab): \| # \| Factor \| Weight \| Rating (0–5) \| Weighted \| \|---\|---\|---\|---\|---\| \| A1 \| AI model tier (Claude Opus=5, Sonnet=3, Haiku=1) \| 0.8 \| \| \| \| A2 \| Prompt maturity (mature prompts=5, first use=1) \| 0.6 \| \| \| \| A3 \| Hallucination risk (well-known domain=1, novel=5) \| -0.5 \| \| \| \| A4 \| Context window pressure (small ctx=5, large=1) \| -0.4 \| \| \| \| A5 \| AI-generated code rework rate (41% baseline = 3) \| -0.6 \| \| \| `ECF_final = ECF_base × (1 + AI_adjustment)` ### Step A2: Rate TCF Factors Open the TCF tab. Rate each factor 0–5. Technical Complexity Factors: \| # \| Factor \| Weight \| Rating (0–5) \| Weighted \| \|---\|---\|---\|---\|---\| \| T1 \| Distributed system / microservices \| 2.0 \| \| \| \| T2 \| Response time / performance requirements \| 1.0 \| \| \| \| T3 \| End-user efficiency (optimized UX needed) \| 1.0 \| \| \| \| T4 \| Complex internal processing / algorithms \| 1.0 \| \| \| \| T5 \| Code reusability requirement \| 1.0 \| \| \| \| T6 \| Easy to install / deploy \| 0.5 \| \| \| \| T7 \| Easy to use (usability) \| 0.5 \| \| \| \| T8 \| Portability across platforms \| 2.0 \| \| \| \| T9 \| Easy to change / maintainability \| 1.0 \| \| \| \| T10 \| Concurrent use / multi-user \| 1.0 \| \| \| \| T11 \| Security features \| 1.0 \| \| \| \| T12 \| Direct access for third parties / APIs \| 1.0 \| \| \| \| T13 \| Special user training required \| 1.0 \| \| \| TCF Formula: `TCF = 0.6 + (0.01 × Σ(Weight × Rating))` ### Step A3: Compute Internal Combined Multiplier `Internal Multiplier = ECF_final × TCF` Record in Setup tab. Applied to all SP × K estimates in EST-05 to produce the token budget. This multiplier also feeds the $/FP calibration rate (EST-08): as ECF/TCF are refined by actuals, the effective cost per FP delivered changes, and $/FP is updated accordingly. \| Combined Multiplier \| Meaning \| \|---\|---\| \| < 0.8 \| Highly favorable — experienced team, stable requirements, mature AI tooling \| \| 0.8 – 1.0 \| Normal — typical project \| \| 1.0 – 1.3 \| Moderate risk — some unknowns \| \| 1.3 – 1.6 \| High risk — unstable requirements or novel domain \| \| > 1.6 \| Very high risk — reconsider scope before estimating further \| --- ## Section B — Client-Facing: Stack Factor and Org Factor ### Step B1: Select Stack Factor From Reference Table §4, select the base tier that best describes the client's technology environment, then apply any additive modifiers: Base tiers: \| Stack Factor \| Select If... \| \|:------------:\|-------------\| \| 0.85 \| Greenfield, single clean modern stack, no legacy \| \| 1.00 \| Standard single stack (Django+HTMX, Rails, Node, FastAPI) \| \| 1.25 \| Two integrated stacks (React SPA + REST backend) \| \| 1.50 \| Legacy codebase integration required \| \| 1.75 \| Multi-cloud or platform-constrained \| \| 2.00 \| Enterprise platform (Salesforce, SAP, ServiceNow) \| \| 2.50+ \| Government / highly regulated (FedRAMP, ITAR) \| Additive modifiers: on-premises +0.10, legacy integration +0.15, multi-cloud +0.15, real-time +0.10, mobile +0.20. Record: Stack Factor base + modifiers = Stack Factor total: ___ ### Step B2: Select Org Factor From Reference Table §5, select the tier that best describes the client's organizational friction: \| Org Factor \| Select If... \| \|:----------:\|-------------\| \| 0.80 \| Startup — flat structure, one decision-maker, no formal process \| \| 1.00 \| Small team / SME — basic sprints, PM involved \| \| 1.25 \| Mid-size — defined SDLC, multiple stakeholders \| \| 1.50 \| Enterprise — formal change management, legal/security review gates \| \| 2.00 \| ITIL/ITSM — CAB approvals, change freeze windows \| \| 2.50 \| Regulated enterprise — SOX, PCI-DSS, HIPAA sign-off gates \| \| 3.50 \| Government — procurement gates, FISMA/FedRAMP, multi-agency review \| Record: Org Factor: ___ ### Step B3: Confirm $/FP Rate From Setup tab (populated in EST-02), confirm the $/FP rate applies: - SEED: $250/FP (default until 3 sprints calibrated) - CALIBRATED: actual $/FP from last sprint close (EST-08) Record in Client Quote tab (Tab 0). ### Step B4: Preview AFP With Stack Factor, Org Factor, and total FP from Scenario List, compute preview AFP: ``` Preview AFP = Total FP (from Scenario List) × Stack Factor × Org Factor Preview Quote Total = Preview AFP × $/FP ``` This is a preview — the AFP on the Client Quote tab will use the final FP total from EST-05/EST-06. Present preview to user for a sanity check before proceeding. --- ## Rules to Follow ### I. Rate ECF/TCF Honestly, Not Optimistically Optimistic risk ratings are the most common estimation failure. If in doubt between 3 and 4, choose 4. ### II. ECF/TCF Are Internal — Never on Client Quote The client sees Stack Factor and Org Factor. ECF/TCF are calibration inputs for $/FP. Mixing them up produces misleading quotes. ### III. Re-Rate Each Sprint ECF/TCF are not static. At each sprint close (EST-08), revisit factors that have changed. Stack Factor and Org Factor can also change if the project context changes — update and re-quote. ### IV. If AFP Preview Looks Wrong, Fix the Inputs — Not the Rate If the preview AFP produces a surprising total, diagnose which input is off (FP count? Stack Factor? Org Factor?) — not pad or cut the $/FP rate to hit a target number. ## Success Criteria - ECF and TCF factors rated with rationale for outliers (Section A) - Internal combined multiplier computed and recorded in Setup tab - Stack Factor and Org Factor selected and recorded (Section B) - $/FP rate confirmed - AFP preview computed and reviewed - ECF, TCF tabs and Client Quote tab of ESTIMATION_TEMPLATE.xlsx updated
5	Produce Rough Estimates + AFP	EST-5	Purpose Produce two parallel outputs from the Level 1 sizing: Internal token budget — SP …	Read the 'EST-5 Produce Rough Estimates + AFP' activity from playbook 'Junior Edda' (workflow 'Estimate the Project'). Follow its guidance when assisting me. ## Purpose Produce two parallel outputs from the Level 1 sizing: 1. Internal token budget — SP × K-token baselines × ECF × TCF → token estimates per sprint and project total. Used for sprint planning and AI cost forecasting. 2. AFP (Adjusted Function Points) — Σ FP × Stack Factor × Org Factor → the client-facing deliverable measure that feeds the quote. Populated in the Client Quote tab. Both outputs come from the same Level 1 sizing. Token budget stays internal; AFP goes on the invoice. ## Prerequisites - EST-03 complete (SP and FP totals per sprint in Scenario List) - EST-04 complete (internal multiplier in Setup tab; Stack Factor + Org Factor in Client Quote tab) - K-token baselines in Setup tab (SEED or CALIBRATED) ## Steps ### Step 1: Compute Internal Token Estimates Per Scenario For each scenario in the Scenario List tab, compute using SP: ``` Raw Tokens (min) = SP × K_min Raw Tokens (expected) = SP × K_expected Raw Tokens (max) = SP × K_max ``` Where K values are the K-token-per-SP baselines from the Setup tab for the assigned size tier. ### Step 2: Apply Internal Risk Multiplier ``` Adjusted Tokens (min) = Raw Tokens (min) × Internal Multiplier × 0.85 Adjusted Tokens (expected) = Raw Tokens (expected) × Internal Multiplier Adjusted Tokens (max) = Raw Tokens (max) × Internal Multiplier × 1.15 ``` The 0.85/1.15 asymmetric adjustment preserves PERT shape after multiplier application. ### Step 3: Aggregate Token Budget to Sprint Level In the Rough Estimates tab, for each sprint: - Sum adjusted token estimates (min/expected/max) across all scenarios in that sprint - Record sprint token budget (expected) - Record sprint token range (min → max) ### Step 4: Derive Duration ``` Duration (days) = Sprint Token Budget (expected) / Daily Token Throughput ``` Where Daily Token Throughput = tokens the AI processes per working day (from Setup tab, typically 500K–2M depending on model and workflow). For the project total, also compute with McConnell's schedule formula: ``` Duration (days) = 3.0 × (Total Effort Person-Months)^(1/3) ``` (For solo AI development, use sprint-by-sprint approach instead.) ### Step 5: Apply COCOMO Convergence Ranges Adjust estimate ranges according to current phase: \| Phase \| Min Multiplier \| Max Multiplier \| \|---\|---\|---\| \| Initial Concept (vision only) \| × 0.25 \| × 4.0 \| \| Approved Concept (scenarios exist) \| × 0.5 \| × 2.0 \| \| Requirements Spec (≥80% complete) \| × 0.67 \| × 1.5 \| \| Architecture (SAO.MD complete) \| × 0.80 \| × 1.25 \| Mark which phase applies. ### Step 6: Compute AFP (Client-Facing) In the Client Quote tab, compute AFP using FP weights (not SP): ``` AFP = Σ FP × Stack Factor × Org Factor ``` Where: - Σ FP = total FP from Scenario List tab (feature delivery FPs only) - Stack Factor = from EST-04 Section B (Reference Table §4) - Org Factor = from EST-04 Section B (Reference Table §5) Add Sprint 0 overhead separately: ``` Sprint 0 AFP = BSP+DSP FP × Stack Factor × Org Factor = 15 FP × Stack × Org (if bootstrap included) ``` Compute total quote: ``` Quote Total = (Feature AFP + Sprint 0 AFP) × $/FP ``` ### Step 7: Populate Rough Estimates Tab For each sprint, record: - Sprint #, scenarios included, SP total, FP total - Token budget: min / expected / max (in K tokens) — internal - Duration: min / expected / max (in days) — internal - Phase (convergence range applied) - Status: SEED / CALIBRATED / BORROWED For project total: total token budget, total duration, number of sprints, estimated completion date range. ### Step 8: Prepare Two Summaries Internal summary (for sprint planning): ``` Token Budget: P50 = ___ K tokens (range: ___ to ___) Duration: ___ sprints / ___ days (range: ___ to ___) Calibration: {SEED / CALIBRATED} ``` Client summary (for quote communication): ``` Feature delivery: ___ FP → AFP = ___ → $___ Sprint 0 setup: 15 FP → AFP = ___ → $___ ───────────────────────────────────────────── Total AFP: ___ Total Quote: $___ Stack Factor: ___ Org Factor: ___ $/FP: $___ ``` Present both to user for review. ## Rules to Follow ### I. Always Show Ranges for Token Budget Never present a single-point token estimate. Always present min/expected/max. ### II. AFP Is the Client Unit — Token Budget Is Not The client receives AFP and the $ total. The token budget is an internal planning tool. Do not show K-token numbers in the client summary. ### III. Token Budget Is a Constraint, Not Just an Output If expected token budget exceeds the team's capacity, that is a scope/priority conversation. ### IV. AFP Drives Billing — SP Does Not Billing is always AFP × $/FP. Never invoice on SP or raw tokens. ### V. Label the Convergence Phase Every token estimate must declare its convergence phase. An "initial concept" estimate with ±400% uncertainty is not a commitment. ## Success Criteria - Token estimates (min/expected/max) computed for all scenarios (internal) - AFP computed from FP × Stack Factor × Org Factor (client-facing) - Sprint 0 overhead AFP included if bootstrap was flagged in EST-01 - Quote Total = AFP × $/FP computed - COCOMO convergence phase labeled - Rough Estimates tab and Client Quote tab of ESTIMATION_TEMPLATE.xlsx complete - Internal summary and client summary prepared and reviewed ## Inputs Read these before starting this activity. They are produced earlier in the playbook and are authoritative — raise a drift event instead of deviating. - Estimation Reference Table (Document, Required) — produced by Calibrate Reference Stories (#67). - Estimation Template (Excel) (Document, Required) — produced by Size Scenarios (Level 1 SWAG) (#68). - Lessons Learned Document (Document, Optional) — produced by Close Iteration (#118).
6	Decompose Work Packages (Level 2)	EST-6	Purpose At Level 1 (EST-03) you sized features by T-shirt. That was good enough for …	Read the 'EST-6 Decompose Work Packages (Level 2)' activity from playbook 'Junior Edda' (workflow 'Estimate the Project'). Follow its guidance when assisting me. ## Purpose At Level 1 (EST-03) you sized features by T-shirt. That was good enough for a rough cut. Level 2 is different: you have the scenario, you have the screen, you have SAO.md describing exactly how the stack works. You don't need to guess which layers a feature touches — BPE-01 will tell you. EST-06 runs BPE-01 in dry-run/estimation mode on each work package to produce a bottom-up artifact list, then wraps each artifact with a PERT triplet from the Reference Table. This is the key idea: BPE-01 Plan → exact artifact list → PERT triplets per artifact → sum = Function Point decomposition. No generic taxonomy lookup required. ## Prerequisites - `docs/architecture/SAO.md` exists and is current - EST-05 complete (Rough Estimates available as cross-check) - Requirements stability ≥ 80% (McConnell prerequisite) ## Gating Condition If SAO.MD does not exist, skip this activity. Return here after SAO.MD is produced (typically after ESM workflow completes). Record this as a gate condition in ESTIMATION_STRATEGY.md. ## Steps ### Step 1: Select the Work Package Take the next undecomposed work package from the sprint plan (EST-05 output). You need three inputs: 1. The scenario file — `docs/features/{act}/{feature}.feature` 2. The screen — find the matching node in the dialogue map (`docs/architecture/screen-flow.drawio`) 3. SAO.md — the authoritative architecture and stack description ### Step 2: Run BPE-01 in Estimation Mode Execute BPE-01 (Plan Feature) for this work package, treating it as if starting from scratch. BPE-01 will produce an Implementation Plan that lists every artifact needed: ``` → Input: feature file + screen name + SAO.md → Output: Implementation Plan listing every artifact: - Django Model + Admin (if new data shape) - Repository methods (which ones, for what queries) - Service layer (what business logic) - Django View + URL pattern (which views, GET/POST) - Unit + Integration tests (what to test) - Django Template + HTMX (which fragments/pages) - Feature Acceptance Tests (from scenario steps) - Journey Certification Tests (if cross-feature flow) - DoD checklist - E2E Playwright tests + PR ``` For each artifact, BPE-01 will also output its reuse flag based on codebase assessment: - NEW — doesn't exist yet, build from scratch - EXTEND — exists but needs significant modification - REUSE — exists, minimal touch needed > Estimation mode means: produce the plan but do not write any code. Stop after BPE-01 Plan and record the artifact list. ### Step 3: Assign PERT Triplets For each artifact in the Implementation Plan, assign PERT triplets (min / expected / max tokens) from the Reference Table K ranges: \| Artifact \| Small (K) \| Medium (K) \| Large (K) \| \|---\|---:\|---:\|---:\| \| Django Model + Admin \| 8 / 15 / 28 \| \| \| \| Repository methods \| 5 / 10 / 20 \| \| \| \| Service layer \| 8 / 18 / 35 \| \| \| \| Django View + URL \| 6 / 12 / 22 \| \| \| \| Unit + Integration Tests \| 10 / 20 / 40 \| \| \| \| Django Template + HTMX \| 8 / 16 / 30 \| \| \| \| Template partials (reusable) \| 4 / 8 / 15 \| \| \| \| Feature Acceptance Tests \| 8 / 15 / 28 \| \| \| \| Journey Certification Tests \| 5 / 10 / 18 \| \| \| \| DoD checklist \| 3 / 6 / 12 \| \| \| \| E2E Playwright tests + PR \| 6 / 12 / 22 \| \| \| \| Implementation Plan (BPE-01) \| 5 / 8 / 15 \| \| \| Apply reuse multipliers based on BPE-01 codebase assessment: - NEW: 1.0× (full token range) - EXTEND: 0.6× (reading + modifying existing code) - REUSE: 0.3× (trivial wiring or config change) ### Step 4: Record the Work Package Enter in the WBS Features tab: ``` Scenario ID: {ACT}-{ENTITY}-{OPERATION}-{NN} Feature: {Feature name from .feature file} Screen: {Screen name from dialogue map} Sprint: {Sprint number} L1 Size: M (2 SP) BPE-01 run: YES / ESTIMATION MODE Artifacts from BPE-01 Plan: WP-01 Django Model (Widget) NEW min=12K exp=16K max=25K WP-02 Repository (WidgetRepo) NEW min=8K exp=11K max=18K WP-03 Service (WidgetService) EXTEND min=8K exp=11K max=19K [×0.6] WP-04 View + URL NEW min=10K exp=14K max=22K WP-05 Unit + Integration Tests NEW min=16K exp=22K max=38K WP-06 Template + HTMX REUSE min=2K exp=4K max=8K [×0.3] WP-07 Feature Acceptance Test NEW min=10K exp=14K max=22K WP-08 DoD checklist NEW min=4K exp=6K max=10K WP-09 E2E test + PR NEW min=8K exp=11K max=18K ──────────────────────────────────────────────────────────────────────── TOTAL: min=78K exp=109K max=180K ``` ### Step 5: Cross-Check Against Level 1 Rough Estimate Compare Level 2 total to Level 1 estimate from EST-05: - Within ±30% → consistent, proceed - L2 > 30% higher than L1 → which artifact is driving the gap? Document it. - L2 > 30% lower than L1 → check for missing artifacts. Common omissions: tests, DoD, E2E. Record delta and rationale in the WBS Features tab notes column. ### Step 6: Repeat for All Work Packages Work through all sprint work packages, highest priority first. After every sprint's worth, sum L2 totals and compare against the Monte Carlo seed in EST-07. If cumulative L2 is >25% outside L1 project total, update the Rough Estimates tab before proceeding. ## Rules to Follow ### I. BPE-01 Is the Decomposition Engine Do not substitute a generic artifact checklist for BPE-01 Plan. The whole point of Level 2 is that you have the actual feature, screen, and architecture — use them. BPE-01 will produce a more accurate artifact list than any template can. ### II. DoD Is Fixed Overhead The DoD checklist (BPE-06) applies to every work package. Never omit it. It is not optional. ### III. Tests Are Not Optional Unit, integration, feature acceptance, and E2E tests are separate work packages. Omitting them produces a false low — the work still happens, it just becomes unplanned rework. ### IV. Decompose Before Estimating Assigning a PERT triplet to a scenario as a whole without running BPE-01 first is a Level 1 estimate masquerading as Level 2. If you skip the BPE-01 step, mark confidence as LOW and document why. ### V. Reuse Is Not Free Extending an existing component still consumes tokens for reading, understanding, and modifying existing code. Use 0.3× for trivial reuse, 0.6× for significant extension, 1.0× for new. ## Success Criteria - BPE-01 Plan executed (estimation mode) for every Level 2 work package - Each work package has a full artifact list with reuse flags - PERT triplets assigned to every artifact - L1/L2 cross-check performed and delta documented - WBS Features and Detailed Estimates tabs complete ## Inputs Read these before starting this activity. They are produced earlier in the playbook and are authoritative — raise a drift event instead of deviating. - User Journey (Document, Required) — produced by Define User Journey (#36). - Screen Flow / Dialogue Map (Diagram, Required) — produced by Create Dialogue Maps (#38). - Feature Files (Document, Required) — produced by Write Feature Files (#39). - HTML Mockups (Code, Optional) — produced by Create Mockups (#40). - Estimation Reference Table (Document, Required) — produced by Calibrate Reference Stories (#67). - Estimation Template (Excel) (Document, Required) — produced by Size Scenarios (Level 1 SWAG) (#68).
7	Run Monte Carlo Simulation	EST-7	Purpose Execute Monte Carlo simulation (10,000 iterations, triangular distributions) over the scenario-level PERT triplets to …	Read the 'EST-7 Run Monte Carlo Simulation' activity from playbook 'Junior Edda' (workflow 'Estimate the Project'). Follow its guidance when assisting me. ## Purpose Execute Monte Carlo simulation (10,000 iterations, triangular distributions) over the scenario-level PERT triplets to produce probabilistic delivery forecasts. The simulation produces two types of output: - Internal: P50/P80/P95 for token budget and calendar duration. Used for sprint planning and AI cost control. - Client-facing: P50/P80/P95 expressed in AFP and $ (AFP × $/FP). Used for delivery commitment communication. The EBS (Evidence-Based Scheduling) diagrams remain internal — the client quote shows AFP bands, not token S-curves. ## Prerequisites - EST-05 complete (Rough Estimates tab with min/expected/max per scenario and per sprint; AFP in Client Quote tab) - OR EST-06 complete for Level 2 (WBS with work-package-level PERT triplets) - Monte Carlo VBS script present in the Monte Carlo tab of ESTIMATION_TEMPLATE.xlsx ## Steps ### Step 1: Verify Simulation Inputs Before running, confirm in the Monte Carlo tab: - Each scenario row has: scenario ID, sprint, min tokens, expected tokens, max tokens - Sprint dependency order is correct - Internal combined multiplier from Setup tab is referenced - Daily throughput (tokens/day) is set in Setup tab If using Level 2 data from EST-06, aggregate work-package PERT triplets to scenario level first (sum of WP min → scenario min, etc.). ### Step 2: Run the VBS Simulation In the Monte Carlo tab, run the VBS macro (Alt+F8 → RunMonteCarloSimulation): The macro performs 10,000 iterations. In each iteration: 1. For every scenario, draw a random token sample from Triangular(min, expected, max) 2. Apply sprint dependency graph (sequential unless flagged parallelizable) 3. Compute total tokens for the iteration 4. Compute total duration (tokens / daily throughput, respecting sprint boundaries) 5. Record [total_tokens, total_duration] to results array Output columns populated by macro: - Column A: iteration token totals (sorted ascending) - Column B: iteration duration totals (sorted ascending) - Column C: cumulative probability (0.0 → 1.0) ### Step 3: Read Internal Simulation Results (Token Budget + Duration) \| Percentile \| Meaning \| Token Budget (K) \| Duration (days) \| \|---\|---\|---\|---\| \| P10 \| Only 10% chance of finishing within this \| ___ K \| ___ days \| \| P50 \| Median — 50/50 chance \| ___ K \| ___ days \| \| P80 \| 80% confidence — recommended for planning \| ___ K \| ___ days \| \| P95 \| Conservative commitment \| ___ K \| ___ days \| Recommended internal planning budget: P80 (ACM SAC 2021 — Monte Carlo achieves MMRE 20% vs 134% for developer estimates; P80 absorbs most residual error). Record these values in the Monte Carlo tab summary section. These are internal and inform sprint budget allocation. ### Step 4: Convert to AFP Bands (Client-Facing) Using AFP and $/FP from the Client Quote tab, compute AFP-equivalent ranges: ``` AFP_P50 = Feature AFP (baseline from EST-05) AFP_P80 = AFP_P50 × (P80_tokens / P50_tokens) ← scale AFP by same ratio as token bands AFP_P95 = AFP_P50 × (P95_tokens / P50_tokens) ``` Then compute $ ranges: ``` Quote_P50 = AFP_P50 × $/FP Quote_P80 = AFP_P80 × $/FP Quote_P95 = AFP_P95 × $/FP ``` Record in the Client Quote tab. This gives the client a defensible range without exposing tokens. ### Step 5: Produce EBS Diagrams (Internal) The EBS (Evidence-Based Scheduling) diagrams show cumulative probability curves — internal planning tools: Curve 1: Token Budget Certainty - X-axis: token budget (K tokens) from P10 to P95 - Y-axis: probability of completing within that budget (0% → 100%) - Mark calibration points: P50, P80, P95 Curve 2: Duration Certainty - X-axis: calendar date (from today to P95 completion date) - Y-axis: probability of completing by that date (0% → 100%) - Mark specific dates: P10, P50 (expected), P80 (planning), P95 (conservative) Both curves are generated by the VBS macro and embedded in the Monte Carlo tab. ### Step 6: Prepare Client Delivery Commitment From the AFP band computation: ``` Delivery Commitment — {Project Name} — {Date} Scope: {N} features, {total FP} FP, Sprint 0 setup included AFP (Adjusted Function Points): P50 (median): AFP = ___ → $___ P80 (planning): AFP = ___ → $___ ← recommended commitment P95 (committed): AFP = ___ → $___ Duration: P50 (median): ___ working days (by ___ date) P80 (planning): ___ working days (by ___ date) P95 (committed): ___ working days (by ___ date) Stack Factor: ___ Org Factor: ___ $/FP: $___ (SEED/CALIBRATED) ``` ### Step 7: Document Simulation Snapshot Save `docs/plans/MC_SNAPSHOT_{DATE}.md` with: - Date, input (total scenarios, total SP, total FP, convergence phase) - ECF/TCF combined multiplier, K-token calibration status - P50/P80/P95 internal (tokens + duration) - P50/P80/P95 client (AFP + $) - Sprint plan summary ## Rules to Follow ### I. Simulation Requires Min ≠ Max If any scenario has min = expected = max, expand: min = expected × 0.7, max = expected × 1.5. ### II. P80 Is the Planning Commitment Never commit to P50. P50 means 50% chance of missing. P80 is the minimum defensible planning target. ### III. Client Sees AFP Bands — Not Token Curves The EBS S-curve is an internal tool. The client communication uses AFP ranges and $ totals. ### IV. Simulate After Each Sprint Close Re-run EST-07 after each EST-08. The simulation updates with actuals replacing estimates for completed scenarios. ### V. Token Cost Is Computable but Internal Tokens × API rate = internal cost of delivery. This informs margin analysis and $/FP calibration. It is never on the client quote. ## Success Criteria - VBS simulation executed (10,000 iterations) - P10/P50/P80/P95 extracted for token budget and duration (internal) - AFP band and $ range computed for P50/P80/P95 (client-facing) - EBS diagrams generated (internal — Monte Carlo tab) - Client delivery commitment prepared (AFP + $ ranges) - MC_SNAPSHOT saved to `docs/plans/` - Monte Carlo tab and Client Quote tab updated
8	Sprint Close & Rebaseline	EST-8	Purpose At the end of each sprint, collect actual token consumption, compute Velocity Factor (VF …	Read the 'EST-8 Sprint Close & Rebaseline' activity from playbook 'Junior Edda' (workflow 'Estimate the Project'). Follow its guidance when assisting me. ## Purpose At the end of each sprint, collect actual token consumption, compute Velocity Factor (VF = actual FP delivered / estimated AFP), update K-token baselines, calibrate $/FP from actuals, and re-run Monte Carlo. This loop is the engine of estimate improvement and pricing calibration across the project. If scope changed during the sprint (requirements modified, feature added/removed): run BPE-08 (Process Change Request) first. Do not blend scope-change overruns into calibration data. ## Prerequisites - Sprint completed (or partially completed with clear scope boundary) - Token consumption data available from AI model billing/usage logs - Scenario completion status recorded - No unresolved scope changes (BPE-08 completed if needed) ## Steps ### Step 1: Collect Sprint Actuals For each scenario attempted in the sprint, record: - Scenario ID - Planned SP, planned FP weight - Planned tokens (expected from estimate) - Actual tokens consumed (from AI usage logs) - Actual API cost ($) for this sprint - Status: DONE / PARTIAL / BLOCKED / DEFERRED - Notes (scope changes, surprises — flag any BPE-08 items) Record in the Scenario List tab, "Sprint N Actuals" columns. ### Step 2: Compute Velocity Factor (Internal — Token-Based) For each completed scenario: ``` Token VF = Actual Tokens / Estimated Tokens (expected) ``` Sprint-level VF: ``` Sprint Token VF = Σ Actual Tokens (completed) / Σ Estimated Tokens (same scenarios) ``` \| VF Range \| Meaning \| Action \| \|---\|---\|---\| \| < 0.8 \| AI performed faster than estimated \| Reduce K_expected; tighten K_min \| \| 0.8 – 1.2 \| On target \| Minor adjustment only \| \| 1.2 – 1.5 \| Slower than expected \| Increase K_expected; widen K_max \| \| > 1.5 \| Significant overrun \| Investigate root cause before adjusting \| ### Step 3: Update K-Token Baselines For each size tier with ≥ 1 completed actual: 1. Append actual to running history in Reference Table §11 2. Recompute: K_expected = weighted average last 3–5 actuals; K_min = 10th pct; K_max = 90th pct 3. Update Setup tab K values 4. Calibration status: 1 actual → SEED; 2 actuals → BORROWED; ≥3 actuals → CALIBRATED ### Step 4: Calibrate $/FP (Client Pricing — Critical) Compute the actual cost per delivered FP for this sprint: ``` $/FP_actual_sprint = Actual API Cost ($) / Σ FP (completed scenarios) ``` Update the running $/FP calibration in Setup tab: ``` $/FP_calibrated = weighted average of $/FP_actual across last 3–5 sprints ``` Update $/FP in Client Quote tab with the calibrated rate. Change calibration status from SEED → CALIBRATED once 3+ sprint actuals are available. This is the feedback loop that keeps the AFP pricing model honest: as the team gets faster (PAF improves), $/FP drops; as scope grows harder, $/FP rises. The client quote rate tracks reality, not seed assumptions. ### Step 5: Compute AFP VF (Client-Facing — Delivery Performance) ``` AFP VF = Σ FP (delivered this sprint) / AFP (estimated for this sprint in Client Quote) ``` \| AFP VF \| Meaning \| \|---\|---\| \| > 1.0 \| Delivered more FP value than quoted — favorable \| \| = 1.0 \| On target \| \| < 1.0 \| Delivered less FP value than quoted — investigate \| Record AFP VF in Reference Table sprint actuals section. This is the metric to show the client as a delivery health indicator. ### Step 6: Re-Rate ECF/TCF (If Warranted) Review factors that may have changed: - E6 (requirements stability) — did requirements churn this sprint? - A3 (hallucination risk) — did AI quality improve as it learned the codebase? - A2 (prompt maturity) — did new prompts prove more efficient? Update ECF/TCF tabs if any factor changes by ≥ 1 point. Recompute internal combined multiplier. ### Step 7: Update Remaining Scenario Estimates For remaining (not yet started) scenarios: - Apply updated K baselines (token budget) - If a class of scenarios ran significantly over/under, apply Token VF as correction factor - Do not touch FP weights — FP is a client commitment, not an internal variable ### Step 8: Re-Run Monte Carlo Run EST-07 over remaining scenarios only: - Completed scenarios: replace with actuals (fixed values, no simulation) - Remaining scenarios: re-simulate with updated PERT distributions - Output: new P50/P80/P95 for token budget, duration, AFP, and $ Compare to previous MC_SNAPSHOT: - Is P80 completion date improving sprint-over-sprint? (healthy) - Is P80 drifting outward? (scope growth or systematic under-estimation — investigate) Save new `docs/plans/MC_SNAPSHOT_{DATE}.md`. ### Step 9: Update Reference Table Append to `docs/plans/REFERENCE_TABLE.md` §11: ``` ## Sprint {N} Actuals — {Date} \| Scenario \| Size \| SP \| FP \| Est. Tokens \| Actual Tokens \| Token VF \| Est. AFP \| Actual FP \| AFP VF \| \|---\|---\|---\|---\|---\|---\|---\|---\|---\|---\| \| FOB-X-Y-01 \| M \| 2 \| 2 \| 110K \| 127K \| 1.15 \| 2 AFP \| 2 FP \| 1.0 \| $/FP this sprint: $___ (API cost $___ / ___ FP delivered) $/FP calibrated: $___ (was: $___) — status: SEED / CALIBRATED Updated K baselines: {list tiers updated} Combined multiplier: {value} (was: {previous}) ``` ### Step 10: Publish Sprint Report ``` Sprint {N} Estimation Report — {Date} Completed: {N} scenarios ({SP} SP / {FP} FP), {actual K}K tokens Planned: {N} scenarios ({SP} SP / {FP} FP), {planned K}K tokens Token VF: {value} AFP VF: {value} API Cost This Sprint: $___ $/FP This Sprint: $___ $/FP Calibrated: $___ Deferred: {list deferred scenarios and reason} Revised Forecast (remaining work): Internal: P50 = {K tokens / days} P80 = {K tokens / days} Client: P80 AFP = ___ → $___ Token Budget Status: Consumed to date: {K} tokens Remaining P80: {K} tokens Total P80: {K} tokens ({% of original P80}) Next sprint: {N} scenarios ({SP} SP / {FP} FP) ``` Present to user/stakeholder. Save to `docs/plans/`. ## Rules to Follow ### I. Actuals Are Sacred Never retroactively adjust planned estimates to match actuals. Both must be preserved as separate columns. ### II. BPE-08 Before Calibration Data Any scope change must be processed through BPE-08 first. Do not blend scope-change overruns into K-token calibration — they will corrupt future baselines. ### III. $/FP Updates Require ≥ 3 Sprints to CALIBRATE 1–2 sprints → BORROWED rate. 3+ sprints → CALIBRATED. Do not price future work off a single sprint anomaly. ### IV. FP Weights Are Fixed — SP Can Move FP weights represent the client-committed value per scenario. Do not retroactively change FP weights after quoting. SP values and K-token baselines are internal calibration variables and can be updated freely. ### V. Investigate AFP VF < 0.8 A sprint where significantly less FP was delivered than quoted is a scope or quality signal. Before re-quoting remaining work, understand why: deferred features? Failed DoD? Unexpected complexity? ### VI. The 20-Data-Point Threshold Monte Carlo achieves MMRE ~20% only after ~20 data points (ACM SAC 2021). Before that, keep PERT ranges wide. ## Success Criteria - Sprint actuals collected (tokens, FP delivered, API cost) - Token VF and AFP VF computed - K-token baselines updated in Setup tab - $/FP calibrated from actuals; status updated (SEED → CALIBRATED after 3 sprints) - Reference Table §11 appended - ECF/TCF re-rated if warranted - Remaining scenario token estimates updated - Monte Carlo re-run, new P50/P80/P95 for tokens and AFP/$ - MC_SNAPSHOT saved, sprint report produced and reviewed - Client Quote tab $/FP updated ## Inputs Read these before starting this activity. They are produced earlier in the playbook and are authoritative — raise a drift event instead of deviating. - Estimation Reference Table (Document, Required) — produced by Calibrate Reference Stories (#67). - Estimation Template (Excel) (Document, Required) — produced by Size Scenarios (Level 1 SWAG) (#68). - Execution Manifest (Document, Required) — produced by Contract (#142). - GitHub Release (Other, Required) — produced by Close Iteration (#118). - Lessons Learned Document (Document, Optional) — produced by Close Iteration (#118).

Activities in Estimate the Project