bmad-odoo-dev

# Story Draft Checklist ## Purpose Ensure that development stories are complete, actionable, and provide sufficient context for independent AI-driven development before marking them as ready for implementation. ## Story Quality Validation ### Business Context Completeness - [ ] **User story follows proper format**: "As a [user type], I want [capability], so that [business value]" - [ ] **Business value is clearly articulated** and measurable - [ ] **User personas are specific** (not generic "user") - [ ] **Business context explains WHY** this story exists - [ ] **Success metrics are defined** and measurable - [ ] **Priority is justified** based on business value ### Technical Context Adequacy - [ ] **System integration points are identified** and documented - [ ] **Technology stack is specified** for the implementation area - [ ] **Architecture alignment is documented** (follows existing patterns) - [ ] **Data requirements are clear** (database changes, data flow) - [ ] **Performance requirements are specified** (if applicable) - [ ] **Security considerations are addressed** (if applicable) ### Acceptance Criteria Quality - [ ] **All acceptance criteria use GIVEN/WHEN/THEN format** or equivalent structured format - [ ] **Functional requirements are specific and testable** - [ ] **Non-functional requirements are included** (performance, security, usability) - [ ] **Integration requirements are clearly specified** - [ ] **Edge cases and error conditions are covered** - [ ] **Acceptance criteria are prioritized** (must-have vs nice-to-have) ### Implementation Guidance Clarity - [ ] **Technical approach is recommended** and feasible - [ ] **Key components are identified** (classes, modules, services to create/modify) - [ ] **Integration patterns are specified** (how to connect with existing systems) - [ ] **Design patterns are referenced** for consistency - [ ] **Implementation tasks are broken down** into actionable items - [ ] **External dependencies are identified** and accessible ## Odoo-Specific Validation ### Odoo Architecture Compliance - [ ] **Target Odoo version is specified** (13.0-18.0) - [ ] **Module dependencies are identified** (standard, OCA, custom) - [ ] **Data model changes are documented** (new models, field additions, relationships) - [ ] **View requirements are specified** (forms, trees, search views) - [ ] **Security model is addressed** (access rights, record rules) - [ ] **OCA compliance patterns are referenced** where applicable ### Brownfield Considerations - [ ] **Existing system impact is assessed** and documented - [ ] **Integration with current modules is planned** - [ ] **Migration or upgrade considerations are addressed** - [ ] **Backward compatibility is ensured** - [ ] **Existing data handling is specified** - [ ] **Rollback procedures are documented** ### Doodba Deployment Readiness - [ ] **Deployment approach is documented** (module installation, updates) - [ ] **Testing strategy in Doodba environment is specified** - [ ] **Container and service requirements are noted** - [ ] **Database management approach is documented** - [ ] **Configuration changes are identified** ## Development Readiness Assessment ### Context Sufficiency - [ ] **Story can be implemented without external research** - [ ] **All necessary context is included in the story** - [ ] **References to external documents are minimal** and accessible - [ ] **Business rules are documented within the story** - [ ] **Integration specifications are complete** ### Technical Feasibility - [ ] **Implementation approach is technically sound** - [ ] **Required skills match available development resources** - [ ] **External dependencies are resolvable** - [ ] **Technology choices are appropriate** for the project context - [ ] **Performance requirements are achievable** - [ ] **Security requirements are implementable** ### Scope Appropriateness - [ ] **Story scope is appropriate for single development iteration** - [ ] **Story delivers independent business value** - [ ] **Story is not dependent on other unfinished stories** - [ ] **Story complexity matches estimated effort** - [ ] **Story can be tested independently** ## Quality Assurance Readiness ### Testing Strategy Completeness - [ ] **Unit testing requirements are specified** - [ ] **Integration testing approach is documented** - [ ] **User acceptance testing scenarios are defined** - [ ] **Performance testing requirements are noted** (if applicable) - [ ] **Security testing requirements are specified** (if applicable) - [ ] **Test data requirements are documented** ### Validation Criteria Clarity - [ ] **Definition of Done is comprehensive** and measurable - [ ] **Validation steps are specific** and executable - [ ] **Quality gates are defined** for story completion - [ ] **Review criteria are established** - [ ] **Deployment validation steps are documented** ## Risk and Dependency Management ### Risk Assessment - [ ] **Technical risks are identified** and assessed - [ ] **Business risks are considered** - [ ] **Mitigation strategies are documented** for major risks - [ ] **Contingency plans are available** for high-impact risks - [ ] **Risk ownership is assigned** ### Dependency Management - [ ] **External dependencies are identified** and tracked - [ ] **Internal dependencies on other stories are documented** - [ ] **Resource dependencies are noted** - [ ] **Timeline dependencies are realistic** - [ ] **Dependency resolution plans are documented** ## Stakeholder Alignment ### Business Stakeholder Approval - [ ] **Business requirements are validated** by stakeholders - [ ] **Acceptance criteria are approved** by business users - [ ] **Priority and timeline are agreed upon** - [ ] **Success metrics are endorsed** by business stakeholders - [ ] **User experience expectations are aligned** ### Technical Stakeholder Review - [ ] **Technical approach is reviewed** by architect/tech lead - [ ] **Security considerations are validated** by security team - [ ] **Performance requirements are realistic** and agreed upon - [ ] **Integration approach is approved** by relevant teams - [ ] **Quality standards are aligned** with project requirements ## Documentation Standards ### Story Documentation Quality - [ ] **Writing is clear, concise, and unambiguous** - [ ] **Technical terms are used correctly** and consistently - [ ] **Formatting follows project standards** - [ ] **Links and references are valid** and accessible - [ ] **Version control information is current** ### Completeness and Maintainability - [ ] **All required sections are present** and complete - [ ] **Information is organized logically** - [ ] **Story is maintainable** and can be updated as needed - [ ] **Traceability to requirements is clear** - [ ] **Change history is documented** (if applicable) ## Final Story Approval ### Story Readiness Confirmation - [ ] **All checklist items are completed** and verified - [ ] **Story provides complete context** for independent development - [ ] **Implementation guidance eliminates ambiguity** - [ ] **Quality assurance requirements ensure comprehensive validation** - [ ] **Stakeholder alignment is confirmed** ### Go/No-Go Decision - [ ] **Story is approved for development** by designated approver - [ ] **Resources are allocated** and available - [ ] **Timeline is realistic** and agreed upon - [ ] **Dependencies are resolved** or have resolution plans - [ ] **Story is moved to ready status** in project management system ## Quality Gates ### Must Pass Before Development - [ ] All Business Context items completed - [ ] All Acceptance Criteria items completed - [ ] All Implementation Guidance items completed - [ ] Technical feasibility confirmed - [ ] Stakeholder approval obtained ### Must Pass Before Story Acceptance - [ ] All acceptance criteria validated - [ ] All quality requirements met - [ ] All testing completed successfully - [ ] Documentation updated - [ ] Stakeholder sign-off obtained ## Notes and Recommendations ### Common Issues to Avoid - **Vague acceptance criteria** that can't be tested objectively - **Missing business context** that requires external research - **Incomplete technical guidance** that leaves implementation ambiguous - **Unrealistic scope** for the estimated timeline - **Missing integration requirements** that cause implementation delays ### Best Practices - **Include concrete examples** in acceptance criteria - **Reference existing patterns** for technical consistency - **Provide complete business context** to eliminate external dependencies - **Break down complex stories** into manageable components - **Validate feasibility** before committing to development Remember: A well-drafted story eliminates the need for additional research and provides everything needed for successful AI-driven development. The time invested in thorough story preparation pays dividends in implementation speed and quality.