# Decide the scope (MoSCoW)

This is the step where you agree with the stakeholder on "how far we build this time" out of the requests you collected.

![PM on Rails scope board. Cards in Must / Should / Could / Won't. Before: scope stayed verbal. After: you agree what you will not build before development starts.](https://pmonrails.com/docs-img/moscow.png)

![Scope-board video. Open a card to check its priority, then press confirm and a confirmation appears. Placing cards alone does not confirm scope; a confirm action is required.](https://pmonrails.com/docs-video/scope.webm)

## MoSCoW

| Category | Meaning | Colour |
| --- | --- | --- |
| Must | Without it, the thing doesn't work | Red |
| Should | Ought to be there, but not essential this time | Blue |
| Could | If there is room | Yellow |
| Won't | Out of scope this time | Grey |

- The layout has two panes: **the four categories on the left, the detail panel on the right**. Either **drag** a requirement card into one of the four columns, or re-select its MoSCoW value from the **panel on the right** that opens when you select a card. The scope you settle is saved.
- In the right-hand panel you can edit the three human judgement axes (business importance / ease of acceptance for users / ease of implementation) with stepped buttons. Impact and request frequency are display-only, shown as "AI observation (reference)".
- Cards show the judgement guides (score and priority) plus a "New / Changed" badge relative to the last time you looked. Internal AI values such as urgency and confidence are not shown.
- **Setting a card to "Won't" automatically makes the requirements created from that request "out of scope"** too, so no requirements are left dangling.

> Being explicit about what you won't build this time does the most to prevent misaligned expectations.

## Adjusting priorities by hand

The initial values the AI assigned can be changed directly by people on screen. Selecting a requirement card slides a **detail panel** in on the right, and you adjust the priority and the judgement axes there.

![PM on Rails priority panel. Choose must through won't for one request. Before: priority was a feeling. After: the reason for the call stays on the card.](https://pmonrails.com/docs-img/priority-panel.png)

### Steps

1. Click a requirement card in the list and the detail panel opens on the right.
2. Check the content in the **overview** at the top (and go as far as the acceptance criteria with "Show details" if you need to).
3. Re-select the **priority (MoSCoW)** from "must / should / could / won't" (dragging the card into a column in the list does the same thing).
4. Adjust the **three human judgement axes** to what you agreed with the stakeholder.
5. Changes are saved automatically and are reflected immediately in the score and priority guides on the card.

### The axes you can adjust

| Axis | Meaning | Editing |
| --- | --- | --- |
| Business importance | How much value there is | Editable |
| Ease of acceptance for users | Whether people will actually use it | Editable |
| Ease of implementation | How easily it can be built | Editable |
| Impact | How far it ripples out | AI observed (display only) |
| Request frequency | How repeatedly it was asked for | AI observed (display only) |

- Moving the three axes (business importance, ease of acceptance for users, ease of implementation) recalculates the **overall score** from that combination, and updates the score and priority guides on the card.
- **The values the AI observed (impact, request frequency) cannot be changed.** They are a record of facts such as "how many times it was mentioned in discussion", not something to rewrite to taste. Human judgement goes in through the three axes above.

> Values you set by hand are not silently overwritten by a later AI recalculation. The priority you agreed with the stakeholder stays as it is.

## The two phases of priority

1. **AI extraction phase** — immediately after extraction from meeting notes, AI derives an initial priority.
2. **Agreement phase** — people settle the priority on this screen using the steps above. Values set by hand are not overwritten by automatic recalculation.

The AI's priority bar (a weighting of four axes) and the priority people decided can diverge. That is by design, and it flags the cards worth discussing. **For cards that diverge, leaving the basis you agreed on in a comment** lets you check "why did we set this priority?" later.

## Confirming the scope for this round

Once priorities are settled, choose "Confirm scope and create user stories" at the top of the screen, then confirm the action. **Saving priorities alone does not confirm the scope.**

Confirmation records the scope as it stands and starts generating drafts of user stories and verification steps. Follow progress in [Processing status and history](https://pmonrails.com/en/docs/jobs.md), then read and edit the results. To revise and confirm the scope again, first retract the current confirmation, adjust the scope, then confirm it again. The retracted record remains in the history.

## Next step

- [User stories and scenarios](https://pmonrails.com/en/docs/stories.md)

---

https://pmonrails.com/en/docs/scope