BMAD-METHOD/bmad-core/checklists/po-master-checklist.md

Product Owner (PO) Validation Checklist

This checklist serves as a comprehensive framework for the Product Owner to validate the complete MVP plan before development execution. The PO should systematically work through each item, documenting compliance status and noting any deficiencies.

[[LLM: INITIALIZATION INSTRUCTIONS - PO MASTER CHECKLIST

Before proceeding with this checklist, ensure you have access to:

1. prd.md - The Product Requirements Document (check docs/prd.md)
2. architecture.md - The system architecture (check docs/architecture.md)
3. frontend-architecture.md - If applicable (check docs/frontend-architecture.md or docs/fe-architecture.md)
4. All epic and story definitions
5. Any technical specifications or constraints

IMPORTANT: This checklist validates the COMPLETE MVP plan. All documents should be finalized before running this validation.

VALIDATION FOCUS:

1. Sequencing - Are things built in the right order?
2. Dependencies - Are all prerequisites in place before they're needed?
3. Completeness - Is everything needed for MVP included?
4. Clarity - Can developers implement without confusion?
5. Feasibility - Is the plan realistic and achievable?

EXECUTION MODE: Ask the user if they want to work through the checklist:

• Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
• All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]

1. PROJECT SETUP & INITIALIZATION

[[LLM: Project setup is the foundation - if this is wrong, everything else fails. Verify:

1. The VERY FIRST epic/story creates the project structure
2. No code is written before the project exists
3. Development environment is ready before any development
4. Dependencies are installed before they're imported
5. Configuration happens before it's needed]]

1.1 Project Scaffolding

• Epic 1 includes explicit steps for project creation/initialization
• If using a starter template, steps for cloning/setup are included
• If building from scratch, all necessary scaffolding steps are defined
• Initial README or documentation setup is included
• Repository setup and initial commit processes are defined (if applicable)

1.2 Development Environment

• Local development environment setup is clearly defined
• Required tools and versions are specified (Node.js, Python, etc.)
• Steps for installing dependencies are included
• Configuration files (dotenv, config files, etc.) are addressed
• Development server setup is included

1.3 Core Dependencies

• All critical packages/libraries are installed early in the process
• Package management (npm, pip, etc.) is properly addressed
• Version specifications are appropriately defined
• Dependency conflicts or special requirements are noted

2. INFRASTRUCTURE & DEPLOYMENT SEQUENCING

[[LLM: Infrastructure must exist before it's used. Check sequencing carefully:

1. Databases exist before tables/collections
2. Tables/collections exist before data operations
3. APIs are configured before endpoints are added
4. Auth is set up before protected routes
5. Deployment pipeline exists before deployment stories]]

2.1 Database & Data Store Setup

• Database selection/setup occurs before any database operations
• Schema definitions are created before data operations
• Migration strategies are defined if applicable
• Seed data or initial data setup is included if needed
• Database access patterns and security are established early

2.2 API & Service Configuration

• API frameworks are set up before implementing endpoints
• Service architecture is established before implementing services
• Authentication framework is set up before protected routes
• Middleware and common utilities are created before use

2.3 Deployment Pipeline

• CI/CD pipeline is established before any deployment actions
• Infrastructure as Code (IaC) is set up before use
• Environment configurations (dev, staging, prod) are defined early
• Deployment strategies are defined before implementation
• Rollback procedures or considerations are addressed

2.4 Testing Infrastructure

• Testing frameworks are installed before writing tests
• Test environment setup precedes test implementation
• Mock services or data are defined before testing
• Test utilities or helpers are created before use

3. EXTERNAL DEPENDENCIES & INTEGRATIONS

[[LLM: External dependencies often block progress. Ensure:

1. All external accounts are created early
2. API keys are obtained before integration stories
3. User actions (like purchasing) are clearly marked
4. Fallback options exist for external service issues
5. Integration prerequisites are met before integration]]

3.1 Third-Party Services

• Account creation steps are identified for required services
• API key acquisition processes are defined
• Steps for securely storing credentials are included
• Fallback or offline development options are considered

3.2 External APIs

• Integration points with external APIs are clearly identified
• Authentication with external services is properly sequenced
• API limits or constraints are acknowledged
• Backup strategies for API failures are considered

3.3 Infrastructure Services

• Cloud resource provisioning is properly sequenced
• DNS or domain registration needs are identified
• Email or messaging service setup is included if needed
• CDN or static asset hosting setup precedes their use

4. USER/AGENT RESPONSIBILITY DELINEATION

[[LLM: Clear ownership prevents confusion and delays. Verify:

1. User tasks are truly things only humans can do
2. No coding tasks are assigned to users
3. Account creation and payments are user tasks
4. Everything else is assigned to appropriate agents
5. Handoffs between user and agent are clear]]

4.1 User Actions

• User responsibilities are limited to only what requires human intervention
• Account creation on external services is properly assigned to users
• Purchasing or payment actions are correctly assigned to users
• Credential provision is appropriately assigned to users

4.2 Developer Agent Actions

• All code-related tasks are assigned to developer agents
• Automated processes are correctly identified as agent responsibilities
• Configuration management is properly assigned
• Testing and validation are assigned to appropriate agents

5. FEATURE SEQUENCING & DEPENDENCIES

[[LLM: Dependencies create the critical path. Check rigorously:

1. Nothing is used before it exists
2. Shared components are built once, used many times
3. The user can complete a meaningful flow early
4. Each epic delivers value, not just infrastructure
5. Dependencies don't create circular references]]

5.1 Functional Dependencies

• Features that depend on other features are sequenced correctly
• Shared components are built before their use
• User flows follow a logical progression
• Authentication features precede protected routes/features

5.2 Technical Dependencies

• Lower-level services are built before higher-level ones
• Libraries and utilities are created before their use
• Data models are defined before operations on them
• API endpoints are defined before client consumption

5.3 Cross-Epic Dependencies

• Later epics build upon functionality from earlier epics
• No epic requires functionality from later epics
• Infrastructure established in early epics is utilized consistently
• Incremental value delivery is maintained

6. MVP SCOPE ALIGNMENT

[[LLM: MVP means MINIMUM viable product. Validate:

1. Every feature directly supports core MVP goals
2. "Nice to haves" are clearly marked for post-MVP
3. The user can achieve primary goals with included features
4. Technical requirements don't add unnecessary scope
5. The product is truly viable with just these features]]

6.1 PRD Goals Alignment

• All core goals defined in the PRD are addressed in epics/stories
• Features directly support the defined MVP goals
• No extraneous features beyond MVP scope are included
• Critical features are prioritized appropriately

6.2 User Journey Completeness

• All critical user journeys are fully implemented
• Edge cases and error scenarios are addressed
• User experience considerations are included
• Accessibility requirements are incorporated if specified

6.3 Technical Requirements Satisfaction

• All technical constraints from the PRD are addressed
• Non-functional requirements are incorporated
• Architecture decisions align with specified constraints
• Performance considerations are appropriately addressed

7. RISK MANAGEMENT & PRACTICALITY

[[LLM: Risks can derail the entire project. Ensure:

1. Technical unknowns have research/spike stories
2. External dependencies have fallback plans
3. Complex features have validation milestones
4. The timeline accounts for discovered complexity
5. Critical risks are addressed early, not late]]

7.1 Technical Risk Mitigation

• Complex or unfamiliar technologies have appropriate learning/prototyping stories
• High-risk components have explicit validation steps
• Fallback strategies exist for risky integrations
• Performance concerns have explicit testing/validation

7.2 External Dependency Risks

• Risks with third-party services are acknowledged and mitigated
• API limits or constraints are addressed
• Backup strategies exist for critical external services
• Cost implications of external services are considered

7.3 Timeline Practicality

• Story complexity and sequencing suggest a realistic timeline
• Dependencies on external factors are minimized or managed
• Parallel work is enabled where possible
• Critical path is identified and optimized

8. DOCUMENTATION & HANDOFF

[[LLM: Good documentation enables smooth development. Check:

1. Developers can start without extensive onboarding
2. Deployment steps are clear and complete
3. Handoff points between roles are documented
4. Future maintenance is considered
5. Knowledge isn't trapped in one person's head]]

8.1 Developer Documentation

• API documentation is created alongside implementation
• Setup instructions are comprehensive
• Architecture decisions are documented
• Patterns and conventions are documented

8.2 User Documentation

• User guides or help documentation is included if required
• Error messages and user feedback are considered
• Onboarding flows are fully specified
• Support processes are defined if applicable

9. POST-MVP CONSIDERATIONS

[[LLM: Planning for success prevents technical debt. Verify:

1. MVP doesn't paint the product into a corner
2. Future features won't require major refactoring
3. Monitoring exists to validate MVP success
4. Feedback loops inform post-MVP priorities
5. The architecture can grow with the product]]

9.1 Future Enhancements

• Clear separation between MVP and future features
• Architecture supports planned future enhancements
• Technical debt considerations are documented
• Extensibility points are identified

9.2 Feedback Mechanisms

• Analytics or usage tracking is included if required
• User feedback collection is considered
• Monitoring and alerting are addressed
• Performance measurement is incorporated

VALIDATION SUMMARY

[[LLM: FINAL PO VALIDATION REPORT GENERATION

Generate a comprehensive validation report for the complete MVP plan:

1. Executive Summary

   • Overall plan readiness (percentage)
   • Go/No-Go recommendation
   • Critical blocking issues count
   • Estimated development timeline feasibility

2. Sequencing Analysis

   • Dependency violations found
   • Circular dependencies identified
   • Missing prerequisites
   • Optimal vs actual sequencing

3. Risk Assessment

   • High-risk areas without mitigation
   • External dependency risks
   • Technical complexity hotspots
   • Timeline risks

4. MVP Completeness

   • Core features coverage
   • Missing essential functionality
   • Scope creep identified
   • True MVP vs "MLP" (Most Lovable Product)

5. Implementation Readiness

   • Developer clarity score (1-10)
   • Ambiguous requirements count
   • Missing technical details
   • Handoff completeness

6. Recommendations

   • Must-fix before development
   • Should-fix for quality
   • Consider for improvement
   • Post-MVP deferrals

After presenting the report, ask if the user wants:

• Detailed analysis of any failed sections
• Specific story resequencing suggestions
• Risk mitigation strategies
• MVP scope refinement help]]

Category Statuses

Category	Status	Critical Issues
1. Project Setup & Initialization	TBD
2. Infrastructure & Deployment Sequencing	TBD
3. External Dependencies & Integrations	TBD
4. User/Agent Responsibility Delineation	TBD
5. Feature Sequencing & Dependencies	TBD
6. MVP Scope Alignment	TBD
7. Risk Management & Practicality	TBD
8. Documentation & Handoff	TBD
9. Post-MVP Considerations	TBD

Critical Deficiencies

To be populated during validation

Recommendations

To be populated during validation

Final Decision

• APPROVED: The plan is comprehensive, properly sequenced, and ready for implementation.
• REJECTED: The plan requires revision to address the identified deficiencies.