237 lines
8.7 KiB
Markdown
237 lines
8.7 KiB
Markdown
# Story Draft Validation Checklist
|
|
|
|
## Purpose
|
|
Comprehensive validation framework for Product Owners and Scrum Masters to ensure each user story contains sufficient context, clarity, and guidance for successful implementation by development teams, including AI agents.
|
|
|
|
## Required Artifacts
|
|
Before proceeding, ensure access to:
|
|
- ✅ Story document being validated
|
|
- ✅ Parent epic context and goals
|
|
- ✅ Referenced architecture and design documents
|
|
- ✅ Previous related stories if applicable
|
|
- ✅ Technical constraints and standards
|
|
|
|
## Validation Principles
|
|
1. **Clarity**: Developers understand WHAT to build without ambiguity
|
|
2. **Context**: WHY this is being built and how it fits the bigger picture
|
|
3. **Guidance**: Key technical decisions and implementation patterns provided
|
|
4. **Testability**: Clear criteria for verifying implementation success
|
|
5. **Self-Containment**: Most necessary information included in the story
|
|
|
|
---
|
|
|
|
## 1. Goal & Context Clarity
|
|
|
|
### Story Purpose Definition
|
|
- [ ] Story goal and objective clearly stated
|
|
- [ ] User value and business benefit explicitly described
|
|
- [ ] Acceptance criteria specific and measurable
|
|
- [ ] Success outcome defined in concrete terms
|
|
- [ ] Story scope boundaries clearly established
|
|
|
|
### Epic & System Integration
|
|
- [ ] Relationship to parent epic goals clearly explained
|
|
- [ ] Integration with overall system architecture described
|
|
- [ ] Dependencies on previous stories identified and documented
|
|
- [ ] Impact on downstream stories or features considered
|
|
- [ ] Business context and strategic value articulated
|
|
|
|
### User-Focused Perspective
|
|
- [ ] Story written from user's perspective (As a [user], I want [goal] so that [benefit])
|
|
- [ ] User scenarios and use cases clearly described
|
|
- [ ] User journey step this story addresses identified
|
|
- [ ] Expected user behavior and interactions specified
|
|
- [ ] Error conditions and edge cases from user perspective considered
|
|
|
|
**Context Assessment**: {{context_clarity_notes}}
|
|
|
|
---
|
|
|
|
## 2. Technical Implementation Guidance
|
|
|
|
### Implementation Direction
|
|
- [ ] Key files, components, or modules to create/modify identified
|
|
- [ ] Technology stack choices specified where non-standard
|
|
- [ ] Integration points with existing codebase clearly described
|
|
- [ ] Required APIs, services, or external systems identified
|
|
- [ ] Database schema changes or data model updates specified
|
|
|
|
### Technical Specifications
|
|
- [ ] Critical API endpoints and contracts defined
|
|
- [ ] Data structures and models clearly specified
|
|
- [ ] Required environment variables or configuration documented
|
|
- [ ] Security considerations and requirements outlined
|
|
- [ ] Performance requirements and constraints specified
|
|
|
|
### Architecture Alignment
|
|
- [ ] Adherence to established coding standards confirmed
|
|
- [ ] Consistency with project architecture patterns verified
|
|
- [ ] Exceptions to standard patterns clearly justified
|
|
- [ ] Code organization and file structure guidance provided
|
|
- [ ] Naming conventions and style requirements specified
|
|
|
|
**Technical Guidance Assessment**: {{technical_guidance_notes}}
|
|
|
|
---
|
|
|
|
## 3. Reference Effectiveness & Documentation
|
|
|
|
### Reference Quality
|
|
- [ ] External document references point to specific, relevant sections
|
|
- [ ] Reference relevance and purpose clearly explained
|
|
- [ ] Critical information summarized within story (not just referenced)
|
|
- [ ] Reference accessibility and availability verified
|
|
- [ ] Reference format consistency maintained
|
|
|
|
### Context Sufficiency
|
|
- [ ] Previous story context summarized when needed
|
|
- [ ] Domain-specific terminology explained or defined
|
|
- [ ] Assumptions made explicit rather than implied
|
|
- [ ] Background information sufficient for implementation
|
|
- [ ] Related work and dependencies clearly documented
|
|
|
|
### Documentation Standards
|
|
- [ ] Story follows consistent format and structure
|
|
- [ ] Language clear, concise, and jargon-free
|
|
- [ ] Visual aids (diagrams, mockups) included where helpful
|
|
- [ ] Code examples provided for complex requirements
|
|
- [ ] Implementation examples from similar features referenced
|
|
|
|
**Documentation Quality**: {{documentation_assessment_notes}}
|
|
|
|
---
|
|
|
|
## 4. Self-Containment & Completeness
|
|
|
|
### Information Completeness
|
|
- [ ] Core requirements contained within story (minimal external dependency)
|
|
- [ ] Implementation approach guidance self-contained
|
|
- [ ] Business rules and logic clearly specified
|
|
- [ ] Data validation and processing requirements detailed
|
|
- [ ] Error handling and exception scenarios covered
|
|
|
|
### Context Independence
|
|
- [ ] Story comprehensible without reading extensive external documentation
|
|
- [ ] Key decisions and rationale included in story
|
|
- [ ] Necessary background information provided
|
|
- [ ] Domain knowledge requirements minimized or explained
|
|
- [ ] Implementation can proceed with story as primary reference
|
|
|
|
### Edge Case Coverage
|
|
- [ ] Error conditions and failure scenarios identified
|
|
- [ ] Boundary conditions and limits specified
|
|
- [ ] Unexpected input handling requirements defined
|
|
- [ ] Fallback behaviors and recovery procedures outlined
|
|
- [ ] Performance edge cases and constraints considered
|
|
|
|
**Self-Containment Assessment**: {{self_containment_notes}}
|
|
|
|
---
|
|
|
|
## 5. Testing & Validation Guidance
|
|
|
|
### Testing Strategy
|
|
- [ ] Required testing approach specified (unit, integration, E2E)
|
|
- [ ] Key test scenarios and use cases identified
|
|
- [ ] Test data requirements and setup procedures documented
|
|
- [ ] Mock services or test doubles requirements specified
|
|
- [ ] Performance testing requirements outlined where applicable
|
|
|
|
### Success Criteria Definition
|
|
- [ ] Acceptance criteria written in testable format
|
|
- [ ] Success metrics and measurement methods defined
|
|
- [ ] Verification procedures clearly outlined
|
|
- [ ] Demo scenarios for stakeholder validation provided
|
|
- [ ] Regression testing considerations addressed
|
|
|
|
### Quality Assurance
|
|
- [ ] Code quality standards and review requirements specified
|
|
- [ ] Security testing considerations outlined
|
|
- [ ] Accessibility testing requirements documented
|
|
- [ ] Browser/platform compatibility testing specified
|
|
- [ ] User experience validation criteria established
|
|
|
|
**Testing Guidance Assessment**: {{testing_guidance_notes}}
|
|
|
|
---
|
|
|
|
## 6. Implementation Feasibility
|
|
|
|
### Technical Feasibility
|
|
- [ ] Implementation approach technically sound and achievable
|
|
- [ ] Required resources and skills available within team
|
|
- [ ] Timeline estimates realistic for story complexity
|
|
- [ ] Technical risks identified with mitigation strategies
|
|
- [ ] Dependencies on external systems or services manageable
|
|
|
|
### Story Sizing & Scope
|
|
- [ ] Story appropriately sized for single sprint completion
|
|
- [ ] Complexity level matches team capacity
|
|
- [ ] Story can be implemented independently
|
|
- [ ] Scope creep risks minimized through clear boundaries
|
|
- [ ] Story breakdown appropriate for incremental development
|
|
|
|
### Resource Requirements
|
|
- [ ] Development effort estimation provided
|
|
- [ ] Special tools or environment requirements identified
|
|
- [ ] Third-party service or API requirements documented
|
|
- [ ] Training or knowledge transfer needs considered
|
|
- [ ] Review and approval processes defined
|
|
|
|
**Feasibility Assessment**: {{feasibility_notes}}
|
|
|
|
---
|
|
|
|
## Final Validation Summary
|
|
|
|
### Overall Assessment
|
|
**Story Readiness Level**: {{readiness_level}} (Ready/Nearly Ready/Needs Revision/Blocked)
|
|
**Clarity Score**: {{clarity_score}}/10
|
|
**Implementation Risk**: {{implementation_risk}} (Low/Medium/High)
|
|
|
|
### Category Status Summary
|
|
| Category | Status | Critical Issues |
|
|
|----------|--------|----------------|
|
|
| Goal & Context Clarity | {{context_status}} | {{context_issues}} |
|
|
| Technical Implementation Guidance | {{technical_status}} | {{technical_issues}} |
|
|
| Reference Effectiveness | {{reference_status}} | {{reference_issues}} |
|
|
| Self-Containment | {{containment_status}} | {{containment_issues}} |
|
|
| Testing Guidance | {{testing_status}} | {{testing_issues}} |
|
|
| Implementation Feasibility | {{feasibility_status}} | {{feasibility_issues}} |
|
|
|
|
### Critical Issues Identified
|
|
1. {{critical_issue_1}}
|
|
2. {{critical_issue_2}}
|
|
3. {{critical_issue_3}}
|
|
|
|
### Specific Improvements Needed
|
|
1. {{improvement_1}}
|
|
2. {{improvement_2}}
|
|
3. {{improvement_3}}
|
|
|
|
### Developer Perspective Questions
|
|
- {{developer_question_1}}
|
|
- {{developer_question_2}}
|
|
- {{developer_question_3}}
|
|
|
|
### Recommendations
|
|
[ ] **READY FOR DEVELOPMENT** - Story provides sufficient context for implementation
|
|
[ ] **NEEDS MINOR REVISION** - Address specific issues before development
|
|
[ ] **REQUIRES SIGNIFICANT REVISION** - Major gaps need resolution
|
|
[ ] **BLOCKED** - External dependencies must be resolved
|
|
|
|
### Next Steps
|
|
1. {{next_step_1}}
|
|
2. {{next_step_2}}
|
|
3. {{next_step_3}}
|
|
|
|
---
|
|
|
|
## Sign-off
|
|
|
|
**Product Owner**: {{po_name}}
|
|
**Scrum Master**: {{sm_name}}
|
|
**Date**: {{validation_date}}
|
|
**Story ID**: {{story_id}}
|
|
|
|
**Final Notes**: {{final_validation_notes}} |