What I do

• •Provide comprehensive guidance on the MoSCoW prioritization framework
• •Help categorize requirements into Must/Should/Could/Won't have categories
• •Offer decision frameworks and challenge questions for validation
• •Provide templates for JIRA tickets and project documentation
• •Guide teams through the step-by-step prioritization process
• •Identify common pitfalls and provide solutions

When to use me

Use this skill when you need to:

• •Prioritize project requirements or features
• •Create JIRA tickets with clear Conditions of Satisfaction
• •Plan sprints or product releases
• •Manage scope and prevent scope creep
• •Make resource allocation decisions with limited time/budget
• •Set and manage stakeholder expectations
• •Define minimum viable product (MVP) scope
• •Make trade-off decisions between competing features

How I work

I provide structured guidance through:

1. •Category Definitions - Detailed explanation of each MoSCoW category with characteristics and examples
2. •Decision Framework - Quick decision tree and challenge questions to validate categorizations
3. •Process Steps - Six-step process from gathering requirements to documentation
4. •Templates - Ready-to-use MoSCoW tables for different project types
5. •Best Practices - DO/DON'T lists and common pitfall solutions
6. •JIRA Integration - Specific guidance on using MoSCoW for Conditions of Satisfaction in tickets

MoSCoW Prioritization Framework

Overview

MoSCoW is a prioritization framework that categorizes requirements based on importance: Must have, Should have, Could have, and Won't have. Created by Dai Clegg at Oracle, it helps teams focus on what truly matters and prevents scope creep.

When to Use MoSCoW

• •Starting a new project or feature
• •Planning sprint backlogs
• •Managing stakeholder expectations
• •Preventing scope creep
• •Making resource allocation decisions
• •Facing time, budget, or resource constraints

The Four MoSCoW Categories

Must Have

Non-negotiable requirements. Without them, the project fails.

Key Questions:

• •Will the product work without this?
• •Is this a legal/compliance requirement?
• •Will the release be useless without it?
• •Does this define core functionality?

Examples:

• •User authentication for secure applications
• •Payment processing for e-commerce
• •Data encryption for healthcare (HIPAA)
• •Core CRUD operations

Red Flags:

• •Everything marked as "Must Have"
• •Must Haves exceed 60% of total scope
• •Vague Must Haves

Should Have

Important but not critical. Add significant value but can be delayed if necessary.

Key Questions:

• •Does it add significant value?
• •Can we launch without it and add later?
• •Would users notice and care if missing?
• •Can we implement a workaround?

Examples:

• •Third-party integrations
• •Personalized user experience
• •Advanced reporting capabilities
• •Multi-language support
• •Export to multiple formats

Red Flags:

• •Should Haves that stakeholders insist are Must Haves
• •Too many Should Haves (scope creep)
• •Should Haves that block other work

Could Have

Nice-to-have features that improve user experience but aren't essential.

Key Questions:

• •Would this be nice to have?
• •Does it improve experience but not core function?
• •Can we deliver this in a later iteration?
• •Is this more "wow factor" than necessity?

Examples:

• •Social media integration
• •Advanced customization (themes, layouts)
• •Gesture controls
• •Animations and transitions
• •Easter eggs or micro-interactions

Red Flags:

• •Could Haves taking too much time
• •Could Haves blocking Must Haves
• •Disagreement on Could vs. Should

Won't Have (This Time)

Items that aren't a priority for the current timeframe. Explicitly out of scope.

Key Questions:

• •Is this out of scope for current release?
• •Would this compromise overall strategy?
• •Is this too complex for available resources?
• •Does this conflict with current goals?

Examples:

• •Advanced AI features requiring extensive R&D
• •Features requiring unavailable infrastructure
• •Capabilities conflicting with product positioning
• •Features for different market segments

Importance: Prevents scope creep and manages stakeholder expectations.

MoSCoW Prioritization Process

1. Gather All Requirements

Collect from stakeholders, users, product vision, technical team, market analysis, and compliance needs.

2. Define Success Criteria

Agree on: What defines success? What are constraints? Who is the target audience? What is MVP?

3. Categorize Each Requirement

Work through questions for Must → Should → Could → Won't Have.

4. Validate and Balance

