schema standardization and bmad ide orchesatrtor can do anything
This commit is contained in:
Brian Madison
@@ -1,83 +1,112 @@
|
||||
# Product Owner (PO) Validation Checklist
|
||||
# Product Owner (PO) Master 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.
|
||||
This checklist serves as a comprehensive framework for the Product Owner to validate project plans before development execution. It adapts intelligently based on project type (greenfield vs brownfield) and includes UI/UX considerations when applicable.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - PO MASTER CHECKLIST
|
||||
|
||||
Before proceeding with this checklist, ensure you have access to:
|
||||
PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
|
||||
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
|
||||
1. Is this a GREENFIELD project (new from scratch)?
|
||||
|
||||
IMPORTANT: This checklist validates the COMPLETE MVP plan. All documents should be finalized before running this validation.
|
||||
- Look for: New project initialization, no existing codebase references
|
||||
- Check for: prd.md, architecture.md, new project setup stories
|
||||
|
||||
VALIDATION FOCUS:
|
||||
2. Is this a BROWNFIELD project (enhancing existing system)?
|
||||
|
||||
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?
|
||||
- Look for: References to existing codebase, enhancement/modification language
|
||||
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
|
||||
|
||||
3. Does the project include UI/UX components?
|
||||
- Check for: frontend-architecture.md, UI/UX specifications, design files
|
||||
- Look for: Frontend stories, component specifications, user interface mentions
|
||||
|
||||
DOCUMENT REQUIREMENTS:
|
||||
Based on project type, ensure you have access to:
|
||||
|
||||
For GREENFIELD projects:
|
||||
|
||||
- prd.md - The Product Requirements Document
|
||||
- architecture.md - The system architecture
|
||||
- frontend-architecture.md - If UI/UX is involved
|
||||
- All epic and story definitions
|
||||
|
||||
For BROWNFIELD projects:
|
||||
|
||||
- brownfield-prd.md - The brownfield enhancement requirements
|
||||
- brownfield-architecture.md - The enhancement architecture
|
||||
- Existing project codebase access (CRITICAL - cannot proceed without this)
|
||||
- Current deployment configuration and infrastructure details
|
||||
- Database schemas, API documentation, monitoring setup
|
||||
|
||||
SKIP INSTRUCTIONS:
|
||||
|
||||
- Skip sections marked [[BROWNFIELD ONLY]] for greenfield projects
|
||||
- Skip sections marked [[GREENFIELD ONLY]] for brownfield projects
|
||||
- Skip sections marked [[UI/UX ONLY]] for backend-only projects
|
||||
- Note all skipped sections in your final report
|
||||
|
||||
VALIDATION APPROACH:
|
||||
|
||||
1. Deep Analysis - Thoroughly analyze each item against documentation
|
||||
2. Evidence-Based - Cite specific sections or code when validating
|
||||
3. Critical Thinking - Question assumptions and identify gaps
|
||||
4. Risk Assessment - Consider what could go wrong with each decision
|
||||
|
||||
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]]
|
||||
- Section by section (interactive mode) - Review each section, get confirmation before proceeding
|
||||
- All at once (comprehensive mode) - Complete full analysis and present report at end]]
|
||||
|
||||
## 1. PROJECT SETUP & INITIALIZATION
|
||||
|
||||
[[LLM: Project setup is the foundation - if this is wrong, everything else fails. Verify:
|
||||
[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
|
||||
|
||||
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
|
||||
### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
|
||||
|
||||
- [ ] 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)
|
||||
- [ ] Repository setup and initial commit processes are defined
|
||||
|
||||
### 1.2 Development Environment
|
||||
### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
|
||||
|
||||
- [ ] Existing project analysis has been completed and documented
|
||||
- [ ] Integration points with current system are identified
|
||||
- [ ] Development environment preserves existing functionality
|
||||
- [ ] Local testing approach validated for existing features
|
||||
- [ ] Rollback procedures defined for each integration point
|
||||
|
||||
### 1.3 Development Environment
|
||||
|
||||
- [ ] Local development environment setup is clearly defined
|
||||
- [ ] Required tools and versions are specified (Node.js, Python, etc.)
|
||||
- [ ] Required tools and versions are specified
|
||||
- [ ] Steps for installing dependencies are included
|
||||
- [ ] Configuration files (dotenv, config files, etc.) are addressed
|
||||
- [ ] Configuration files are addressed appropriately
|
||||
- [ ] Development server setup is included
|
||||
|
||||
### 1.3 Core Dependencies
|
||||
### 1.4 Core Dependencies
|
||||
|
||||
- [ ] All critical packages/libraries are installed early in the process
|
||||
- [ ] Package management (npm, pip, etc.) is properly addressed
|
||||
- [ ] All critical packages/libraries are installed early
|
||||
- [ ] Package management is properly addressed
|
||||
- [ ] Version specifications are appropriately defined
|
||||
- [ ] Dependency conflicts or special requirements are noted
|
||||
- [ ] [[BROWNFIELD ONLY]] Version compatibility with existing stack verified
|
||||
|
||||
## 2. INFRASTRUCTURE & DEPLOYMENT SEQUENCING
|
||||
## 2. INFRASTRUCTURE & DEPLOYMENT
|
||||
|
||||
[[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]]
|
||||
[[LLM: Infrastructure must exist before use. For brownfield, must integrate with existing infrastructure without breaking it.]]
|
||||
|
||||
### 2.1 Database & Data Store Setup
|
||||
|
||||
- [ ] Database selection/setup occurs before any database operations
|
||||
- [ ] Database selection/setup occurs before any 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
|
||||
- [ ] [[BROWNFIELD ONLY]] Database migration risks identified and mitigated
|
||||
- [ ] [[BROWNFIELD ONLY]] Backward compatibility ensured
|
||||
|
||||
### 2.2 API & Service Configuration
|
||||
|
||||
@@ -85,31 +114,29 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Service architecture is established before implementing services
|
||||
- [ ] Authentication framework is set up before protected routes
|
||||
- [ ] Middleware and common utilities are created before use
|
||||
- [ ] [[BROWNFIELD ONLY]] API compatibility with existing system maintained
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration with existing authentication preserved
|
||||
|
||||
### 2.3 Deployment Pipeline
|
||||
|
||||
- [ ] CI/CD pipeline is established before any deployment actions
|
||||
- [ ] CI/CD pipeline is established before deployment actions
|
||||
- [ ] Infrastructure as Code (IaC) is set up before use
|
||||
- [ ] Environment configurations (dev, staging, prod) are defined early
|
||||
- [ ] Environment configurations are defined early
|
||||
- [ ] Deployment strategies are defined before implementation
|
||||
- [ ] Rollback procedures or considerations are addressed
|
||||
- [ ] [[BROWNFIELD ONLY]] Deployment minimizes downtime
|
||||
- [ ] [[BROWNFIELD ONLY]] Blue-green or canary deployment implemented
|
||||
|
||||
### 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
|
||||
- [ ] [[BROWNFIELD ONLY]] Regression testing covers existing functionality
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration testing validates new-to-existing connections
|
||||
|
||||
## 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]]
|
||||
[[LLM: External dependencies often block progress. For brownfield, ensure new dependencies don't conflict with existing ones.]]
|
||||
|
||||
### 3.1 Third-Party Services
|
||||
|
||||
@@ -117,6 +144,8 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] API key acquisition processes are defined
|
||||
- [ ] Steps for securely storing credentials are included
|
||||
- [ ] Fallback or offline development options are considered
|
||||
- [ ] [[BROWNFIELD ONLY]] Compatibility with existing services verified
|
||||
- [ ] [[BROWNFIELD ONLY]] Impact on existing integrations assessed
|
||||
|
||||
### 3.2 External APIs
|
||||
|
||||
@@ -124,6 +153,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Authentication with external services is properly sequenced
|
||||
- [ ] API limits or constraints are acknowledged
|
||||
- [ ] Backup strategies for API failures are considered
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing API dependencies maintained
|
||||
|
||||
### 3.3 Infrastructure Services
|
||||
|
||||
@@ -131,239 +161,270 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] 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
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing infrastructure services preserved
|
||||
|
||||
## 4. USER/AGENT RESPONSIBILITY DELINEATION
|
||||
## 4. UI/UX CONSIDERATIONS [[UI/UX ONLY]]
|
||||
|
||||
[[LLM: Clear ownership prevents confusion and delays. Verify:
|
||||
[[LLM: Only evaluate this section if the project includes user interface components. Skip entirely for backend-only projects.]]
|
||||
|
||||
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 Design System Setup
|
||||
|
||||
### 4.1 User Actions
|
||||
- [ ] UI framework and libraries are selected and installed early
|
||||
- [ ] Design system or component library is established
|
||||
- [ ] Styling approach (CSS modules, styled-components, etc.) is defined
|
||||
- [ ] Responsive design strategy is established
|
||||
- [ ] Accessibility requirements are defined upfront
|
||||
|
||||
- [ ] 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 Frontend Infrastructure
|
||||
|
||||
### 4.2 Developer Agent Actions
|
||||
- [ ] Frontend build pipeline is configured before development
|
||||
- [ ] Asset optimization strategy is defined
|
||||
- [ ] Frontend testing framework is set up
|
||||
- [ ] Component development workflow is established
|
||||
- [ ] [[BROWNFIELD ONLY]] UI consistency with existing system maintained
|
||||
|
||||
- [ ] 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
|
||||
### 4.3 User Experience Flow
|
||||
|
||||
## 5. FEATURE SEQUENCING & DEPENDENCIES
|
||||
- [ ] User journeys are mapped before implementation
|
||||
- [ ] Navigation patterns are defined early
|
||||
- [ ] Error states and loading states are planned
|
||||
- [ ] Form validation patterns are established
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing user workflows preserved or migrated
|
||||
|
||||
[[LLM: Dependencies create the critical path. Check rigorously:
|
||||
## 5. USER/AGENT RESPONSIBILITY
|
||||
|
||||
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]]
|
||||
[[LLM: Clear ownership prevents confusion. Ensure tasks are assigned appropriately based on what only humans can do.]]
|
||||
|
||||
### 5.1 Functional Dependencies
|
||||
### 5.1 User Actions
|
||||
|
||||
- [ ] Features that depend on other features are sequenced correctly
|
||||
- [ ] User responsibilities limited to human-only tasks
|
||||
- [ ] Account creation on external services assigned to users
|
||||
- [ ] Purchasing or payment actions assigned to users
|
||||
- [ ] Credential provision appropriately assigned to users
|
||||
|
||||
### 5.2 Developer Agent Actions
|
||||
|
||||
- [ ] All code-related tasks assigned to developer agents
|
||||
- [ ] Automated processes identified as agent responsibilities
|
||||
- [ ] Configuration management properly assigned
|
||||
- [ ] Testing and validation assigned to appropriate agents
|
||||
|
||||
## 6. FEATURE SEQUENCING & DEPENDENCIES
|
||||
|
||||
[[LLM: Dependencies create the critical path. For brownfield, ensure new features don't break existing ones.]]
|
||||
|
||||
### 6.1 Functional Dependencies
|
||||
|
||||
- [ ] Features depending on others are sequenced correctly
|
||||
- [ ] Shared components are built before their use
|
||||
- [ ] User flows follow a logical progression
|
||||
- [ ] Authentication features precede protected routes/features
|
||||
- [ ] User flows follow logical progression
|
||||
- [ ] Authentication features precede protected features
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing functionality preserved throughout
|
||||
|
||||
### 5.2 Technical Dependencies
|
||||
### 6.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
|
||||
- [ ] Lower-level services built before higher-level ones
|
||||
- [ ] Libraries and utilities created before their use
|
||||
- [ ] Data models defined before operations on them
|
||||
- [ ] API endpoints defined before client consumption
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration points tested at each step
|
||||
|
||||
### 5.3 Cross-Epic Dependencies
|
||||
### 6.3 Cross-Epic Dependencies
|
||||
|
||||
- [ ] Later epics build upon functionality from earlier epics
|
||||
- [ ] Later epics build upon earlier epic functionality
|
||||
- [ ] No epic requires functionality from later epics
|
||||
- [ ] Infrastructure established in early epics is utilized consistently
|
||||
- [ ] Incremental value delivery is maintained
|
||||
- [ ] Infrastructure from early epics utilized consistently
|
||||
- [ ] Incremental value delivery maintained
|
||||
- [ ] [[BROWNFIELD ONLY]] Each epic maintains system integrity
|
||||
|
||||
## 6. MVP SCOPE ALIGNMENT
|
||||
## 7. RISK MANAGEMENT [[BROWNFIELD ONLY]]
|
||||
|
||||
[[LLM: MVP means MINIMUM viable product. Validate:
|
||||
[[LLM: This section is CRITICAL for brownfield projects. Think pessimistically about what could break.]]
|
||||
|
||||
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]]
|
||||
### 7.1 Breaking Change Risks
|
||||
|
||||
### 6.1 PRD Goals Alignment
|
||||
- [ ] Risk of breaking existing functionality assessed
|
||||
- [ ] Database migration risks identified and mitigated
|
||||
- [ ] API breaking change risks evaluated
|
||||
- [ ] Performance degradation risks identified
|
||||
- [ ] Security vulnerability risks evaluated
|
||||
|
||||
- [ ] 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
|
||||
### 7.2 Rollback Strategy
|
||||
|
||||
### 6.2 User Journey Completeness
|
||||
- [ ] Rollback procedures clearly defined per story
|
||||
- [ ] Feature flag strategy implemented
|
||||
- [ ] Backup and recovery procedures updated
|
||||
- [ ] Monitoring enhanced for new components
|
||||
- [ ] Rollback triggers and thresholds defined
|
||||
|
||||
- [ ] 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
|
||||
### 7.3 User Impact Mitigation
|
||||
|
||||
### 6.3 Technical Requirements Satisfaction
|
||||
- [ ] Existing user workflows analyzed for impact
|
||||
- [ ] User communication plan developed
|
||||
- [ ] Training materials updated
|
||||
- [ ] Support documentation comprehensive
|
||||
- [ ] Migration path for user data validated
|
||||
|
||||
- [ ] All technical constraints from the PRD are addressed
|
||||
- [ ] Non-functional requirements are incorporated
|
||||
- [ ] Architecture decisions align with specified constraints
|
||||
- [ ] Performance considerations are appropriately addressed
|
||||
## 8. MVP SCOPE ALIGNMENT
|
||||
|
||||
## 7. RISK MANAGEMENT & PRACTICALITY
|
||||
[[LLM: MVP means MINIMUM viable product. For brownfield, ensure enhancements are truly necessary.]]
|
||||
|
||||
[[LLM: Risks can derail the entire project. Ensure:
|
||||
### 8.1 Core Goals Alignment
|
||||
|
||||
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]]
|
||||
- [ ] All core goals from PRD are addressed
|
||||
- [ ] Features directly support MVP goals
|
||||
- [ ] No extraneous features beyond MVP scope
|
||||
- [ ] Critical features prioritized appropriately
|
||||
- [ ] [[BROWNFIELD ONLY]] Enhancement complexity justified
|
||||
|
||||
### 7.1 Technical Risk Mitigation
|
||||
### 8.2 User Journey Completeness
|
||||
|
||||
- [ ] 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
|
||||
- [ ] All critical user journeys fully implemented
|
||||
- [ ] Edge cases and error scenarios addressed
|
||||
- [ ] User experience considerations included
|
||||
- [ ] [[UI/UX ONLY]] Accessibility requirements incorporated
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing workflows preserved or improved
|
||||
|
||||
### 7.2 External Dependency Risks
|
||||
### 8.3 Technical Requirements
|
||||
|
||||
- [ ] 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
|
||||
- [ ] All technical constraints from PRD addressed
|
||||
- [ ] Non-functional requirements incorporated
|
||||
- [ ] Architecture decisions align with constraints
|
||||
- [ ] Performance considerations addressed
|
||||
- [ ] [[BROWNFIELD ONLY]] Compatibility requirements met
|
||||
|
||||
### 7.3 Timeline Practicality
|
||||
## 9. DOCUMENTATION & HANDOFF
|
||||
|
||||
- [ ] 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
|
||||
[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical.]]
|
||||
|
||||
## 8. DOCUMENTATION & HANDOFF
|
||||
### 9.1 Developer Documentation
|
||||
|
||||
[[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
|
||||
- [ ] API documentation created alongside implementation
|
||||
- [ ] Setup instructions are comprehensive
|
||||
- [ ] Architecture decisions are documented
|
||||
- [ ] Patterns and conventions are documented
|
||||
- [ ] Architecture decisions documented
|
||||
- [ ] Patterns and conventions documented
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
|
||||
|
||||
### 8.2 User Documentation
|
||||
### 9.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
|
||||
- [ ] User guides or help documentation included if required
|
||||
- [ ] Error messages and user feedback considered
|
||||
- [ ] Onboarding flows fully specified
|
||||
- [ ] [[BROWNFIELD ONLY]] Changes to existing features documented
|
||||
|
||||
## 9. POST-MVP CONSIDERATIONS
|
||||
### 9.3 Knowledge Transfer
|
||||
|
||||
[[LLM: Planning for success prevents technical debt. Verify:
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing system knowledge captured
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration knowledge documented
|
||||
- [ ] Code review knowledge sharing planned
|
||||
- [ ] Deployment knowledge transferred to operations
|
||||
- [ ] Historical context preserved
|
||||
|
||||
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]]
|
||||
## 10. POST-MVP CONSIDERATIONS
|
||||
|
||||
### 9.1 Future Enhancements
|
||||
[[LLM: Planning for success prevents technical debt. For brownfield, ensure enhancements don't limit future growth.]]
|
||||
|
||||
### 10.1 Future Enhancements
|
||||
|
||||
- [ ] Clear separation between MVP and future features
|
||||
- [ ] Architecture supports planned future enhancements
|
||||
- [ ] Technical debt considerations are documented
|
||||
- [ ] Extensibility points are identified
|
||||
- [ ] Architecture supports planned enhancements
|
||||
- [ ] Technical debt considerations documented
|
||||
- [ ] Extensibility points identified
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration patterns reusable
|
||||
|
||||
### 9.2 Feedback Mechanisms
|
||||
### 10.2 Monitoring & Feedback
|
||||
|
||||
- [ ] Analytics or usage tracking is included if required
|
||||
- [ ] User feedback collection is considered
|
||||
- [ ] Monitoring and alerting are addressed
|
||||
- [ ] Performance measurement is incorporated
|
||||
- [ ] Analytics or usage tracking included if required
|
||||
- [ ] User feedback collection considered
|
||||
- [ ] Monitoring and alerting addressed
|
||||
- [ ] Performance measurement incorporated
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing monitoring preserved/enhanced
|
||||
|
||||
## VALIDATION SUMMARY
|
||||
|
||||
[[LLM: FINAL PO VALIDATION REPORT GENERATION
|
||||
|
||||
Generate a comprehensive validation report for the complete MVP plan:
|
||||
Generate a comprehensive validation report that adapts to project type:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall plan readiness (percentage)
|
||||
- Project type: [Greenfield/Brownfield] with [UI/No UI]
|
||||
- Overall readiness (percentage)
|
||||
- Go/No-Go recommendation
|
||||
- Critical blocking issues count
|
||||
- Estimated development timeline feasibility
|
||||
- Sections skipped due to project type
|
||||
|
||||
2. Sequencing Analysis
|
||||
2. Project-Specific Analysis
|
||||
|
||||
- Dependency violations found
|
||||
- Circular dependencies identified
|
||||
- Missing prerequisites
|
||||
- Optimal vs actual sequencing
|
||||
FOR GREENFIELD:
|
||||
|
||||
- Setup completeness
|
||||
- Dependency sequencing
|
||||
- MVP scope appropriateness
|
||||
- Development timeline feasibility
|
||||
|
||||
FOR BROWNFIELD:
|
||||
|
||||
- Integration risk level (High/Medium/Low)
|
||||
- Existing system impact assessment
|
||||
- Rollback readiness
|
||||
- User disruption potential
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- High-risk areas without mitigation
|
||||
- External dependency risks
|
||||
- Technical complexity hotspots
|
||||
- Timeline risks
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations
|
||||
- Timeline impact of addressing issues
|
||||
- [BROWNFIELD] Specific integration risks
|
||||
|
||||
4. MVP Completeness
|
||||
|
||||
- Core features coverage
|
||||
- Missing essential functionality
|
||||
- Scope creep identified
|
||||
- True MVP vs "MLP" (Most Lovable Product)
|
||||
- True MVP vs over-engineering
|
||||
|
||||
5. Implementation Readiness
|
||||
|
||||
- Developer clarity score (1-10)
|
||||
- Ambiguous requirements count
|
||||
- Missing technical details
|
||||
- Handoff completeness
|
||||
- [BROWNFIELD] Integration point clarity
|
||||
|
||||
6. Recommendations
|
||||
|
||||
- Must-fix before development
|
||||
- Should-fix for quality
|
||||
- Consider for improvement
|
||||
- Post-MVP deferrals
|
||||
|
||||
7. [BROWNFIELD ONLY] Integration Confidence
|
||||
- Confidence in preserving existing functionality
|
||||
- Rollback procedure completeness
|
||||
- Monitoring coverage for integration points
|
||||
- Support team readiness
|
||||
|
||||
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]]
|
||||
- [BROWNFIELD] Integration risk deep-dive]]
|
||||
|
||||
### 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_ | |
|
||||
| Category | Status | Critical Issues |
|
||||
| --------------------------------------- | ------ | --------------- |
|
||||
| 1. Project Setup & Initialization | _TBD_ | |
|
||||
| 2. Infrastructure & Deployment | _TBD_ | |
|
||||
| 3. External Dependencies & Integrations | _TBD_ | |
|
||||
| 4. UI/UX Considerations | _TBD_ | |
|
||||
| 5. User/Agent Responsibility | _TBD_ | |
|
||||
| 6. Feature Sequencing & Dependencies | _TBD_ | |
|
||||
| 7. Risk Management (Brownfield) | _TBD_ | |
|
||||
| 8. MVP Scope Alignment | _TBD_ | |
|
||||
| 9. Documentation & Handoff | _TBD_ | |
|
||||
| 10. Post-MVP Considerations | _TBD_ | |
|
||||
|
||||
### Critical Deficiencies
|
||||
|
||||
@@ -376,4 +437,5 @@ _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.
|
||||
- **CONDITIONAL**: The plan requires specific adjustments before proceeding.
|
||||
- **REJECTED**: The plan requires significant revision to address critical deficiencies.
|
||||
|
||||
Reference in New Issue
Block a user