diff --git a/src/core/tasks/bmad-create-prd/steps-c/step-08-scoping.md b/src/core/tasks/bmad-create-prd/steps-c/step-08-scoping.md index b060dda8d..3d913f6ee 100644 --- a/src/core/tasks/bmad-create-prd/steps-c/step-08-scoping.md +++ b/src/core/tasks/bmad-create-prd/steps-c/step-08-scoping.md @@ -12,6 +12,8 @@ - 📋 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}` - ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}` @@ -75,10 +77,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 @@ -98,6 +113,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 @@ -129,6 +150,8 @@ Prepare comprehensive scoping section: #### Content Structure: +**If user chose phased delivery:** + ```markdown ## Project Scoping & Phased Development @@ -160,6 +183,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: @@ -189,8 +240,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 @@ -202,8 +254,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/core/tasks/bmad-create-prd/steps-c/step-11-polish.md b/src/core/tasks/bmad-create-prd/steps-c/step-11-polish.md index c63ae5b29..decf8865b 100644 --- a/src/core/tasks/bmad-create-prd/steps-c/step-11-polish.md +++ b/src/core/tasks/bmad-create-prd/steps-c/step-11-polish.md @@ -138,7 +138,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