git:20261004.cc33b37 to git:20261021.d128b5f

---

name: moscow-prioritization

description: "MoSCoW prioritization: categorize requirements into Must Should Could Won't tiers using failure-focused test. Apply for backlog refinement, feature prioritization, sprint planning, release scope decisions, rebalance Must tier, create Won't items with revisit dates, adjudicate stakeholder disagreements, produce decision log. Keywords: prioritization, backlog, refinement, sprint planning, release scope, rebalance, stakeholder, decisions, MVP, scope control."

allowed-tools: Read, Write, Edit, Bash

---

# MoSCoW Prioritization

## When to Use

Use this skill when you need to rank requirements for a release.

## When Not to Use

Do not use this skill for task-level estimation, bug triage, or sprint capacity planning by itself.

## Principles

1. `Must` means release failure if missing.

2. `Should` means high value but deferrable.

3. `Could` means optional enhancement.

4. `Won't` means explicitly out of scope for this release.

## Deterministic Workflow

1. Collect candidate requirements in one list.

2. Confirm release constraints (date, budget, team).

3. Categorize each item with the decision tree in `references/categorization-decision-tree.md`.

4. Challenge every `Must` using failure-focused questions.

5. **Validate:** Verify that the `Must` count does not exceed 60% of total effort before proceeding.

6. Rebalance if `Must` work exceeds 60% of effort. If rebalancing cannot bring `Must` under 60%, escalate to stakeholders to either re-scope the release (split into two releases, extend the timeline, or increase capacity) before finalizing categories.

7. Publish final table with owners and review date.

## Quick Commands

### Create a workshop draft

```bash

cp skills/moscow-prioritization/references/facilitator-workshop-template.md .context/moscow-workshop-draft.md

```

Expected result: reusable working document for prioritization.

### Create a decision log

```bash

cat > .context/moscow-decisions-$(date +%Y-%m-%d).md <<'MD'

# MoSCoW Decision Log

| Requirement | Category | Rationale | Owner |

| --- | --- | --- | --- |

MD

```

Expected result: traceable decisions with ownership.

### Validate skill quality after edits

```bash

```

Expected result: updated score and grade for this skill.

### Lint this skill documentation

```bash

rumdl check skills/moscow-prioritization

```

Expected result: no rumdl errors.

## Anti-Patterns

### NEVER label stakeholder preference as `Must`

- **WHY:** Preference is not the same as release-critical need.

- **BAD:** "Executive asked for dark mode, so it is Must."

- **GOOD:** "Dark mode is Should unless release fails without it."

- **Consequence:** `Must` list inflates and blocks true essentials.

### NEVER skip explicit `Won't` items

- **WHY:** Missing exclusions invite silent scope creep.

- **BAD:** Keep backlog open-ended with no rejected items.

- **GOOD:** Record rejected items with revisit date.

- **Consequence:** Team repeatedly reopens settled decisions.

### NEVER finalize priorities without constraint checks

- **WHY:** Categories are invalid without timeline and capacity context.

- **BAD:** Categorize before confirming release limits.

- **GOOD:** Validate date, staffing, and budget first.

- **Consequence:** Plans collapse during execution.

### NEVER keep categories without rationale

- **WHY:** Unjustified categories cannot be defended or audited.

- **BAD:** Spreadsheet with only item and category.

- **GOOD:** Include business outcome and risk rationale.

- **Consequence:** Priorities are re-litigated in every review.

## References

- `references/categorization-decision-tree.md`

- `references/facilitator-workshop-template.md`

- `references/effort-balancing-and-tradeoffs.md`