# Story Draft Checklist

This checklist validates that a story draft is complete and ready for development before it leaves the Scrum Master's control. Used by the Scrum Master Agent to ensure story quality before handoff to development.

## Required Documents
- The story draft being validated
- Epic file (if story is part of an epic)
- PRD or requirements document
- Architecture documents (if available)

## LLM Instructions
Execute this checklist systematically to validate the story draft completeness and quality. Mark each item and provide specific evidence or note what needs to be addressed.

## Section 1: Story Structure and Template Compliance

**LLM Prompt:** "Verify the story follows the proper template structure and contains all required sections with appropriate content."

### Template Completeness
- [ ] **All required sections present**
  - Evidence: Story header, statement, acceptance criteria, dev notes, tasks
  - Validation: No missing sections from story-tmpl.yaml
  
- [ ] **Story statement properly formatted**  
  - Evidence: Follows "As a [user], I want [capability], so that [value]" format
  - Quality: Clear user type, specific capability, measurable value
  
- [ ] **Acceptance criteria well-defined**
  - Evidence: Uses GIVEN-WHEN-THEN format where appropriate
  - Completeness: Covers functional, integration, and quality requirements
  
- [ ] **Context source documented**
  - Evidence: Source document, enhancement type, system impact identified
  - Traceability: Clear link back to originating requirements

**Section 1 Pass Criteria:** All structural elements must be complete and properly formatted.

## Section 2: Technical Guidance and Implementation Details

**LLM Prompt:** "Evaluate whether the technical guidance provides sufficient context for a developer agent to implement the story without external research."

### Dev Technical Guidance Quality
- [ ] **Architecture guidance complete**
  - Evidence: Relevant data models, API specs, component specs included
  - Sources: All technical details have source references
  
- [ ] **File locations specified**
  - Evidence: Clear guidance on where new files should be created
  - Consistency: File paths align with project structure
  
- [ ] **Integration approach defined**
  - Evidence: Clear description of how to integrate with existing system
  - Completeness: Integration points and patterns specified
  
- [ ] **Technical constraints documented**
  - Evidence: Version requirements, performance considerations, security rules
  - Accuracy: Constraints are verifiable and current

### Implementation Tasks Quality
- [ ] **Tasks are appropriately granular**
  - Evidence: Tasks can be completed in reasonable time blocks
  - Actionability: Each task has clear deliverables
  
- [ ] **Task sequence is logical**
  - Evidence: Tasks follow proper implementation order
  - Dependencies: Task dependencies are clear and manageable
  
- [ ] **Testing tasks included**
  - Evidence: Unit testing and integration testing tasks present
  - Coverage: Testing tasks cover all acceptance criteria

**Section 2 Pass Criteria:** Technical guidance must be sufficient for autonomous development.

## Section 3: Requirements and Acceptance Criteria Validation

**LLM Prompt:** "Verify that the acceptance criteria are complete, testable, and properly linked to implementation tasks."

### Acceptance Criteria Completeness
- [ ] **All requirements covered**
  - Evidence: Each requirement from source has corresponding acceptance criteria
  - Traceability: Clear mapping between requirements and criteria
  
- [ ] **Criteria are testable**
  - Evidence: Each criterion can be verified through code/testing
  - Specificity: Criteria avoid subjective language
  
- [ ] **Edge cases addressed**
  - Evidence: Error conditions and boundary cases included
  - Coverage: Non-happy-path scenarios considered
  
- [ ] **Integration requirements specified**
  - Evidence: Backward compatibility and system integration verified
  - Safety: Existing functionality protection included

### Task-Acceptance Criteria Alignment
- [ ] **Tasks map to acceptance criteria**
  - Evidence: Each AC has corresponding implementation tasks
  - Completeness: No orphaned criteria or tasks
  
- [ ] **Success criteria clear**
  - Evidence: "Done" is clearly defined for each criterion
  - Measurability: Success can be objectively verified

**Section 3 Pass Criteria:** All requirements must have testable criteria with clear implementation paths.

## Section 4: Risk Assessment and Quality Considerations

**LLM Prompt:** "Evaluate the risk assessment and quality considerations to ensure the story can be implemented safely."

### Risk Assessment Quality
- [ ] **Primary risks identified**
  - Evidence: Main implementation and integration risks documented
  - Mitigation: Clear strategies for addressing identified risks
  
- [ ] **Rollback plan documented**
  - Evidence: Clear steps to undo changes if needed
  - Feasibility: Rollback procedures are practical and tested
  
- [ ] **Safety checks defined**
  - Evidence: Specific steps to verify existing functionality
  - Coverage: Critical system areas are protected

### Quality and Standards Alignment
- [ ] **Definition of done complete**
  - Evidence: All DOD items relevant to this story type
  - Standards: Code quality and testing requirements specified
  
- [ ] **Security considerations addressed**
  - Evidence: Security requirements identified and addressed
  - Compliance: Security standards and practices followed

**Section 4 Pass Criteria:** Risk mitigation and quality standards must be adequately addressed.

## Section 5: Development Readiness Assessment

**LLM Prompt:** "Assess whether the story is ready for immediate development without requiring additional research or clarification."

### Self-Contained Context
- [ ] **All necessary information included**
  - Evidence: Dev agent can work without external document access
  - Completeness: Technical context, patterns, constraints all present
  
- [ ] **No ambiguous requirements**
  - Evidence: All requirements are clear and unambiguous
  - Actionability: Developer knows exactly what to build
  
- [ ] **Dependencies clearly identified**
  - Evidence: Any external dependencies or prerequisites noted
  - Availability: Required resources and access are confirmed

### Implementation Readiness
- [ ] **Story size is appropriate**
  - Evidence: Story can be completed in single development iteration
  - Scope: Story is focused and not trying to do too much
  
- [ ] **Priority and sequencing clear**
  - Evidence: Story priority and sprint assignment specified
  - Blocking: Any blocking relationships documented

**Section 5 Pass Criteria:** Story must be immediately implementable without additional research.

## Final Assessment

### Overall Completion Status
**Pass Criteria:** All 5 sections must achieve 100% pass rate.

### Story Quality Classification
- **Ready for Development:** All criteria met, can proceed to developer
- **Minor Issues:** Small fixes needed, can be addressed quickly
- **Major Issues:** Significant problems requiring rework
- **Incomplete:** Story needs substantial additional work

### Summary Report Template
```
## Story Draft Validation Results

**Story:** [Story Title]
**Validation Date:** [Date]
**Validated By:** Scrum Master Agent

### Section Pass Rates
- Section 1 (Structure): ___/4 items (___%)
- Section 2 (Technical): ___/7 items (___%)  
- Section 3 (Requirements): ___/6 items (___%)
- Section 4 (Risk/Quality): ___/5 items (___%)
- Section 5 (Readiness): ___/5 items (___%)

**Overall Status:** [READY/MINOR ISSUES/MAJOR ISSUES/INCOMPLETE]

### Issues Identified (if any)
[List any items that did not pass with specific recommendations]

### Recommended Actions
[Next steps to address any identified issues]

### Final Decision
[✓ Story Ready for Development] / [✗ Story Requires Revision]
```

## Usage Notes
- This checklist is executed by the Scrum Master Agent before story handoff
- All items must pass before story can be assigned to Developer Agent
- Any failing items must be addressed and re-validated
- The checklist results should guide story revision priorities
- Stories should only proceed to development when achieving "Ready" status