refactor: consolidate checklists and improve scope creep detection
- Remove duplicate checklists (epic-readiness, story-approval) in favor of bmad-core equivalents - Add SCOPE-CREEP classification category to prevent scope expansion during reviews - Change consolidation responsibility from architect to scrum master for better neutrality - Update dependencies to include pm-checklist.md from core - Maintain focus on original MVP scope through strict acceptance criteria compliance 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
2-gabadi
parent
23b0220910
commit
f034282b6d
|
|
@ -46,8 +46,10 @@ Addresses the complexity gap in agile story implementation by providing:
|
|||
- **epic-party-mode-retrospective.md**: Automatic epic retrospective with multi-agent analysis
|
||||
|
||||
### Checklists
|
||||
- **story-approval-checklist.md**: Product Owner story validation framework
|
||||
- **epic-readiness-checklist.md**: Epic business readiness validation
|
||||
- Uses bmad-core checklists via execute-checklist task:
|
||||
- **po-master-checklist.md**: Epic readiness and business validation
|
||||
- **pm-checklist.md**: Story approval and acceptance criteria validation
|
||||
- **story-draft-checklist.md**: Story quality validation
|
||||
|
||||
## Integration with Core BMAD
|
||||
|
||||
|
|
|
|||
|
|
@ -1,64 +0,0 @@
|
|||
# epic-readiness-checklist.md
|
||||
|
||||
**Purpose**: Validate epic business readiness and dependencies before story creation
|
||||
**Agent**: po (Product Owner)
|
||||
**Phase**: Pre-Story Creation Validation
|
||||
|
||||
## Epic Business Readiness Validation
|
||||
|
||||
### Epic Existence & Status Verification
|
||||
- [ ] **Epic file exists**: Epic file located in `docs/prd/epic-{epic_number}-*.md` or `docs/epics/epic-{epic_number}-*.md` or user-specified location confirmed
|
||||
- [ ] **Epic status approved**: Epic status is "Approved" (not Draft/In Progress/Review)
|
||||
- [ ] **Epic completion readiness**: Epic has clear business objectives and scope defined
|
||||
- [ ] **Epic format compliance**: Epic follows project template and documentation standards
|
||||
|
||||
### Epic Dependencies Assessment
|
||||
- [ ] **Prerequisite epics completed**: All prerequisite epics are marked "Done" or dependencies resolved
|
||||
- [ ] **No blocking dependencies**: No unresolved technical or business blockers identified for epic scope
|
||||
- [ ] **Resource availability**: Required team members and resources available for epic execution
|
||||
- [ ] **External dependencies clear**: Third-party services, APIs, or integrations ready if needed
|
||||
|
||||
### Epic Context Sufficiency Analysis
|
||||
- [ ] **Business goals clarity**: Epic provides sufficient context for meaningful story creation
|
||||
- [ ] **User journeys defined**: Business goals and user workflows are clearly articulated
|
||||
- [ ] **Success criteria specified**: Epic completion criteria and definition of done are explicit
|
||||
- [ ] **Acceptance boundaries**: Epic scope boundaries and out-of-scope items are clearly defined
|
||||
|
||||
### Story Creation Readiness
|
||||
- [ ] **Story numbering valid**: Requested story number does not conflict with existing stories
|
||||
- [ ] **Epic sequence logic**: Story fits logical sequence within epic roadmap and dependencies
|
||||
- [ ] **Story prerequisites met**: All prerequisite stories for requested story are completed
|
||||
- [ ] **Business context sufficient**: Epic provides enough detail for comprehensive story definition
|
||||
|
||||
### Business Value Validation
|
||||
- [ ] **Value proposition clear**: Epic business value and ROI rationale are explicitly documented
|
||||
- [ ] **Priority alignment**: Epic aligns with current business priorities and strategic objectives
|
||||
- [ ] **Stakeholder alignment**: Key stakeholders have reviewed and approved epic scope
|
||||
- [ ] **Risk assessment complete**: Known risks and mitigation strategies are documented
|
||||
|
||||
## Validation Outcomes
|
||||
|
||||
### If ALL checks pass:
|
||||
- **Status**: Epic ready for story creation
|
||||
- **Action**: Proceed with create_story workflow step
|
||||
- **Documentation**: Update story file with epic validation timestamp and PO approval
|
||||
|
||||
### If ANY check fails:
|
||||
- **Status**: Epic not ready for story creation
|
||||
- **Action**: HALT workflow and address identified issues
|
||||
- **Escalation**: Work with SM and stakeholders to resolve epic readiness blockers
|
||||
- **Documentation**: Document specific issues and required remediation steps
|
||||
|
||||
## Notes
|
||||
|
||||
- This checklist must be completed before any story creation begins
|
||||
- Focus on business readiness rather than technical implementation details
|
||||
- Epic validation ensures stories are created from well-defined, approved business context
|
||||
- Failed validation prevents wasted effort on premature or poorly defined stories
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from**: Epic files, previous story status, business stakeholder feedback
|
||||
- **Output to**: create_story workflow step (if validation passes)
|
||||
- **Dependencies**: Epic documentation standards, story numbering conventions
|
||||
- **Escalation**: SM for process issues, architect for technical dependencies
|
||||
|
|
@ -1,136 +0,0 @@
|
|||
# Story Approval Checklist (Product Owner)
|
||||
|
||||
## Purpose
|
||||
|
||||
Product Owner validation checklist to approve stories for development. This checklist ensures the story delivers business value, aligns with epic goals, and is ready for the development team.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - STORY APPROVAL VALIDATION
|
||||
|
||||
This checklist is for PRODUCT OWNERS to validate stories created by Scrum Master before development begins.
|
||||
|
||||
VALIDATION FOCUS:
|
||||
1. Business value and alignment
|
||||
2. User need satisfaction
|
||||
3. Acceptance criteria accuracy
|
||||
4. Scope appropriateness
|
||||
5. Development readiness
|
||||
|
||||
EXECUTION APPROACH:
|
||||
1. Review the story in context of its parent epic
|
||||
2. Validate from user/business perspective (not technical)
|
||||
3. Focus on "will this deliver the intended value?"
|
||||
4. Consider if this is the right story at the right time
|
||||
5. Ensure development team has clear success criteria
|
||||
|
||||
APPROVAL DECISION:
|
||||
- APPROVED: Story ready for development
|
||||
- CONDITIONAL: Minor changes needed before approval
|
||||
- REJECTED: Significant revision required]]
|
||||
|
||||
## Validation Criteria
|
||||
|
||||
### 1. BUSINESS VALUE ALIGNMENT
|
||||
|
||||
[[LLM: Verify the story actually solves a user problem and contributes to epic goals]]
|
||||
|
||||
- [ ] **User Story Clarity**: User story clearly articulates WHO, WHAT, and WHY
|
||||
- [ ] **Epic Alignment**: Story directly contributes to epic business objectives
|
||||
- [ ] **Value Proposition**: Clear business or user value from implementing this story
|
||||
- [ ] **User Need**: Addresses a real user need (not just technical convenience)
|
||||
|
||||
### 2. ACCEPTANCE CRITERIA VALIDATION
|
||||
|
||||
[[LLM: ACs must be testable and reflect actual business requirements, not just technical specs]]
|
||||
|
||||
- [ ] **Completeness**: ACs cover all essential functionality for the user story
|
||||
- [ ] **Business Accuracy**: ACs reflect actual business rules and user expectations
|
||||
- [ ] **Testability**: Each AC can be verified through user testing or business validation
|
||||
- [ ] **Clarity**: ACs are unambiguous and actionable for development team
|
||||
- [ ] **Measurability**: Success criteria are observable and measurable
|
||||
|
||||
### 3. SCOPE AND PRIORITY ASSESSMENT
|
||||
|
||||
[[LLM: Ensure story is right-sized and appropriately prioritized]]
|
||||
|
||||
- [ ] **Scope Appropriateness**: Story scope aligns with project phase and delivery boundaries
|
||||
- [ ] **Deliverable Size**: Story can be completed within project's standard delivery timeframe
|
||||
- [ ] **Priority Justification**: Story priority aligns with current project objectives and constraints
|
||||
- [ ] **Dependency Clarity**: Prerequisites and dependencies are clearly identified
|
||||
- [ ] **Risk Assessment**: Business risk of implementing/not implementing is understood
|
||||
|
||||
### 4. USER EXPERIENCE CONSIDERATION
|
||||
|
||||
[[LLM: From user perspective, does this story make sense and add value?]]
|
||||
|
||||
- [ ] **User Journey**: Story fits logically into user workflow and journey
|
||||
- [ ] **Usability**: Implementation will result in intuitive user experience
|
||||
- [ ] **Edge Cases**: Important user scenarios and edge cases are considered
|
||||
- [ ] **Error Handling**: User-facing error scenarios are addressed in ACs
|
||||
|
||||
### 5. DEVELOPMENT READINESS
|
||||
|
||||
[[LLM: Development team has what they need to succeed]]
|
||||
|
||||
- [ ] **Requirements Clarity**: Development team will understand what to build
|
||||
- [ ] **Success Definition**: Clear definition of "done" from business perspective
|
||||
- [ ] **Stakeholder Availability**: PO available for clarification during development
|
||||
- [ ] **Acceptance Process**: Process for validating completed story is defined
|
||||
|
||||
## APPROVAL DECISION
|
||||
|
||||
[[LLM: STORY APPROVAL SUMMARY
|
||||
|
||||
Based on checklist validation, provide:
|
||||
|
||||
1. Approval Decision
|
||||
- APPROVED: Ready for development
|
||||
- CONDITIONAL: Specific changes needed (list them)
|
||||
- REJECTED: Major revision required (explain why)
|
||||
|
||||
2. Business Confidence
|
||||
- High: Very confident this delivers intended value
|
||||
- Medium: Some concerns but workable
|
||||
- Low: Significant value or alignment concerns
|
||||
|
||||
3. Key Issues (if any)
|
||||
- List specific problems found
|
||||
- Suggest concrete improvements
|
||||
- Identify any business risks
|
||||
|
||||
4. Approval Actions
|
||||
- If APPROVED: Update story status to "Approved"
|
||||
- If CONDITIONAL: Document required changes
|
||||
- If REJECTED: Document revision requirements
|
||||
|
||||
5. Next Steps
|
||||
- For approved stories: Proceed to development
|
||||
- For conditional: Return to SM with change requests
|
||||
- For rejected: Return to epic planning for revision]]
|
||||
|
||||
| Category | Status | Comments |
|
||||
|----------|--------|----------|
|
||||
| 1. Business Value Alignment | _TBD_ | |
|
||||
| 2. Acceptance Criteria Validation | _TBD_ | |
|
||||
| 3. Scope and Priority Assessment | _TBD_ | |
|
||||
| 4. User Experience Consideration | _TBD_ | |
|
||||
| 5. Development Readiness | _TBD_ | |
|
||||
|
||||
### Final Decision
|
||||
|
||||
- [ ] **APPROVED**: Story is ready for development (update status to "Approved")
|
||||
- [ ] **CONDITIONAL**: Story needs specific changes before approval (document below)
|
||||
- [ ] **REJECTED**: Story requires significant revision (return to epic planning)
|
||||
|
||||
### Issues and Required Changes
|
||||
|
||||
(Document any specific issues found and changes needed)
|
||||
|
||||
### Business Risk Assessment
|
||||
|
||||
- **Implementation Risk**: _[High/Medium/Low]_
|
||||
- **User Impact**: _[High/Medium/Low]_
|
||||
- **Business Value Confidence**: _[High/Medium/Low]_
|
||||
|
||||
### Approval Notes
|
||||
|
||||
(Optional: Additional context for development team or future reference)
|
||||
|
|
@ -28,9 +28,7 @@ files:
|
|||
- update-epic-progress.md
|
||||
- epic-party-mode-retrospective.md
|
||||
|
||||
checklists:
|
||||
- story-approval-checklist.md
|
||||
- epic-readiness-checklist.md
|
||||
checklists: []
|
||||
|
||||
# Dependencies on core BMAD components
|
||||
dependencies:
|
||||
|
|
@ -51,6 +49,7 @@ dependencies:
|
|||
- architect-checklist.md
|
||||
- po-master-checklist.md
|
||||
- story-dod-checklist.md
|
||||
- pm-checklist.md
|
||||
core_templates:
|
||||
- story-tmpl.md
|
||||
|
||||
|
|
@ -74,7 +73,7 @@ post_install_message: |
|
|||
- Epic validation before story creation
|
||||
- Project-agnostic code generation and build tool integration
|
||||
- Round 1: Comprehensive reviews (Architecture, Business, Process, QA, UX)
|
||||
- Feedback consolidation with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification
|
||||
- Feedback consolidation with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT/SCOPE-CREEP classification
|
||||
- Round 2+: Efficient architect-only validation with browser MCP testing
|
||||
- Story status tracking throughout workflow (Draft → Approved → In Progress → Verified → Review → Done → Delivered)
|
||||
- Story-based documentation for evidence and tracking
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Product Owner validation and approval of story for development readiness. Valida
|
|||
- Understand the story's role within the epic objectives
|
||||
|
||||
### 2. Execute Story Approval Checklist
|
||||
- Use `story-approval-checklist.md` as validation framework
|
||||
- Use `pm-checklist.md` as validation framework (sections 4.3, 6.2, 8.2)
|
||||
- Systematically evaluate each checklist category:
|
||||
- Business Value Alignment
|
||||
- Acceptance Criteria Validation
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
# Consolidate Review Feedback
|
||||
|
||||
## Task Overview
|
||||
**Agent:** architect
|
||||
**Agent:** sm
|
||||
**Action Type:** feedback-consolidation
|
||||
**Duration:** 10-15 minutes
|
||||
**LLM-Optimized:** Token-efficient structured consolidation
|
||||
|
||||
## Purpose
|
||||
Consolidate feedback from all Round 1 reviews into prioritized action plan with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification for efficient implementation.
|
||||
Consolidate feedback from all Round 1 reviews into prioritized action plan with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT/SCOPE-CREEP classification for efficient implementation while maintaining story focus.
|
||||
|
||||
## Context
|
||||
Central coordination after 5 parallel Round 1 reviews:
|
||||
|
|
@ -36,6 +36,12 @@ Central coordination after 5 parallel Round 1 reviews:
|
|||
|
||||
### Step 1: Pre-Consolidation Analysis
|
||||
|
||||
**Original Story Analysis (CRITICAL FIRST STEP):**
|
||||
1. Read original user story and ALL acceptance criteria from story file
|
||||
2. Identify explicit requirements vs implicit assumptions
|
||||
3. Note any performance, testing, or quality requirements in original AC
|
||||
4. Establish baseline: "What was originally agreed as MVP scope?"
|
||||
|
||||
**Feedback Source Review:**
|
||||
- Architecture: Technical design and implementation issues
|
||||
- Business: Requirements and value delivery gaps
|
||||
|
|
@ -47,6 +53,8 @@ Central coordination after 5 parallel Round 1 reviews:
|
|||
```
|
||||
FEEDBACK_ANALYSIS:
|
||||
- Total items: [count]
|
||||
- Original AC items: [count]
|
||||
- Scope expansion items: [count]
|
||||
- Overlapping issues: [count]
|
||||
- Conflicts identified: [count]
|
||||
- Implementation effort: [HIGH/MEDIUM/LOW]
|
||||
|
|
@ -54,6 +62,16 @@ FEEDBACK_ANALYSIS:
|
|||
|
||||
### Step 2: Priority Classification
|
||||
|
||||
**SCOPE-CREEP DETECTION (Scrum Master Responsibility):**
|
||||
Before classification, compare ALL feedback against original story acceptance criteria:
|
||||
- Read original user story and acceptance criteria from story file
|
||||
- Compare each suggestion against original requirements
|
||||
- Flag anything NOT explicitly required by acceptance criteria
|
||||
- Identify tests/standards beyond project minimums
|
||||
- Mark nice-to-have additions that expand scope
|
||||
- Apply "strict AC compliance" - if not in original AC = potential scope creep
|
||||
- Consult architect for complex technical feasibility questions if needed
|
||||
|
||||
**REQUIRED-FOR-COMPLETION** (Blocks story completion):
|
||||
- Acceptance criteria gaps
|
||||
- Critical functionality breaks
|
||||
|
|
@ -77,6 +95,15 @@ FEEDBACK_ANALYSIS:
|
|||
- Documentation enhancements
|
||||
- Process improvements
|
||||
|
||||
**SCOPE-CREEP** (Outside original story scope - IGNORE):
|
||||
- Features not in original acceptance criteria
|
||||
- Tests beyond project minimum standards (unless AC specifies performance requirements)
|
||||
- Functionality belonging to future stories
|
||||
- Nice-to-have additions not in user story
|
||||
- Optimizations not needed for story completion
|
||||
- Requirements that expand original scope beyond MVP intent
|
||||
- "Should also do X" suggestions where X is not in AC
|
||||
|
||||
**Classification Format (Max 50 tokens/item):**
|
||||
```
|
||||
[PRIORITY]: [Issue] - [Domain] - [Effort: S/M/L] - [Impact: H/M/L]
|
||||
|
|
@ -87,14 +114,16 @@ FEEDBACK_ANALYSIS:
|
|||
- Technical vs Business conflicts → Acceptance criteria priority
|
||||
- Similar issues → Consolidate into single action
|
||||
- Priority disputes → Story completion impact assessment
|
||||
- Reviewer disagreements → Architecture principles guide
|
||||
- Reviewer disagreements → Consult with relevant expert (architect for technical, PO for business)
|
||||
- Complex technical conflicts → Escalate to architect consultation
|
||||
|
||||
### Step 4: Implementation Sequencing (3-4 minutes)
|
||||
**Sequencing Rules:**
|
||||
1. REQUIRED-FOR-COMPLETION (dependency order)
|
||||
2. QUALITY-STANDARD (grouped by domain)
|
||||
3. Dependencies: Backend → Frontend → Integration
|
||||
4. Validation checkpoints after major changes
|
||||
1. SCOPE-CREEP items → IGNORE (do not implement)
|
||||
2. REQUIRED-FOR-COMPLETION (dependency order)
|
||||
3. QUALITY-STANDARD (grouped by domain)
|
||||
4. Dependencies: Backend → Frontend → Integration
|
||||
5. Validation checkpoints after major changes
|
||||
|
||||
**Implementation Groups:**
|
||||
```
|
||||
|
|
@ -108,7 +137,7 @@ Update story file with:
|
|||
|
||||
```markdown
|
||||
## Review Consolidation Summary
|
||||
**Architect:** [Name] | **Date:** [YYYY-MM-DD] | **Duration:** [X minutes]
|
||||
**Scrum Master:** [Name] | **Date:** [YYYY-MM-DD] | **Duration:** [X minutes]
|
||||
|
||||
### Round 1 Review Results
|
||||
- Architecture: [PASS/ISSUES] ([X] items)
|
||||
|
|
@ -127,6 +156,9 @@ Update story file with:
|
|||
#### IMPROVEMENT ([X] items)
|
||||
- [Issue] - [Domain] - [Effort] - [Value] | Max 50 tokens
|
||||
|
||||
#### SCOPE-CREEP ([X] items - IGNORED)
|
||||
- [Issue] - [Domain] - [Reason: Outside AC/Future Story/Nice-to-have] | Max 50 tokens
|
||||
|
||||
### Implementation Sequence
|
||||
**Phase 1:** [Critical fixes] - Est: [time] - Items: [count]
|
||||
**Phase 2:** [Quality fixes] - Est: [time] - Items: [count]
|
||||
|
|
@ -143,8 +175,10 @@ Update story file with:
|
|||
|
||||
## Success Criteria
|
||||
- [ ] All 5 review streams analyzed and categorized
|
||||
- [ ] Conflicts resolved with clear rationale
|
||||
- [ ] Priority classification complete (3 categories)
|
||||
- [ ] Original acceptance criteria reviewed and compared against all feedback
|
||||
- [ ] Scope creep identified by Scrum Master and marked as IGNORE
|
||||
- [ ] Conflicts resolved with clear rationale (architect consulted for technical disputes)
|
||||
- [ ] Priority classification complete (4 categories)
|
||||
- [ ] Implementation sequence with time estimates
|
||||
- [ ] Story file updated with structured summary
|
||||
- [ ] Action items under 50 tokens each
|
||||
|
|
@ -186,4 +220,5 @@ If conflicts cannot be resolved:
|
|||
- **Input from:** Round 1 reviews (architect, po, sm, qa, ux-expert)
|
||||
- **Output to:** implement-consolidated-fixes task (dev agent)
|
||||
- **Dependencies:** All Round 1 review checklists must be complete
|
||||
- **Consultation:** Architect available for complex technical dispute resolution
|
||||
- **Validation:** Next phase will validate using story docs + Playwright MCP
|
||||
|
|
@ -119,7 +119,7 @@ workflow:
|
|||
action: execute-checklist
|
||||
inputs:
|
||||
- epic_number
|
||||
checklist: epic-readiness-checklist.md
|
||||
checklist: po-master-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Validate epic business readiness and dependencies before story creation"
|
||||
story_status_update: "N/A - No story exists yet"
|
||||
|
||||
|
|
@ -234,7 +234,7 @@ workflow:
|
|||
checklist_completion_tracking: true
|
||||
|
||||
- step: consolidate_feedback
|
||||
agent: architect
|
||||
agent: sm
|
||||
action: consolidate-review-feedback
|
||||
requires: [round1_architecture_review, round1_business_review, round1_process_review, round1_qa_review, round1_ux_review]
|
||||
inputs:
|
||||
|
|
@ -244,7 +244,7 @@ workflow:
|
|||
- process_feedback
|
||||
- qa_feedback
|
||||
- ux_feedback
|
||||
notes: "REQUIRED: Use Task tool for execution - Architect consolidates all review feedback with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification"
|
||||
notes: "REQUIRED: Use Task tool for execution - Scrum Master consolidates all review feedback with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT/SCOPE-CREEP classification. Compare ALL feedback against original acceptance criteria to identify scope creep."
|
||||
|
||||
- step: implement_fixes
|
||||
agent: dev
|
||||
|
|
@ -491,9 +491,7 @@ workflow:
|
|||
- create-comprehensive-pr
|
||||
- update-epic-progress
|
||||
- epic-party-mode-retrospective
|
||||
expansion_checklists:
|
||||
- story-approval-checklist.md
|
||||
- epic-readiness-checklist.md
|
||||
expansion_checklists: []
|
||||
|
||||
handoff_prompts:
|
||||
po_validate_epic: "Validate epic {epic_number} readiness for story creation - check approval status, dependencies, and business context"
|
||||
|
|
|
|||
Loading…
Reference in New Issue