Initial commit
This commit is contained in:
Zhongwei Li
423
skills/prioritization/SKILL.md
Normal file
423
skills/prioritization/SKILL.md
Normal file
@@ -0,0 +1,423 @@
|
||||
---
|
||||
name: Prioritization
|
||||
description: This skill should be used when the user asks to "prioritize requirements", "use MoSCoW", "prioritize epics", "prioritize stories", "prioritize tasks", "what should I build first", "rank features", or when they need to determine the priority order of epics, user stories, or tasks using the MoSCoW framework.
|
||||
version: 0.2.0
|
||||
---
|
||||
|
||||
# Prioritization
|
||||
|
||||
## Overview
|
||||
|
||||
Prioritization is the process of determining the relative importance and sequence of requirements at any level—epics, user stories, or tasks. Using the MoSCoW framework (Must Have, Should Have, Could Have, Won't Have), teams can make informed decisions about what to build first, ensuring maximum value delivery within constraints.
|
||||
|
||||
## Purpose
|
||||
|
||||
Effective prioritization:
|
||||
- Focuses effort on highest-value work
|
||||
- Enables incremental delivery of working software
|
||||
- Manages scope within time and budget constraints
|
||||
- Aligns team and stakeholders on what matters most
|
||||
- Provides clear rationale for sequencing decisions
|
||||
|
||||
## MoSCoW Framework
|
||||
|
||||
### Must Have
|
||||
|
||||
**Definition:** Requirements critical for success. Without these, the product fails to deliver core value or is fundamentally broken.
|
||||
|
||||
**Characteristics:**
|
||||
- Non-negotiable for initial release
|
||||
- Product is not viable without these
|
||||
- Legal, regulatory, or safety requirements
|
||||
- Core functionality essential to vision
|
||||
|
||||
**Examples:**
|
||||
- User authentication (for a product requiring accounts)
|
||||
- Payment processing (for an e-commerce product)
|
||||
- Core workflow (the main thing users do)
|
||||
|
||||
**Questions to Ask:**
|
||||
- Can we ship without this?
|
||||
- Does this deliver essential core value?
|
||||
- Is this legally or contractually required?
|
||||
- Would users reject the product without this?
|
||||
|
||||
**Typical Percentage:** 60% of total requirements
|
||||
|
||||
---
|
||||
|
||||
### Should Have
|
||||
|
||||
**Definition:** Important requirements that significantly enhance value but aren't absolutely critical for initial release. Can be deferred if necessary.
|
||||
|
||||
**Characteristics:**
|
||||
- High impact, not mission-critical
|
||||
- Significantly improves user experience
|
||||
- Differentiates from competitors
|
||||
- Can work around absence (though painful)
|
||||
|
||||
**Examples:**
|
||||
- Advanced filtering and search
|
||||
- Batch operations
|
||||
- Export to multiple formats
|
||||
- Email notifications
|
||||
|
||||
**Questions to Ask:**
|
||||
- Does this significantly improve UX or value?
|
||||
- Can users achieve their goals without this (even if harder)?
|
||||
- Does this provide important differentiation?
|
||||
- Would delaying this cause pain but not failure?
|
||||
|
||||
**Typical Percentage:** 20% of total requirements
|
||||
|
||||
---
|
||||
|
||||
### Could Have
|
||||
|
||||
**Definition:** Nice-to-have requirements that provide marginal value. Include only if time and resources permit.
|
||||
|
||||
**Characteristics:**
|
||||
- Low impact on core value
|
||||
- "Nice to have" enhancements
|
||||
- Polish and convenience features
|
||||
- Easy to cut if needed
|
||||
|
||||
**Examples:**
|
||||
- Customizable themes
|
||||
- Additional chart types
|
||||
- Keyboard shortcuts
|
||||
- Tooltips and help text
|
||||
|
||||
**Questions to Ask:**
|
||||
- Would users notice if this were missing?
|
||||
- Does this provide marginal or incremental value?
|
||||
- Is this primarily for convenience or polish?
|
||||
- Can this easily be added later?
|
||||
|
||||
**Typical Percentage:** 20% of total requirements
|
||||
|
||||
---
|
||||
|
||||
### Won't Have (This Time)
|
||||
|
||||
**Definition:** Requirements explicitly excluded from current scope. May be considered for future releases but are off the table now.
|
||||
|
||||
**Characteristics:**
|
||||
- Out of current scope
|
||||
- Lower priority than other work
|
||||
- Not aligned with current goals
|
||||
- Explicitly deferred or rejected
|
||||
|
||||
**Examples:**
|
||||
- Mobile app (when focusing on web first)
|
||||
- AI-powered features (for MVP)
|
||||
- Advanced analytics (phase 2 feature)
|
||||
- Third-party integrations (beyond core)
|
||||
|
||||
**Questions to Ask:**
|
||||
- Does this align with current vision and goals?
|
||||
- Is this better suited for a future release?
|
||||
- Does including this risk delaying more important work?
|
||||
- Can we explicitly say "not now" to this?
|
||||
|
||||
**Purpose:** Prevents scope creep by making exclusions explicit
|
||||
|
||||
---
|
||||
|
||||
## Prioritization Process
|
||||
|
||||
### Step 1: Define Context
|
||||
|
||||
Establish the scope and constraints:
|
||||
|
||||
**Clarify:**
|
||||
- What are we prioritizing? (Epics? Stories? Tasks?)
|
||||
- What are the constraints? (Time, budget, resources)
|
||||
- What's the target? (MVP? V1.0? Next sprint?)
|
||||
- Who are the stakeholders?
|
||||
|
||||
**Set Boundaries:**
|
||||
- Total number of items to prioritize
|
||||
- Decision criteria (value, risk, effort, dependencies)
|
||||
- Time frame for this prioritization
|
||||
|
||||
### Step 2: Assess Each Item
|
||||
|
||||
For each epic/story/task, evaluate:
|
||||
|
||||
**Value to Users:**
|
||||
- How much does this improve user experience?
|
||||
- How many users benefit?
|
||||
- How often will this be used?
|
||||
|
||||
**Business Value:**
|
||||
- Revenue impact?
|
||||
- Strategic importance?
|
||||
- Competitive advantage?
|
||||
|
||||
**Risk:**
|
||||
- Technical risk (complexity, unknowns)?
|
||||
- Market risk (assumptions about user needs)?
|
||||
- Higher risk items often prioritized earlier for learning
|
||||
|
||||
**Effort/Cost:**
|
||||
- How much work is required?
|
||||
- Resource needs (people, time, tools)?
|
||||
- Return on investment?
|
||||
|
||||
**Dependencies:**
|
||||
- What must come before this?
|
||||
- What is blocked by this?
|
||||
- External dependencies?
|
||||
|
||||
### Step 3: Apply MoSCoW Categories
|
||||
|
||||
For each item, assign a MoSCoW category:
|
||||
|
||||
**Decision Framework:**
|
||||
|
||||
1. **Start with Must Haves:**
|
||||
- Identify absolute essentials
|
||||
- Challenge each: "Can we really not ship without this?"
|
||||
- Aim for <60% in this category
|
||||
|
||||
2. **Identify Should Haves:**
|
||||
- High-value, not mission-critical
|
||||
- Important for good UX or differentiation
|
||||
- Can defer if Must Haves at risk
|
||||
|
||||
3. **Mark Could Haves:**
|
||||
- Nice to have if time permits
|
||||
- Easy to cut without major impact
|
||||
- Often polish or convenience features
|
||||
|
||||
4. **Explicitly List Won't Haves:**
|
||||
- Items that won't be in current scope
|
||||
- Document WHY to prevent revisiting
|
||||
- May be reconsidered in future
|
||||
|
||||
### Step 4: Validate and Balance
|
||||
|
||||
Review the prioritization:
|
||||
|
||||
**Balance Check:**
|
||||
- Are <60% of items "Must Have"? (If more, challenge them)
|
||||
- Is there a healthy mix across categories?
|
||||
- Have we explicitly identified "Won't Haves"?
|
||||
|
||||
**Sanity Checks:**
|
||||
- Do "Must Haves" collectively deliver minimum viable product?
|
||||
- Can we ship with just "Must Haves" if needed?
|
||||
- Are dependencies respected? (prerequisite items high priority)
|
||||
|
||||
**Stakeholder Review:**
|
||||
- Share prioritization with key stakeholders
|
||||
- Get feedback on category assignments
|
||||
- Discuss trade-offs and rationale
|
||||
- Build consensus
|
||||
|
||||
### Step 5: Sequence Within Categories
|
||||
|
||||
Within each MoSCoW category, establish order:
|
||||
|
||||
**Sequencing Factors:**
|
||||
- Dependencies (blockers first)
|
||||
- Risk (tackle unknowns early for learning)
|
||||
- Value (highest value first within category)
|
||||
- Effort (quick wins can build momentum)
|
||||
|
||||
**Common Strategies:**
|
||||
- **Risk-driven:** Tackle high-risk, high-uncertainty items early
|
||||
- **Value-driven:** Deliver highest-value items first
|
||||
- **Dependency-driven:** Respect technical dependencies
|
||||
- **Quick wins:** Mix in some easy, visible wins for morale
|
||||
|
||||
### Step 6: Document and Communicate
|
||||
|
||||
Record prioritization decisions:
|
||||
|
||||
**In GitHub Projects:**
|
||||
- Update "Priority" custom field on issues
|
||||
- Add priority labels (priority:must-have, etc.)
|
||||
- Order issues in project views by priority
|
||||
|
||||
**Rationale:**
|
||||
- Document WHY items are prioritized as they are
|
||||
- Capture trade-offs and decisions made
|
||||
- Reference for future prioritization
|
||||
|
||||
**Communication:**
|
||||
- Share prioritized backlog with team
|
||||
- Explain sequencing and rationale
|
||||
- Set expectations about what's in/out of scope
|
||||
|
||||
## Prioritization at Different Levels
|
||||
|
||||
### Prioritizing Epics
|
||||
|
||||
**Context:** Determining which major capabilities to build first
|
||||
|
||||
**Considerations:**
|
||||
- Strategic alignment with vision
|
||||
- Foundation vs. enhancement (build foundation first)
|
||||
- User journey completeness (can users accomplish goals?)
|
||||
- Market differentiation (what makes you unique?)
|
||||
|
||||
**Example:**
|
||||
- Must Have: User Authentication, Core Workflow, Payment Processing
|
||||
- Should Have: Advanced Analytics, Team Collaboration
|
||||
- Could Have: Custom Branding, API Access
|
||||
- Won't Have: Mobile App (Web-first strategy)
|
||||
|
||||
### Prioritizing User Stories
|
||||
|
||||
**Context:** Determining which stories within an epic to implement first
|
||||
|
||||
**Considerations:**
|
||||
- Happy path before edge cases
|
||||
- Core functionality before enhancements
|
||||
- Foundation before polish
|
||||
- High-frequency use cases before rare ones
|
||||
|
||||
**Example (within "Campaign Management" epic):**
|
||||
- Must Have: Create campaign, View campaign list, Edit campaign basics
|
||||
- Should Have: Duplicate campaign, Archive campaign, Bulk operations
|
||||
- Could Have: Campaign templates, Custom fields
|
||||
- Won't Have: Campaign scheduling (separate epic)
|
||||
|
||||
### Prioritizing Tasks
|
||||
|
||||
**Context:** Determining sequence of implementation tasks within a story
|
||||
|
||||
**Considerations:**
|
||||
- Technical dependencies (backend before frontend)
|
||||
- Iterative progress (working slice early, then enhance)
|
||||
- Testing alongside feature work (not all at end)
|
||||
- Documentation concurrent with implementation
|
||||
|
||||
**Example (within "Filter campaigns by date" story):**
|
||||
- Must Have: Backend date filtering logic, Basic UI with date pickers, Integration
|
||||
- Should Have: Validation and error handling, Unit tests
|
||||
- Could Have: Date range presets (Last 7 days, Last 30 days)
|
||||
- Won't Have: Save filter preferences (separate story)
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Challenge "Must Haves"
|
||||
|
||||
Everything feels critical to someone:
|
||||
- Use strict criteria: "Product is broken without this"
|
||||
- Push back on inflated urgency
|
||||
- Ask: "Can we ship an MVP without this?"
|
||||
- Aim to keep "Must Haves" under 60%
|
||||
|
||||
### Be Explicit About "Won't Haves"
|
||||
|
||||
Prevent scope creep:
|
||||
- Document what's explicitly out of scope
|
||||
- Explain why (not aligned, too costly, wrong time)
|
||||
- Revisit in future planning cycles
|
||||
- Helps manage stakeholder expectations
|
||||
|
||||
### Consider Technical Dependencies
|
||||
|
||||
Priority isn't just about value:
|
||||
- Some items must come before others (architecture, data model)
|
||||
- Foundation before features built on it
|
||||
- Don't prioritize item X high if it depends on low-priority item Y
|
||||
|
||||
### Revisit and Refine
|
||||
|
||||
Priorities change:
|
||||
- New information emerges
|
||||
- Market conditions shift
|
||||
- User feedback reveals new priorities
|
||||
- Re-prioritize at regular intervals (quarterly, per release)
|
||||
|
||||
### Involve Stakeholders
|
||||
|
||||
Prioritization is collaborative:
|
||||
- Product owners provide business perspective
|
||||
- Developers provide technical perspective
|
||||
- Users/customers provide value perspective
|
||||
- Build consensus on trade-offs
|
||||
|
||||
### Use Data When Available
|
||||
|
||||
Inform decisions with evidence:
|
||||
- Usage analytics (what features are used most?)
|
||||
- User research (what do users need most?)
|
||||
- Revenue data (what drives business value?)
|
||||
- Competitor analysis (what's table stakes?)
|
||||
|
||||
## Common Pitfalls to Avoid
|
||||
|
||||
### Everything is a "Must Have"
|
||||
|
||||
If everything is critical, nothing is:
|
||||
- Challenge assumptions
|
||||
- Force trade-offs
|
||||
- Use strict criteria for "Must Have"
|
||||
|
||||
### Ignoring Technical Dependencies
|
||||
|
||||
Prioritizing features without considering what they depend on:
|
||||
- Map dependencies
|
||||
- Prioritize prerequisites appropriately
|
||||
- Consider architectural foundations
|
||||
|
||||
### Forgetting "Won't Have"
|
||||
|
||||
Scope creep occurs when exclusions aren't explicit:
|
||||
- Actively identify what's out of scope
|
||||
- Document and communicate "Won't Haves"
|
||||
- Revisit them in future planning
|
||||
|
||||
### Prioritizing Based on Who Shouts Loudest
|
||||
|
||||
Let the loudest voice determine priority:
|
||||
- Use objective criteria
|
||||
- Base decisions on data and strategy
|
||||
- Build consensus across stakeholders
|
||||
|
||||
### Never Re-Prioritizing
|
||||
|
||||
Priorities set once and never revisited:
|
||||
- Revisit priorities regularly
|
||||
- Adjust based on new information
|
||||
- Stay flexible and adaptive
|
||||
|
||||
## Quick Reference: Prioritization Flow
|
||||
|
||||
1. **Define Context** → What are we prioritizing? Constraints? Goals?
|
||||
2. **Assess Items** → Evaluate value, risk, effort, dependencies
|
||||
3. **Apply MoSCoW** → Assign each item to a category
|
||||
4. **Validate Balance** → Check distribution, sanity check, stakeholder review
|
||||
5. **Sequence** → Order within categories (dependencies, risk, value)
|
||||
6. **Document** → Update GitHub Projects, record rationale
|
||||
7. **Communicate** → Share with team and stakeholders
|
||||
8. **Execute** → Build in priority order (Must → Should → Could)
|
||||
9. **Revisit** → Re-prioritize as needed based on learning
|
||||
|
||||
## Additional Resources
|
||||
|
||||
### Reference Files
|
||||
|
||||
For detailed prioritization frameworks and examples:
|
||||
- **`${CLAUDE_PLUGIN_ROOT}/skills/prioritization/references/moscow-worksheet.md`** - Template for conducting MoSCoW prioritization sessions
|
||||
|
||||
## Integration with Requirements Lifecycle
|
||||
|
||||
**When to Prioritize:**
|
||||
- After identifying epics (prioritize which epics to build first)
|
||||
- After creating user stories (prioritize which stories within an epic)
|
||||
- During sprint planning (prioritize tasks for the iteration)
|
||||
- During refinement (adjust priorities based on new information)
|
||||
|
||||
**Updating GitHub Projects:**
|
||||
- Set "Priority" custom field on issues
|
||||
- Apply priority labels
|
||||
- Order backlog by priority
|
||||
- Review and adjust regularly
|
||||
|
||||
Prioritization is an ongoing activity throughout the requirements lifecycle—use it to focus effort on what matters most and deliver maximum value incrementally.
|
||||
263
skills/prioritization/references/moscow-worksheet.md
Normal file
263
skills/prioritization/references/moscow-worksheet.md
Normal file
@@ -0,0 +1,263 @@
|
||||
# MoSCoW Prioritization Worksheet
|
||||
|
||||
Use this worksheet to systematically prioritize requirements using the MoSCoW framework.
|
||||
|
||||
---
|
||||
|
||||
## Prioritization Session Info
|
||||
|
||||
**Date:** [YYYY-MM-DD]
|
||||
**Facilitator:** [Name]
|
||||
**Participants:** [Names/roles of stakeholders involved]
|
||||
**Scope:** [What are we prioritizing? Epics for Q1? Stories for Sprint 5?]
|
||||
**Target/Goal:** [What are we trying to achieve? MVP? V1.0? Next release?]
|
||||
**Constraints:** [Time, budget, team size, deadlines]
|
||||
|
||||
---
|
||||
|
||||
## Decision Criteria
|
||||
|
||||
**Value to Users:** [Weight: High / Medium / Low]
|
||||
- Impact on user experience
|
||||
- Number of users affected
|
||||
- Frequency of use
|
||||
|
||||
**Business Value:** [Weight: High / Medium / Low]
|
||||
- Revenue impact
|
||||
- Strategic importance
|
||||
- Competitive advantage
|
||||
|
||||
**Risk:** [Weight: High / Medium / Low]
|
||||
- Technical complexity
|
||||
- Uncertainty / unknowns
|
||||
- Market assumptions
|
||||
|
||||
**Effort:** [Weight: High / Medium / Low]
|
||||
- Time required
|
||||
- Resources needed
|
||||
- Technical dependencies
|
||||
|
||||
---
|
||||
|
||||
## Items to Prioritize
|
||||
|
||||
List all items (epics, stories, or tasks) that need prioritization:
|
||||
|
||||
| ID | Item Name | Description | Value | Risk | Effort | Dependencies |
|
||||
|----|-----------|-------------|-------|------|--------|--------------|
|
||||
| 1 | [Name] | [Brief desc]| H/M/L | H/M/L| H/M/L | [IDs] |
|
||||
| 2 | [Name] | [Brief desc]| H/M/L | H/M/L| H/M/L | [IDs] |
|
||||
| 3 | [Name] | [Brief desc]| H/M/L | H/M/L| H/M/L | [IDs] |
|
||||
|... | ... | ... | ... | ... | ... | ... |
|
||||
|
||||
---
|
||||
|
||||
## MoSCoW Classification
|
||||
|
||||
### Must Have (≤60% of items)
|
||||
|
||||
> Critical requirements without which the product cannot launch or function
|
||||
|
||||
| ID | Item Name | Rationale |
|
||||
|----|-----------|-----------|
|
||||
| [#]| [Name] | [Why this is absolutely essential] |
|
||||
| [#]| [Name] | [Why this is absolutely essential] |
|
||||
|... | ... | ... |
|
||||
|
||||
**Total Must Haves:** [Count] out of [Total] = [%]
|
||||
|
||||
---
|
||||
|
||||
### Should Have (~20% of items)
|
||||
|
||||
> Important requirements that significantly enhance value but can be deferred if necessary
|
||||
|
||||
| ID | Item Name | Rationale | Workaround if Deferred |
|
||||
|----|-----------|-----------|------------------------|
|
||||
| [#]| [Name] | [Why important but not critical] | [How users cope without it] |
|
||||
| [#]| [Name] | [Why important but not critical] | [How users cope without it] |
|
||||
|... | ... | ... | ... |
|
||||
|
||||
**Total Should Haves:** [Count] out of [Total] = [%]
|
||||
|
||||
---
|
||||
|
||||
### Could Have (~20% of items)
|
||||
|
||||
> Nice-to-have requirements that provide marginal value
|
||||
|
||||
| ID | Item Name | Rationale |
|
||||
|----|-----------|-----------|
|
||||
| [#]| [Name] | [Why nice to have but low priority] |
|
||||
| [#]| [Name] | [Why nice to have but low priority] |
|
||||
|... | ... | ... |
|
||||
|
||||
**Total Could Haves:** [Count] out of [Total] = [%]
|
||||
|
||||
---
|
||||
|
||||
### Won't Have (This Time)
|
||||
|
||||
> Requirements explicitly excluded from current scope
|
||||
|
||||
| ID | Item Name | Rationale | Future Consideration? |
|
||||
|----|-----------|-----------|----------------------|
|
||||
| [#]| [Name] | [Why not now] | [When might we revisit?] |
|
||||
| [#]| [Name] | [Why not now] | [When might we revisit?] |
|
||||
|... | ... | ... | ... |
|
||||
|
||||
**Total Won't Haves:** [Count] out of [Total] = [%]
|
||||
|
||||
---
|
||||
|
||||
## Sequencing Within Categories
|
||||
|
||||
### Must Haves - Execution Order
|
||||
|
||||
Ordered by dependencies, risk, and value:
|
||||
|
||||
1. [Item name] - [Reason for sequence position]
|
||||
2. [Item name] - [Reason for sequence position]
|
||||
3. [Item name] - [Reason for sequence position]
|
||||
...
|
||||
|
||||
### Should Haves - Execution Order
|
||||
|
||||
1. [Item name] - [Reason for sequence position]
|
||||
2. [Item name] - [Reason for sequence position]
|
||||
...
|
||||
|
||||
### Could Haves - Execution Order
|
||||
|
||||
1. [Item name] - [Reason for sequence position]
|
||||
2. [Item name] - [Reason for sequence position]
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
## Validation & Sanity Checks
|
||||
|
||||
### Distribution Check
|
||||
|
||||
- **Must Haves:** [%] (Target: ≤60%)
|
||||
- **Should Haves:** [%] (Target: ~20%)
|
||||
- **Could Haves:** [%] (Target: ~20%)
|
||||
- **Won't Haves:** [%]
|
||||
|
||||
**Is distribution balanced?** [Yes / No]
|
||||
**If no, what needs adjustment?** [Notes]
|
||||
|
||||
### MVP Viability Check
|
||||
|
||||
**Can we ship a viable product with just "Must Haves"?** [Yes / No]
|
||||
|
||||
**Does it deliver core value?** [Yes / No]
|
||||
|
||||
**Would users pay for / use it?** [Yes / No]
|
||||
|
||||
**Are all critical user journeys covered?** [Yes / No]
|
||||
|
||||
### Dependency Check
|
||||
|
||||
**Are all dependencies respected in sequencing?** [Yes / No]
|
||||
|
||||
**Any items prioritized high that depend on low-priority items?** [List if any]
|
||||
|
||||
### Stakeholder Alignment
|
||||
|
||||
**Have key stakeholders reviewed and approved?** [Yes / No]
|
||||
|
||||
**Any major disagreements?** [Notes]
|
||||
|
||||
**Consensus achieved?** [Yes / No]
|
||||
|
||||
---
|
||||
|
||||
## Decisions & Trade-offs
|
||||
|
||||
Document key decisions and trade-offs made during prioritization:
|
||||
|
||||
**Decision 1:**
|
||||
- **What:** [What was decided]
|
||||
- **Rationale:** [Why]
|
||||
- **Trade-off:** [What was sacrificed or deferred]
|
||||
|
||||
**Decision 2:**
|
||||
- **What:** [What was decided]
|
||||
- **Rationale:** [Why]
|
||||
- **Trade-off:** [What was sacrificed or deferred]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
## Action Items
|
||||
|
||||
**Immediate Actions:**
|
||||
- [ ] Update GitHub Projects with priority labels
|
||||
- [ ] Update custom "Priority" field on all issues
|
||||
- [ ] Order backlog by priority
|
||||
- [ ] Communicate prioritization to team
|
||||
- [ ] Begin work on first "Must Have" item
|
||||
|
||||
**Follow-up Actions:**
|
||||
- [ ] Schedule re-prioritization review [Date]
|
||||
- [ ] Gather user feedback on priorities [Date]
|
||||
- [ ] Re-assess "Won't Haves" for future releases [Date]
|
||||
|
||||
---
|
||||
|
||||
## Notes & Comments
|
||||
|
||||
[Any additional notes, context, or discussion points from the prioritization session]
|
||||
|
||||
---
|
||||
|
||||
## Revision History
|
||||
|
||||
| Date | Change | By |
|
||||
|------|--------|-----|
|
||||
| [YYYY-MM-DD] | Initial prioritization | [Name] |
|
||||
| [YYYY-MM-DD] | Re-prioritized based on user feedback | [Name] |
|
||||
| [YYYY-MM-DD] | Moved Item X from Should to Must | [Name] |
|
||||
|
||||
---
|
||||
|
||||
## Example: E-commerce MVP
|
||||
|
||||
**Scope:** Prioritizing epics for e-commerce platform MVP
|
||||
**Target:** Launch in 3 months with core functionality
|
||||
**Constraints:** 2 developers, limited budget
|
||||
|
||||
### Must Have (5 epics)
|
||||
|
||||
1. **Product Catalog** - Cannot sell without products
|
||||
2. **Shopping Cart** - Core functionality for purchases
|
||||
3. **Checkout & Payment** - Must be able to complete purchases
|
||||
4. **User Accounts** - Track orders, save preferences
|
||||
5. **Order Management** - Sellers need to fulfill orders
|
||||
|
||||
### Should Have (3 epics)
|
||||
|
||||
6. **Product Search & Filtering** - Important for UX, but can browse categories initially
|
||||
7. **Email Notifications** - Enhances experience, but can manually check orders
|
||||
8. **Product Reviews** - Builds trust, but not critical for launch
|
||||
|
||||
### Could Have (3 epics)
|
||||
|
||||
9. **Wishlist** - Nice feature, low priority
|
||||
10. **Product Recommendations** - Enhances discovery, not essential
|
||||
11. **Social Sharing** - Marketing feature, not core
|
||||
|
||||
### Won't Have (4 epics)
|
||||
|
||||
12. **Mobile App** - Web-first strategy, mobile later
|
||||
13. **Loyalty Program** - Phase 2 feature
|
||||
14. **Multi-vendor Support** - Single vendor for MVP
|
||||
15. **International Shipping** - Domestic only for MVP
|
||||
|
||||
**Distribution:** 5 Must (45%), 3 Should (27%), 3 Could (27%) = Balanced ✓
|
||||
|
||||
**MVP Viable:** Yes - Can sell products, accept payment, fulfill orders ✓
|
||||
|
||||
**Sequence:** Product Catalog → Shopping Cart → Checkout → User Accounts → Order Management
|
||||
Reference in New Issue
Block a user