# Prioritization

A method for ordering a project's tasks when every one looks important and dependency edges alone do not decide the sequence. `BLOCKS` relationships say what *must* come before what; they say nothing about what *should* come first among tasks that are all ready. This reference supplies a named framework for that choice and reflects the result in how tasks are created and noted — no schema change.

## When dependency order is not enough

`work-ready` returns the set of tasks with no unresolved blockers. When that set has one item, the choice is made. When it has many, the operator needs a way to rank them. Pick one framework below to fit the project; do not mix them within a single project.

### RICE

Score each task on Reach (how many people or cases it touches), Impact (how much it moves the outcome), Confidence (how sure you are of the first two), and Effort (how much work it takes). Rank by `(Reach × Impact × Confidence) ÷ Effort`. Use RICE when tasks vary widely in both benefit and cost and you want a single comparable number.

### ICE

A lighter RICE: score Impact, Confidence, and Ease (the inverse of effort), each on a simple scale, and rank by their product. Use ICE for a quick ranking when full RICE scoring is more precision than the project warrants.

### MoSCoW

Sort tasks into Must have, Should have, Could have, and Won't have (this time). Use MoSCoW when the project has a fixed deadline and the real question is what to drop, not what to score — it makes the cut line explicit.

### Kano

Classify each task by how it affects satisfaction: basic expectations (their absence causes complaints, their presence is unremarkable), performance features (more is better), and delighters (unexpected, disproportionately appreciated). Use Kano when the project is about a client-facing result and you are deciding where extra effort earns the most goodwill.

## Graph termination

Prioritization changes the order work is created and started, and records the decision — it never leaves a free-standing ranked list.

- **Create or order tasks to reflect the ranking.** When building the project, create the higher-ranked work items first so they surface earlier; for an existing project, the ranking decides which ready task is started next via the normal `work-ready` flow.
- **Record the method and the resulting order as a note.** Append to the project with `project-update`, e.g. `[PROJECT:PHASE] Prioritized via RICE — top three: site survey, supplier quotes, deposit invoice`. This makes the reasoning auditable later and visible in `project-get`.

No new property or relationship is introduced — priority lives in creation order and the lifecycle note, not a schema field.

## Wiring

This method runs inside the Plan phase of `sprint.md`. Load it via `plugin-read` when a project has many tasks and dependency edges do not settle the sequence. It pairs with `stakeholder-map.md` in the same phase: stakeholder power often informs Impact.

## When to Use

- A Plan phase where many tasks are ready and the order is unclear.
- "Everything feels urgent — what do we do first?"
- "We can't do all of this before the deadline — what makes the cut?"
- A client project where you are deciding where to spend the extra effort.