feat: add epic retrospective task and template for QA analysis
- Introduced a new task for conducting comprehensive retrospectives on completed epics from a QA perspective. - Added a detailed template to guide the retrospective process, ensuring thorough analysis and actionable recommendations. - Updated the QA commands to include the new epic-retrospective task. - Added configuration options for enabling retrospectives in core-config.yml, including file location and patterns. - Updated the story creation process to incorporate insights from recent retrospectives, enhancing story quality and avoiding past issues. - Introduced a new "Retrospective Insights" section in the story template to document reviewed retrospectives and key insights applied.
This commit is contained in:
Davor Racic
parent
3e2e43dd88
commit
4c151a554b
|
|
@ -43,6 +43,7 @@ commands: # All commands require * prefix when used (e.g., *help)
|
|||
dependencies:
|
||||
tasks:
|
||||
- review-story
|
||||
- epic-retrospective
|
||||
data:
|
||||
- technical-preferences
|
||||
utils:
|
||||
|
|
|
|||
|
|
@ -11,6 +11,12 @@ architecture:
|
|||
architectureVersion: v4
|
||||
architectureSharded: true
|
||||
architectureShardedLocation: docs/architecture
|
||||
retrospectives:
|
||||
enabled: true
|
||||
retrospectiveLocation: docs/retrospectives
|
||||
retrospectiveFilePattern: qa-epic-retrospective-*.md
|
||||
depth: 3 # Number of recent retrospectives to consider
|
||||
maxDepth: 5 # Maximum allowed depth for safety
|
||||
customTechnicalDocuments: null
|
||||
devLoadAlwaysFiles:
|
||||
- docs/architecture/coding-standards.md
|
||||
|
|
|
|||
|
|
@ -113,11 +113,33 @@ To identify the next logical story based on project progress and epic definition
|
|||
- Any "lessons learned" or notes for future stories
|
||||
- Extract relevant insights that might inform the current story's preparation
|
||||
|
||||
### 4. Gather & Synthesize Architecture Context
|
||||
### 4. Review Recent Retrospectives for Lessons Learned
|
||||
|
||||
[[LLM: This step incorporates retrospective insights to improve story quality and avoid repeating past issues]]
|
||||
|
||||
- Check if retrospectives are enabled in core-config.yml (`retrospectives.enabled: true`)
|
||||
- **If retrospectives are enabled:**
|
||||
- Locate retrospective files in `retrospectiveLocation` using `retrospectiveFilePattern`
|
||||
- Identify the most recent `depth` number of retrospective files (default: 3)
|
||||
- If more than `maxDepth` retrospectives exist, limit to `maxDepth` for cognitive load management
|
||||
- Read each identified retrospective file and extract key insights relevant to story creation:
|
||||
- **Technical Issues to Avoid:** Recurring problems, anti-patterns, or architectural pitfalls
|
||||
- **Successful Practices:** Patterns, tools, or approaches that worked well
|
||||
- **Testing Gaps:** Areas where testing was insufficient or missed critical scenarios
|
||||
- **Architecture Patterns:** Component designs or integration approaches that proved effective
|
||||
- **Process Improvements:** Development workflow enhancements or team collaboration insights
|
||||
- **Quality Recommendations:** Specific QA guidance for similar story types
|
||||
- Synthesize insights into actionable guidance for the current story
|
||||
- Document which retrospectives were reviewed for traceability
|
||||
- **If retrospectives are disabled or no retrospective files exist:**
|
||||
- Skip this step and proceed to architecture context gathering
|
||||
- Note in story preparation that retrospective insights were not available
|
||||
|
||||
### 5. Gather & Synthesize Architecture Context
|
||||
|
||||
[[LLM: CRITICAL - You MUST gather technical details from the architecture documents. NEVER make up technical details not found in these documents.]]
|
||||
|
||||
#### 4.1 Determine Architecture Document Strategy
|
||||
#### 5.1 Determine Architecture Document Strategy
|
||||
|
||||
Based on configuration loaded in Step 0:
|
||||
|
||||
|
|
@ -134,7 +156,7 @@ Based on configuration loaded in Step 0:
|
|||
- If `architectureSharded: true`: Search sharded files by filename relevance
|
||||
- If `architectureSharded: false`: Search within monolithic `architectureFile` for relevant sections
|
||||
|
||||
#### 4.2 Recommended Reading Order Based on Story Type (v4 Sharded Only)
|
||||
#### 5.2 Recommended Reading Order Based on Story Type (v4 Sharded Only)
|
||||
|
||||
[[LLM: Use this structured approach ONLY for v4 sharded architecture. For other versions, use best judgment based on file names and content.]]
|
||||
|
||||
|
|
@ -162,7 +184,7 @@ Based on configuration loaded in Step 0:
|
|||
|
||||
- Read both Backend and Frontend sections above
|
||||
|
||||
#### 4.3 Extract Story-Specific Technical Details
|
||||
#### 5.3 Extract Story-Specific Technical Details
|
||||
|
||||
[[LLM: As you read each document, extract ONLY the information directly relevant to implementing the current story. Do NOT include general information unless it directly impacts the story implementation.]]
|
||||
|
||||
|
|
@ -175,19 +197,19 @@ For each relevant document, extract:
|
|||
- Testing requirements specific to the story's features
|
||||
- Security or performance considerations affecting the story
|
||||
|
||||
#### 4.4 Document Source References
|
||||
#### 5.4 Document Source References
|
||||
|
||||
[[LLM: ALWAYS cite the source document and section for each technical detail you include. This helps the dev agent verify information if needed.]]
|
||||
|
||||
Format references as: `[Source: architecture/{filename}.md#{section}]`
|
||||
|
||||
### 5. Verify Project Structure Alignment
|
||||
### 6. Verify Project Structure Alignment
|
||||
|
||||
- Cross-reference the story's requirements and anticipated file manipulations with the Project Structure Guide from `docs/architecture/unified-project-structure.md`.
|
||||
- Ensure any file paths, component locations, or module names implied by the story align with defined structures.
|
||||
- Document any structural conflicts, necessary clarifications, or undefined components/paths in a "Project Structure Notes" section within the story draft.
|
||||
|
||||
### 6. Populate Story Template with Full Context
|
||||
### 7. Populate Story Template with Full Context
|
||||
|
||||
- Create a new story file: `{devStoryLocation}/{epicNum}.{storyNum}.story.md` (using location from config).
|
||||
- Use the Story Template to structure the file.
|
||||
|
|
@ -196,6 +218,10 @@ Format references as: `[Source: architecture/{filename}.md#{section}]`
|
|||
- `Status: Draft`
|
||||
- `Story` (User Story statement from Epic)
|
||||
- `Acceptance Criteria (ACs)` (from Epic, to be refined if needed based on context)
|
||||
- **`Retrospective Insights` section:**
|
||||
- Populate the "Retrospectives Reviewed" subsection with the specific retrospective files that were analyzed
|
||||
- Fill the "Key Insights Applied" subsection with synthesized, actionable insights relevant to this story
|
||||
- If no retrospectives were available or enabled, use the template's default messaging
|
||||
- **`Dev Technical Guidance` section (CRITICAL):**
|
||||
|
||||
[[LLM: This section MUST contain ONLY information extracted from the architecture shards. NEVER invent or assume technical details.]]
|
||||
|
|
|
|||
|
|
@ -0,0 +1,188 @@
|
|||
# QA Epic Retrospective Task
|
||||
|
||||
## Purpose
|
||||
|
||||
Conduct a comprehensive retrospective analysis of completed epics from a quality assurance standpoint. This task focuses on evaluating the entire development and testing process to identify successes, failures, and areas for improvement in product quality and testing strategy. The resulting retrospective document serves as a learning tool to guide future development cycles and enhance overall quality processes.
|
||||
|
||||
## When to Use This Task
|
||||
|
||||
**Use this task when:**
|
||||
|
||||
- An epic has been completed and deployed
|
||||
- All associated stories have reached their Definition of Done
|
||||
- QA wants to capture lessons learned for process improvement
|
||||
- Team is ready to invest time in reflective analysis
|
||||
|
||||
**Use alternative retrospective approaches when:**
|
||||
|
||||
- Epic is still in progress (use review-story instead)
|
||||
- Immediate hotfixes are needed (focus on incident post-mortems)
|
||||
- Limited QA involvement in the epic (consider development-focused retrospectives)
|
||||
- Epic was abandoned or significantly changed mid-development
|
||||
|
||||
## Instructions
|
||||
|
||||
### 1. Data Collection and Preparation (Required)
|
||||
|
||||
Before beginning the analysis, gather all relevant documentation and data from the completed epic:
|
||||
|
||||
**Epic Documentation:**
|
||||
|
||||
- [ ] Completed epic document with original goals and scope
|
||||
- [ ] All story documents associated with the epic
|
||||
- [ ] Definition of Done criteria for each story
|
||||
- [ ] Acceptance criteria and business requirements
|
||||
|
||||
**Testing Documentation:**
|
||||
|
||||
- [ ] Test plans and test case documentation
|
||||
- [ ] Test execution reports and results
|
||||
- [ ] Bug reports filed during the epic development
|
||||
- [ ] Performance test results (if applicable)
|
||||
- [ ] User acceptance testing feedback
|
||||
|
||||
**Development Artifacts:**
|
||||
|
||||
- [ ] Git commit history for the epic's duration
|
||||
- [ ] Final codebase snapshot for the epic
|
||||
|
||||
### 2. Quality Analysis
|
||||
|
||||
Conduct a thorough analysis of the collected data from multiple QA perspectives:
|
||||
|
||||
#### Test Coverage and Effectiveness Analysis
|
||||
|
||||
**Test Plan Review:**
|
||||
|
||||
- [ ] Analyze test plan coverage against requirements
|
||||
- [ ] Identify gaps between planned and executed tests
|
||||
- [ ] Evaluate test case quality and completeness
|
||||
- [ ] Review automation vs manual testing balance
|
||||
|
||||
**Bug Analysis:**
|
||||
|
||||
- [ ] Categorize bugs by severity and type
|
||||
- [ ] Analyze bug introduction points in development cycle
|
||||
- [ ] Review bug fix effectiveness and regression occurrences
|
||||
- [ ] Identify patterns in bug types or areas
|
||||
|
||||
#### Documentation and Requirements Analysis
|
||||
|
||||
**Requirements Validation:**
|
||||
|
||||
- [ ] Verify final product meets acceptance criteria
|
||||
- [ ] Identify requirements that were unclear or changed
|
||||
- [ ] Assess story Definition of Done effectiveness
|
||||
- [ ] Review business value delivery against original goals
|
||||
|
||||
**Documentation Quality:**
|
||||
|
||||
- [ ] Evaluate test documentation completeness
|
||||
- [ ] Review user documentation accuracy
|
||||
- [ ] Assess technical documentation for QA processes
|
||||
|
||||
#### Codebase and Development Process Analysis
|
||||
|
||||
**Code Quality Review:**
|
||||
|
||||
- [ ] Analyze commit history for quality trends
|
||||
- [ ] Review code review effectiveness from QA perspective
|
||||
- [ ] Identify areas with high bug density
|
||||
- [ ] Assess testability of delivered code
|
||||
|
||||
**Process Effectiveness:**
|
||||
|
||||
- [ ] Evaluate QA involvement throughout development
|
||||
- [ ] Review testing environment stability and effectiveness
|
||||
- [ ] Analyze deployment and release process quality
|
||||
|
||||
### 3. Retrospective Document Generation
|
||||
|
||||
Use the epic-retrospective-tmpl.md template to create the comprehensive retrospective report:
|
||||
|
||||
#### What Went Well Section
|
||||
|
||||
Focus on QA successes and effective practices:
|
||||
|
||||
- **Testing Strategies:** Note effective testing approaches, tools, or methodologies
|
||||
- **Collaboration:** Highlight good communication between QA and development teams
|
||||
- **Quality Metrics:** Document areas with low bug counts or high test coverage
|
||||
- **Process Improvements:** Recognize successful process changes implemented during the epic
|
||||
|
||||
#### What Could Be Improved Section
|
||||
|
||||
Identify specific areas needing enhancement:
|
||||
|
||||
- **Test Coverage Gaps:** Document areas with insufficient testing
|
||||
- **Bug Prevention:** Identify recurring bug types or root causes
|
||||
- **Requirements Issues:** Note unclear acceptance criteria or changing requirements
|
||||
- **Environment Issues:** Document testing environment problems or limitations
|
||||
- **Communication:** Identify breakdowns in QA/Dev collaboration
|
||||
|
||||
#### Actionable Recommendations Section
|
||||
|
||||
Propose concrete, implementable improvements:
|
||||
|
||||
- **Process Changes:** Specific modifications to QA processes
|
||||
- **Tool Improvements:** New tools or better use of existing tools
|
||||
- **Training Needs:** Skills development for team members
|
||||
- **Documentation Updates:** Improvements to templates or standards
|
||||
- **Automation Opportunities:** Areas where manual testing could be automated
|
||||
|
||||
### 4. Validation and Review
|
||||
|
||||
Before finalizing the retrospective, ensure comprehensive coverage:
|
||||
|
||||
**Content Validation:**
|
||||
|
||||
- [ ] All major quality issues identified and analyzed
|
||||
- [ ] Recommendations are specific and actionable
|
||||
- [ ] Both positive and negative aspects are balanced
|
||||
- [ ] Data supports all conclusions and recommendations
|
||||
|
||||
**Stakeholder Review:**
|
||||
|
||||
- [ ] Development team feedback incorporated
|
||||
- [ ] Product Owner perspective considered
|
||||
- [ ] Scrum Master/Project Manager input included
|
||||
- [ ] Technical Architecture feedback if relevant
|
||||
|
||||
**Follow-up Planning:**
|
||||
|
||||
- [ ] Recommendations prioritized by impact and effort
|
||||
- [ ] Owners assigned for implementing recommendations
|
||||
- [ ] Timeline established for process improvements
|
||||
- [ ] Success metrics defined for recommended changes
|
||||
|
||||
## Output
|
||||
|
||||
A single markdown file named `qa-epic-retrospective-<epic_name>.md` saved in the `docs/retrospectives/` directory.
|
||||
|
||||
**File Structure Requirements:**
|
||||
|
||||
- Use the epic-retrospective-tmpl.md template
|
||||
- Include all sections with substantive content
|
||||
- Provide specific examples rather than generic statements
|
||||
- Include metrics and data where available
|
||||
- Ensure recommendations are actionable with clear next steps
|
||||
|
||||
## Success Criteria
|
||||
|
||||
The epic retrospective is successful when:
|
||||
|
||||
1. **Comprehensive Analysis:** All aspects of quality and testing are thoroughly reviewed
|
||||
2. **Data-Driven Insights:** Conclusions are supported by concrete evidence from the epic
|
||||
3. **Actionable Recommendations:** Proposed improvements are specific, measurable, and implementable
|
||||
4. **Process Learning:** Document provides clear guidance for future epic development
|
||||
5. **Stakeholder Value:** Insights are valuable to development team, product management, and QA processes
|
||||
6. **Continuous Improvement:** Recommendations address root causes, not just symptoms
|
||||
|
||||
## Important Notes
|
||||
|
||||
- **Timing Matters:** Conduct retrospectives while the epic experience is still fresh, but allow time for post-deployment observation
|
||||
- **Focus on Learning:** Emphasize learning and improvement over blame or criticism
|
||||
- **Data Over Opinion:** Base conclusions on concrete evidence from testing and development artifacts
|
||||
- **Actionable Outcomes:** Ensure every recommendation has a clear path to implementation
|
||||
- **Follow Through:** Plan to review retrospective recommendations in future epics to ensure continuous improvement
|
||||
|
||||
**Agent Responsibility:** The QA agent conducting this retrospective should maintain objectivity while advocating for quality improvements that benefit the entire development process.
|
||||
|
|
@ -0,0 +1,472 @@
|
|||
# Epic Retrospective: {{epic_name}}
|
||||
|
||||
[[LLM: The default path and filename unless specified is docs/retrospectives/qa-epic-retrospective-{{epic_name}}.md]]
|
||||
|
||||
[[LLM: This template guides comprehensive QA-focused retrospective analysis of completed epics. Before beginning:
|
||||
|
||||
1. **Verify Epic Completion**: Confirm the epic has been fully deployed and sufficient time has passed for real-world observation (recommended: 1-2 weeks post-deployment)
|
||||
|
||||
2. **REQUIRED INPUTS**: Ensure access to all necessary documentation and data:
|
||||
- Completed epic document with original goals and scope
|
||||
- All story documents with Definition of Done criteria
|
||||
- Test plans, test cases, and execution reports
|
||||
- Bug reports and issue tracking data
|
||||
- Git commit history for the epic duration
|
||||
- Final codebase snapshot
|
||||
- Performance metrics and monitoring data
|
||||
|
||||
3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the actual development and testing process. Every insight must be based on concrete evidence from the epic's execution, not assumptions.
|
||||
|
||||
4. **CONTINUOUS VALIDATION**: Throughout this process, validate your understanding with stakeholders. For every conclusion, confirm: "Based on my analysis of the epic data, I found [specific evidence] which indicates [conclusion]. Does this align with the team's experience?"
|
||||
|
||||
If any required inputs are missing, request them before proceeding.
|
||||
|
||||
After presenting this introduction, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
## Change Log
|
||||
|
||||
[[LLM: Track document versions and changes]]
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
[[LLM: Provide a comprehensive overview after completing all other sections. Include:
|
||||
|
||||
- Brief recap of epic goals and scope
|
||||
- Key quality metrics and outcomes
|
||||
- Primary successes and challenges identified
|
||||
- Strategic recommendations summary
|
||||
- Overall quality assessment
|
||||
|
||||
Write this section LAST after all analysis is complete.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
**Epic Overview:** {{epic_summary}}
|
||||
|
||||
**Quality Assessment:** {{overall_quality_rating}}
|
||||
|
||||
**Key Findings:**
|
||||
|
||||
- {{key_finding_1}}
|
||||
- {{key_finding_2}}
|
||||
- {{key_finding_3}}
|
||||
|
||||
**Strategic Impact:** {{impact_on_future_development}}
|
||||
|
||||
## 2. What Went Well
|
||||
|
||||
[[LLM: Conduct detailed analysis of successful practices and positive outcomes. Focus on evidence-based insights that can be replicated in future epics.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### BMAD Method Application
|
||||
|
||||
[[LLM: Analyze how BMAD methodology contributed to success]]
|
||||
|
||||
**Effective Practices:**
|
||||
|
||||
- {{bmad_practice_1}}
|
||||
- {{bmad_practice_2}}
|
||||
|
||||
**Methodology Adherence:** {{adherence_assessment}}
|
||||
|
||||
@{example: bmad_success}
|
||||
- Agent coordination worked exceptionally well for Story 2.3, with seamless handoff between Dev and QA agents
|
||||
- BMAD checklist caught 3 critical integration issues before they reached production
|
||||
- Template-driven development reduced story completion time by 40%
|
||||
@{/example}
|
||||
|
||||
### Code Quality & Refactoring
|
||||
|
||||
[[LLM: Document code quality achievements and successful refactoring efforts]]
|
||||
|
||||
**Quality Metrics Achieved:**
|
||||
|
||||
- **Test Coverage:** {{coverage_percentage}}% (Target: {{target_coverage}}%)
|
||||
- **Code Review Quality:** {{review_metrics}}
|
||||
- **Technical Debt Reduction:** {{debt_metrics}}
|
||||
|
||||
**Successful Refactoring Efforts:**
|
||||
|
||||
<<REPEAT: refactoring_success>>
|
||||
|
||||
- **{{refactoring_area}}:** {{description}} - {{impact_measurement}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
@{example: code_quality}
|
||||
- Achieved 94% test coverage across all new components (exceeded 80% target)
|
||||
- Zero critical code smells identified in SonarQube analysis
|
||||
- Successfully refactored authentication service, reducing complexity by 35%
|
||||
@{/example}
|
||||
|
||||
### Adaptive Development
|
||||
|
||||
[[LLM: Highlight successful adaptations and pivots during development]]
|
||||
|
||||
**Successful Adaptations:**
|
||||
|
||||
- {{adaptation_1}}
|
||||
- {{adaptation_2}}
|
||||
|
||||
**Change Management:** {{change_handling_assessment}}
|
||||
|
||||
### Tooling & Libraries
|
||||
|
||||
[[LLM: Document effective tool and library choices]]
|
||||
|
||||
**Effective Technology Choices:**
|
||||
|
||||
<<REPEAT: tool_success>>
|
||||
|
||||
- **{{tool_name}}:** {{usage_description}} - {{benefit_realized}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
**Integration Successes:** {{integration_assessment}}
|
||||
|
||||
## 3. What Could Be Improved
|
||||
|
||||
[[LLM: Conduct thorough analysis of areas needing improvement. Focus on specific, actionable insights with clear evidence.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### API Contracts
|
||||
|
||||
[[LLM: Analyze API design and contract issues encountered]]
|
||||
|
||||
**Contract Issues Identified:**
|
||||
|
||||
<<REPEAT: api_issue>>
|
||||
|
||||
- **{{api_endpoint}}:** {{issue_description}} - {{impact_assessment}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
**Integration Challenges:** {{integration_challenges}}
|
||||
|
||||
@{example: api_issues}
|
||||
- User profile endpoint returned inconsistent data types (string vs number for user_id)
|
||||
- Missing error codes for edge cases caused unclear error handling in frontend
|
||||
- API versioning strategy unclear, leading to breaking changes in Story 3.2
|
||||
@{/example}
|
||||
|
||||
### Code Architecture & Design
|
||||
|
||||
[[LLM: Identify architectural and design issues]]
|
||||
|
||||
**Architectural Concerns:**
|
||||
|
||||
- {{arch_concern_1}}
|
||||
- {{arch_concern_2}}
|
||||
|
||||
**Design Pattern Issues:** {{design_pattern_assessment}}
|
||||
|
||||
**Technical Debt Accumulated:** {{tech_debt_assessment}}
|
||||
|
||||
### Code Repetition
|
||||
|
||||
[[LLM: Document instances of code duplication and missed abstraction opportunities]]
|
||||
|
||||
**Repetition Patterns Identified:**
|
||||
|
||||
<<REPEAT: repetition_issue>>
|
||||
|
||||
- **{{code_area}}:** {{repetition_description}} - {{refactoring_opportunity}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
**Missed Abstraction Opportunities:** {{abstraction_opportunities}}
|
||||
|
||||
### Testing
|
||||
|
||||
[[LLM: Analyze testing gaps and issues comprehensively]]
|
||||
|
||||
**Test Coverage Gaps:**
|
||||
|
||||
- **Unit Tests:** {{unit_test_gaps}}
|
||||
- **Integration Tests:** {{integration_test_gaps}}
|
||||
- **E2E Tests:** {{e2e_test_gaps}}
|
||||
|
||||
**Test Quality Issues:**
|
||||
|
||||
<<REPEAT: test_issue>>
|
||||
|
||||
- **{{test_area}}:** {{issue_description}} - {{improvement_needed}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
**Testing Process Issues:** {{process_issues}}
|
||||
|
||||
@{example: testing_issues}
|
||||
- Payment flow integration tests failed to cover error scenarios (API timeout, network issues)
|
||||
- Unit tests for utility functions had hardcoded values instead of parameterized tests
|
||||
- E2E tests were flaky due to timing issues, causing false failures in CI pipeline
|
||||
@{/example}
|
||||
|
||||
### Process & Story Management
|
||||
|
||||
[[LLM: Evaluate story management and development process issues]]
|
||||
|
||||
**Story Definition Issues:**
|
||||
|
||||
- {{story_issue_1}}
|
||||
- {{story_issue_2}}
|
||||
|
||||
**Definition of Done Gaps:** {{dod_assessment}}
|
||||
|
||||
**Communication Breakdowns:** {{communication_issues}}
|
||||
|
||||
**Handoff Problems:** {{handoff_assessment}}
|
||||
|
||||
### Estimations
|
||||
|
||||
[[LLM: Analyze estimation accuracy and planning issues]]
|
||||
|
||||
**Estimation Accuracy:**
|
||||
|
||||
| Story | Estimated Effort | Actual Effort | Variance | Factors |
|
||||
| :---- | :-------------- | :------------ | :------- | :------ |
|
||||
| {{story_id}} | {{estimate}} | {{actual}} | {{variance}} | {{factors}} |
|
||||
|
||||
**Planning Issues Identified:**
|
||||
|
||||
- {{planning_issue_1}}
|
||||
- {{planning_issue_2}}
|
||||
|
||||
**Scope Creep Instances:** {{scope_creep_assessment}}
|
||||
|
||||
## 4. Key Insights
|
||||
|
||||
[[LLM: Synthesize broader takeaways and learnings from the epic development process. Focus on insights that provide strategic value for future development.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
**Development Process Insights:**
|
||||
|
||||
<<REPEAT: process_insight>>
|
||||
|
||||
- **{{insight_area}}:** {{insight_description}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
**Quality Assurance Insights:**
|
||||
|
||||
- {{qa_insight_1}}
|
||||
- {{qa_insight_2}}
|
||||
|
||||
**Team Collaboration Insights:**
|
||||
|
||||
- {{collaboration_insight_1}}
|
||||
- {{collaboration_insight_2}}
|
||||
|
||||
**Technology and Architecture Insights:**
|
||||
|
||||
- {{tech_insight_1}}
|
||||
- {{tech_insight_2}}
|
||||
|
||||
@{example: insights}
|
||||
- Early involvement of QA in story refinement reduced defect discovery time by 60%
|
||||
- Automated testing infrastructure investment in Epic 1 paid dividends throughout the project
|
||||
- Cross-functional story reviews identified integration issues before development began
|
||||
@{/example}
|
||||
|
||||
## 5. Actionable Recommendations
|
||||
|
||||
[[LLM: Provide specific, prioritized recommendations that can be implemented in future epics. Each recommendation should include implementation guidance and success metrics.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Process & Planning
|
||||
|
||||
[[LLM: Recommendations for improving development and planning processes]]
|
||||
|
||||
**High Priority:**
|
||||
|
||||
<<REPEAT: process_recommendation>>
|
||||
|
||||
1. **{{recommendation_title}}**
|
||||
- **Issue Addressed:** {{issue_reference}}
|
||||
- **Implementation:** {{specific_steps}}
|
||||
- **Success Metric:** {{measurement_criteria}}
|
||||
- **Timeline:** {{implementation_timeframe}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
**Medium Priority:**
|
||||
|
||||
- {{medium_priority_recommendation}}
|
||||
|
||||
**Low Priority:**
|
||||
|
||||
- {{low_priority_recommendation}}
|
||||
|
||||
### Development & DX
|
||||
|
||||
[[LLM: Recommendations for improving developer experience and development practices]]
|
||||
|
||||
**Immediate Actions:**
|
||||
|
||||
<<REPEAT: dev_recommendation>>
|
||||
|
||||
- **{{dev_improvement}}:** {{implementation_approach}} - {{expected_benefit}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
**Tool and Process Improvements:**
|
||||
|
||||
- {{tool_improvement_1}}
|
||||
- {{tool_improvement_2}}
|
||||
|
||||
@{example: dev_recommendations}
|
||||
- Implement pre-commit hooks for code formatting and linting (reduce review time by 30%)
|
||||
- Create shared component library to reduce code duplication (target: 50% reduction in UI code)
|
||||
- Establish API contract testing to catch breaking changes early (prevent integration delays)
|
||||
@{/example}
|
||||
|
||||
### Architecture & Patterns
|
||||
|
||||
[[LLM: Recommendations for architectural improvements]]
|
||||
|
||||
**Architectural Improvements:**
|
||||
|
||||
<<REPEAT: arch_recommendation>>
|
||||
|
||||
- **{{architecture_area}}:** {{improvement_description}} - {{implementation_strategy}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
**Pattern Standardization:**
|
||||
|
||||
- {{pattern_standardization_1}}
|
||||
- {{pattern_standardization_2}}
|
||||
|
||||
### Future Tooling
|
||||
|
||||
[[LLM: Recommendations for new tools and technology adoption]]
|
||||
|
||||
**Tool Evaluation Needed:**
|
||||
|
||||
<<REPEAT: tool_evaluation>>
|
||||
|
||||
- **{{tool_category}}:** {{tool_options}} - {{evaluation_criteria}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
**Technology Upgrades:**
|
||||
|
||||
- {{upgrade_recommendation_1}}
|
||||
- {{upgrade_recommendation_2}}
|
||||
|
||||
## 6. Metrics and Evidence
|
||||
|
||||
[[LLM: Provide concrete metrics and evidence supporting the retrospective analysis]]
|
||||
|
||||
### Quality Metrics
|
||||
|
||||
| Metric | Target | Achieved | Status |
|
||||
| :----- | :----- | :------- | :----- |
|
||||
| Test Coverage | {{target_coverage}}% | {{actual_coverage}}% | {{status}} |
|
||||
| Bug Density | {{target_bugs}}/KLOC | {{actual_bugs}}/KLOC | {{status}} |
|
||||
| Code Review Time | {{target_review_time}} | {{actual_review_time}} | {{status}} |
|
||||
| Story Completion Rate | {{target_completion}}% | {{actual_completion}}% | {{status}} |
|
||||
|
||||
### Development Velocity
|
||||
|
||||
**Story Completion Metrics:**
|
||||
|
||||
- **Planned Stories:** {{planned_stories}}
|
||||
- **Completed Stories:** {{completed_stories}}
|
||||
- **Average Story Cycle Time:** {{avg_cycle_time}}
|
||||
- **Velocity Trend:** {{velocity_assessment}}
|
||||
|
||||
### Issue Tracking
|
||||
|
||||
**Bug Analysis:**
|
||||
|
||||
- **Total Bugs Found:** {{total_bugs}}
|
||||
- **Severity Distribution:** {{severity_breakdown}}
|
||||
- **Resolution Time:** {{avg_resolution_time}}
|
||||
- **Escaped Defects:** {{escaped_defects}}
|
||||
|
||||
## 7. Follow-up Actions
|
||||
|
||||
[[LLM: Define specific next steps and ownership for implementing recommendations]]
|
||||
|
||||
### Immediate Actions (Next Sprint)
|
||||
|
||||
<<REPEAT: immediate_action>>
|
||||
|
||||
- [ ] **{{action_item}}**
|
||||
- **Owner:** {{responsible_person}}
|
||||
- **Due Date:** {{due_date}}
|
||||
- **Success Criteria:** {{completion_criteria}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
### Short-term Actions (Next Epic)
|
||||
|
||||
<<REPEAT: short_term_action>>
|
||||
|
||||
- [ ] **{{action_item}}**
|
||||
- **Owner:** {{responsible_person}}
|
||||
- **Timeline:** {{timeline}}
|
||||
- **Dependencies:** {{dependencies}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
### Long-term Improvements
|
||||
|
||||
- {{long_term_improvement_1}}
|
||||
- {{long_term_improvement_2}}
|
||||
|
||||
## 8. Retrospective Validation
|
||||
|
||||
[[LLM: Include validation steps to ensure retrospective accuracy and completeness]]
|
||||
|
||||
### Stakeholder Review Checklist
|
||||
|
||||
- [ ] Development team feedback incorporated
|
||||
- [ ] Product Owner perspective included
|
||||
- [ ] Scrum Master/Project Manager input gathered
|
||||
- [ ] Technical Architecture review completed
|
||||
- [ ] All major quality issues documented
|
||||
|
||||
### Evidence Validation
|
||||
|
||||
- [ ] All conclusions supported by concrete data
|
||||
- [ ] Metrics verified against actual project artifacts
|
||||
- [ ] Recommendations linked to specific identified issues
|
||||
- [ ] Success stories documented with measurable outcomes
|
||||
|
||||
### Next Retrospective Planning
|
||||
|
||||
**Recommended Timeline:** {{next_retrospective_timeline}}
|
||||
|
||||
**Focus Areas for Next Review:**
|
||||
|
||||
- {{focus_area_1}}
|
||||
- {{focus_area_2}}
|
||||
|
||||
**Monitoring Requirements:** {{monitoring_setup}}
|
||||
|
||||
---
|
||||
|
||||
[[LLM: After completing the document, offer advanced elicitation with these custom options for epic retrospectives:
|
||||
|
||||
**Epic Retrospective Elicitation Actions**
|
||||
0. Deep dive into a specific quality issue or success pattern
|
||||
1. Expand analysis of development velocity and story completion
|
||||
2. Analyze cross-epic patterns and trends
|
||||
3. Stress test recommendations for feasibility
|
||||
4. Generate specific improvement implementation plans
|
||||
5. Compare this epic's outcomes to previous epics
|
||||
6. Explore team collaboration and communication patterns
|
||||
7. Validate recommendations with stakeholder feedback
|
||||
8. If only we had known about [issue/pattern] earlier...
|
||||
9. Finalize retrospective document
|
||||
|
||||
These replace the standard elicitation options when working on epic retrospective documents.]]
|
||||
|
|
@ -38,6 +38,46 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
|
|||
|
||||
{{ f.e. `- dev will create a script with task 3 above that you can run with "npm run test-initiate-launch-sequence" and validate Armageddon is initiated`}}
|
||||
|
||||
## Retrospective Insights
|
||||
|
||||
[[LLM: This section is populated during story creation if retrospectives are enabled in core-config.yml. Include key learnings from recent retrospectives that are relevant to this story.]]
|
||||
|
||||
### Retrospectives Reviewed
|
||||
|
||||
[[LLM: List which retrospective files were reviewed, if any]]
|
||||
|
||||
{{#if retrospectives_reviewed}}
|
||||
- {{retrospective_file_1}} ({{retrospective_date_1}})
|
||||
- {{retrospective_file_2}} ({{retrospective_date_2}})
|
||||
- {{retrospective_file_3}} ({{retrospective_date_3}})
|
||||
{{else}}
|
||||
No retrospectives available or retrospectives disabled in configuration.
|
||||
{{/if}}
|
||||
|
||||
### Key Insights Applied
|
||||
|
||||
[[LLM: Synthesize actionable insights from retrospectives that are relevant to this story type/domain]]
|
||||
|
||||
{{#if retrospective_insights}}
|
||||
**Technical Patterns to Follow:**
|
||||
- {{successful_pattern_1}}
|
||||
- {{successful_pattern_2}}
|
||||
|
||||
**Issues to Avoid:**
|
||||
- {{recurring_issue_1}}
|
||||
- {{recurring_issue_2}}
|
||||
|
||||
**Testing Considerations:**
|
||||
- {{testing_insight_1}}
|
||||
- {{testing_insight_2}}
|
||||
|
||||
**Process Improvements:**
|
||||
- {{process_improvement_1}}
|
||||
- {{process_improvement_2}}
|
||||
{{else}}
|
||||
No specific insights identified from retrospectives for this story type.
|
||||
{{/if}}
|
||||
|
||||
## Dev Agent Record
|
||||
|
||||
### Agent Model Used: {{Agent Model Name/Version}}
|
||||
|
|
|
|||
|
|
@ -1160,6 +1160,13 @@ coreProjectLocation:
|
|||
|
||||
customTechnicalDocuments: null # Additional docs for SM
|
||||
|
||||
retrospectives: # Retrospective integration settings
|
||||
enabled: true # Enable retrospective insights in story creation
|
||||
retrospectiveLocation: docs/retrospectives # Where retrospective files are stored
|
||||
retrospectiveFilePattern: qa-epic-retrospective-*.md # Pattern for retrospective files
|
||||
depth: 3 # Number of recent retrospectives to consider (default: 3)
|
||||
maxDepth: 5 # Maximum allowed depth for safety
|
||||
|
||||
devLoadAlwaysFiles: # Files dev agent always loads
|
||||
- docs/architecture/coding-standards.md
|
||||
- docs/architecture/tech-stack.md
|
||||
|
|
@ -1245,6 +1252,77 @@ devLoadAlwaysFiles:
|
|||
|
||||
This ensures the dev agent always has critical context without needing to search for it.
|
||||
|
||||
##### Retrospective Configuration
|
||||
|
||||
BMAD V4 introduces intelligent retrospective integration that helps teams learn from past epics and apply those insights to new story creation:
|
||||
|
||||
```yaml
|
||||
retrospectives:
|
||||
enabled: true # Enable/disable retrospective integration
|
||||
retrospectiveLocation: docs/retrospectives # Where retrospective files are stored
|
||||
retrospectiveFilePattern: qa-epic-retrospective-*.md # Pattern for retrospective files
|
||||
depth: 3 # Number of recent retrospectives to consider
|
||||
maxDepth: 5 # Maximum allowed depth for safety
|
||||
```
|
||||
|
||||
**Configuration Options:**
|
||||
|
||||
- **enabled**: `true/false` - Controls whether the Scrum Master agent incorporates retrospective insights when creating stories
|
||||
- **retrospectiveLocation**: Directory path where retrospective files are stored
|
||||
- **retrospectiveFilePattern**: Glob pattern to identify retrospective files (supports wildcards)
|
||||
- **depth**: Number of recent retrospectives to analyze (default: 3, based on agile best practices)
|
||||
- **maxDepth**: Safety limit to prevent cognitive overload (recommended: 5)
|
||||
|
||||
**How It Works:**
|
||||
|
||||
When creating new stories, the Scrum Master agent will:
|
||||
|
||||
1. Check if retrospectives are enabled
|
||||
2. Locate the most recent `depth` number of retrospective files
|
||||
3. Extract key insights relevant to the story being created:
|
||||
- Technical patterns that worked well
|
||||
- Common issues to avoid
|
||||
- Testing gaps to address
|
||||
- Process improvements to apply
|
||||
4. Include these insights in the story's "Retrospective Insights" section
|
||||
|
||||
**Recommended Depth Settings:**
|
||||
|
||||
- **New projects**: `depth: 1` (latest retrospective only)
|
||||
- **Mature projects**: `depth: 3-4` (pattern recognition across multiple epics)
|
||||
- **Large teams**: `depth: 2-3` (manage cognitive load)
|
||||
- **Small teams**: `depth: 4-5` (can handle more historical context)
|
||||
|
||||
**Example Configurations:**
|
||||
|
||||
_Minimal Configuration (new projects):_
|
||||
|
||||
```yaml
|
||||
retrospectives:
|
||||
enabled: true
|
||||
retrospectiveLocation: docs/retrospectives
|
||||
retrospectiveFilePattern: retrospective-*.md
|
||||
depth: 1
|
||||
```
|
||||
|
||||
_Comprehensive Configuration (mature projects):_
|
||||
|
||||
```yaml
|
||||
retrospectives:
|
||||
enabled: true
|
||||
retrospectiveLocation: docs/qa/retrospectives
|
||||
retrospectiveFilePattern: epic-retro-*.md
|
||||
depth: 4
|
||||
maxDepth: 6
|
||||
```
|
||||
|
||||
_Disabled (existing projects):_
|
||||
|
||||
```yaml
|
||||
retrospectives:
|
||||
enabled: false
|
||||
```
|
||||
|
||||
##### Debug and Export Options
|
||||
|
||||
**Debug Log:**
|
||||
|
|
|
|||
Loading…
Reference in New Issue