• •Must Haves: ~50-60% of effort
• •Should Haves: ~20-30% of effort
• •Could Haves: ~10-20% of effort
• •Won't Haves: Explicitly documented

5. Reach Consensus

Ensure all stakeholders agree. Resolve conflicts using business value, constraints, user impact, and data.

6. Document and Communicate

Create clear documentation with rationale, dependencies, and estimated effort.

MoSCoW Decision Framework

Quick Decision Tree

Is it legally required? → YES → Must Have
      ↓ NO
Does core functionality break without it? → YES → Must Have
      ↓ NO
Would users find product useless without it? → YES → Must Have
      ↓ NO
Does it add significant value AND can we delay? → YES → Should Have
      ↓ NO
Is it a nice enhancement but not essential? → YES → Could Have
      ↓ NO
Is it out of scope or too complex right now? → YES → Won't Have

Challenge Questions for Must Haves

1. •"What happens if we launch without this?"
2. •"Can we provide a workaround or manual process?"
3. •"Is this required by law or regulation?"
4. •"Would any users successfully use the product without this?"
5. •"Can this wait for a 1.1 release?"

If answers allow alternatives or delays, it's likely a Should or Could Have.

Integration with JIRA Tickets

Use MoSCoW for "Conditions of Satisfaction":

## Conditions of Satisfaction (MoSCoW)

### Must Have
- [ ] Critical requirement 1
- [ ] Critical requirement 2

### Should Have
- [ ] Important feature 1
- [ ] Important feature 2

### Could Have
- [ ] Enhancement 1
- [ ] Enhancement 2

### Won't Have (This Iteration)
- Out of scope item 1
- Out of scope item 2

The Must Have conditions become the basis for acceptance criteria.

Best Practices

DO

✅ Challenge every Must Have - Ensure it's truly essential ✅ Get stakeholder buy-in - Agreement prevents disputes ✅ Document rationale - Record why each decision was made ✅ Review regularly - Priorities shift as projects evolve ✅ Be realistic about effort - Consider team capacity ✅ Use data - Back decisions with research and analytics ✅ Consider dependencies - Some Should Haves may enable Must Haves

DON'T

❌ Don't make everything Must Have - Defeats the purpose ❌ Don't ignore Won't Haves - Explicit exclusions prevent scope creep ❌ Don't skip Should Haves - They often become quick wins ❌ Don't work in isolation - Involve the whole team ❌ Don't be rigid - MoSCoW is a guide, not a straitjacket

Common Pitfalls and Solutions

Pitfall 1: Too Many Must-Haves

Problem: Everything marked "Must Have" Solution: Challenge each with "Can we launch without this?"

Pitfall 2: Scope Creep via Should Haves

Problem: Too many Should Haves expand scope Solution: Allocate fixed percentage (60% Must, 20% Should, 20% Could)

Pitfall 3: Unclear Boundaries

Problem: Disagreement on categorization Solution: Use decision framework and document rationale

Pitfall 4: Ignoring Won't Haves

Problem: Features creep back without explicit exclusion Solution: Document Won't Haves clearly and communicate

Pitfall 5: Static Prioritization

Problem: MoSCoW set once and never revised Solution: Review during sprint planning and backlog grooming

Summary

MoSCoW prioritization helps teams:

• •Focus on what truly matters
• •Communicate priorities clearly
• •Prevent scope creep
• •Deliver value faster
• •Manage stakeholder expectations
• •Make difficult trade-off decisions

By categorizing into Must, Should, Could, and Won't Have, teams can:

1. •Identify minimum viable product
2. •Plan realistic releases
3. •Allocate resources effectively
4. •Set clear boundaries
5. •Make informed trade-offs

Remember: The goal isn't to eliminate Should or Could Haves, but to make informed decisions about where to allocate limited time and resources.

Additional Resources

For detailed examples, templates, and patterns by project type, see:

• •templates/ - Ready-to-use MoSCoW templates for JIRA and documentation
• •examples/ - Real-world examples and patterns by project type
• •REFERENCE.md - Complete reference guide with extended guidance

References

• •MoSCoW Prioritization Model: https://www.bitesizelearning.co.uk/resources/moscow-prioritisation-model
• •MoSCoW Method Overview: https://www.productplan.com/glossary/moscow-prioritization/
• •Dynamic System Development Method (DSDM): https://www.agilebusiness.org/