From a5b4f2cfff7b393ba4e69c0611917205522cef65 Mon Sep 17 00:00:00 2001 From: sdev Date: Thu, 12 Mar 2026 19:39:25 +0530 Subject: [PATCH] fix(prd): require explicit user confirmation before de-scoping requirements or inventing phases --- .../create-prd/steps-c/step-08-scoping.md | 66 +++++++++++++++++-- .../create-prd/steps-c/step-11-polish.md | 2 +- 2 files changed, 61 insertions(+), 7 deletions(-) diff --git a/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-08-scoping.md b/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-08-scoping.md index b287bd3a6..7c894e7e4 100644 --- a/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-08-scoping.md +++ b/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-08-scoping.md @@ -1,6 +1,6 @@ --- name: 'step-08-scoping' -description: 'Define MVP boundaries and prioritize features across development phases' +description: 'Define scope boundaries and prioritize features, with phasing only when user requests it' # File References nextStepFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-09-functional.md' @@ -25,6 +25,8 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow - 📋 YOU ARE A FACILITATOR, not a content generator - 💬 FOCUS on strategic scope decisions that keep projects viable - 🎯 EMPHASIZE lean MVP thinking while preserving long-term vision +- ⚠️ NEVER de-scope, defer, or phase out requirements that the user explicitly included in their input documents without asking first +- ⚠️ NEVER invent phasing (MVP/Growth/Vision) unless the user requests phased delivery — if input documents define all components as core requirements, they are ALL in scope - ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}` ## EXECUTION PROTOCOLS: @@ -87,10 +89,23 @@ Use structured decision-making for scope: - Advanced functionality that builds on MVP - Ask what features could be added in versions 2, 3, etc. +**⚠️ SCOPE CHANGE CONFIRMATION GATE:** +- If you believe any user-specified requirement should be deferred or de-scoped, you MUST present this to the user and get explicit confirmation BEFORE removing it from scope +- Frame it as a recommendation, not a decision: "I'd recommend deferring X because [reason]. Do you agree, or should it stay in scope?" +- NEVER silently move user requirements to a later phase or exclude them from MVP + ### 4. Progressive Feature Roadmap -Create phased development approach: -- Guide mapping of features across development phases +**CRITICAL: Phasing is NOT automatic. Check the user's input first.** + +Before proposing any phased approach, review the user's input documents: + +- **If the input documents define all components as core requirements with no mention of phases:** Present all requirements as a single release scope. Do NOT invent phases or move requirements to fabricated future phases. +- **If the input documents explicitly request phased delivery:** Guide mapping of features across the phases the user defined. +- **If scope is unclear:** ASK the user whether they want phased delivery or a single release before proceeding. + +**When the user wants phased delivery**, guide mapping of features across development phases: + - Structure as Phase 1 (MVP), Phase 2 (Growth), Phase 3 (Vision) - Ensure clear progression and dependencies @@ -110,6 +125,12 @@ Create phased development approach: - Platform features - New markets or use cases +**When the user wants a single release**, define the complete scope: + +- All user-specified requirements are in scope +- Focus must-have vs nice-to-have analysis on what ships in this release +- Do NOT create phases — use must-have/nice-to-have priority within the single release + **Where does your current vision fit in this development sequence?**" ### 5. Risk-Based Scoping @@ -141,6 +162,8 @@ Prepare comprehensive scoping section: #### Content Structure: +**If user chose phased delivery:** + ```markdown ## Project Scoping & Phased Development @@ -172,6 +195,34 @@ Prepare comprehensive scoping section: **Resource Risks:** {{contingency_approach}} ``` +**If user chose single release (no phasing):** + +```markdown +## Project Scoping + +### Strategy & Philosophy + +**Approach:** {{chosen_approach}} +**Resource Requirements:** {{team_size_and_skills}} + +### Complete Feature Set + +**Core User Journeys Supported:** +{{all_journeys}} + +**Must-Have Capabilities:** +{{list_of_must_have_features}} + +**Nice-to-Have Capabilities:** +{{list_of_nice_to_have_features}} + +### Risk Mitigation Strategy + +**Technical Risks:** {{mitigation_approach}} +**Market Risks:** {{validation_approach}} +**Resource Risks:** {{contingency_approach}} +``` + ### 7. Present MENU OPTIONS Present the scoping decisions for review, then display menu: @@ -201,8 +252,9 @@ When user selects 'C', append the content directly to the document using the str ✅ Complete PRD document analyzed for scope implications ✅ Strategic MVP approach defined and justified -✅ Clear MVP feature boundaries established -✅ Phased development roadmap created +✅ Clear feature boundaries established (phased or single-release, per user preference) +✅ All user-specified requirements accounted for — none silently removed or deferred +✅ Any scope reduction recommendations presented to user with rationale and explicit confirmation obtained ✅ Key risks identified and mitigation strategies defined ✅ User explicitly agrees to scope decisions ✅ A/P/C menu presented and handled correctly @@ -214,8 +266,10 @@ When user selects 'C', append the content directly to the document using the str ❌ Making scope decisions without strategic rationale ❌ Not getting explicit user agreement on MVP boundaries ❌ Missing critical risk analysis -❌ Not creating clear phased development approach ❌ Not presenting A/P/C menu after content generation +❌ **CRITICAL**: Silently de-scoping or deferring requirements that the user explicitly included in their input documents +❌ **CRITICAL**: Inventing phasing (MVP/Growth/Vision) when the user did not request phased delivery +❌ **CRITICAL**: Making consequential scoping decisions (what is in/out of scope) without explicit user confirmation ❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions ❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file diff --git a/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md b/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md index 40ed0e96a..53ff20b2e 100644 --- a/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md +++ b/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md @@ -151,7 +151,7 @@ Make targeted improvements: - All user success criteria - All functional requirements (capability contract) - All user journey narratives -- All scope decisions (MVP, Growth, Vision) +- All scope decisions (whether phased or single-release) - All non-functional requirements - Product differentiator and vision - Domain-specific requirements