Why prioritisation is critical in agile projects
Every project has more requirements than time. Agile frameworks do not solve this problem by adding more resources — they solve it through consistent prioritisation. MoSCoW and the user story format are the most important tools for this.
The user story format
A user story describes a requirement from the perspective of the person using the product — not from a technical point of view.
Standard format
As a [role]
I want to [feature / goal]
so that [benefit / value]
Example
As a delivery driver
I want to scan delivery notes using my camera
so that I no longer need to fill in paper forms and save time at each stop.
Acceptance criteria
Every user story needs acceptance criteria — measurable conditions that define when the story is “done”.
- The scan reliably recognises barcodes and QR codes
- The result is saved in under 3 seconds
- If a read error occurs, a clear error message is displayed
Quality criteria: INVEST
| Letter | Word | Meaning |
|---|---|---|
| I | Independent | Story can be developed independently |
| N | Negotiable | Details can still be discussed |
| V | Valuable | Delivers measurable value |
| E | Estimable | Effort can be roughly estimated |
| S | Small | Fits within one sprint / timebox |
| T | Testable | Has clear acceptance criteria |
MoSCoW prioritisation
MoSCoW is a prioritisation method embedded in the AgilePM® framework. It distinguishes four categories:
| Category | Meaning | Rule of thumb |
|---|---|---|
| Must have | Without this feature the release has no value | ≤ 60 % of the total project effort |
| Should have | Important but can be deferred if necessary | Buffer for Must-haves |
| Could have | Nice-to-have, delivered if time permits | Scope buffer |
| Won't have | Explicitly excluded from this release | Manages expectations |
Timeboxing and MoSCoW working together
MoSCoW only works in combination with timeboxing: the timebox (time and budget) is fixed. What gets delivered within that timebox is governed by MoSCoW. When time runs short, Could-haves are dropped first — then Should-haves. Must-haves must always be delivered; otherwise the release should be postponed.
Common MoSCoW mistakes
- Too many Must-haves: If everything “must” be done, there is no flexibility. Rule of thumb: ≤ 60 % of the total project effort
- Forgetting Won't-haves: Clear exclusions prevent scope discussions later
- Priority without context: MoSCoW categories must always be tied to a specific timebox / release
Eighty per cent of the requirements in your backlog are classified as Must have. Why is that not a sign of clarity?
Answer it yourself first — then compare.
Key takeaways
- User stories formulate requirements from the user's perspective — not from a technical point of view
- INVEST criteria ensure the quality of each user story
- MoSCoW makes scope explicitly prioritisable and enables timeboxing
- Must-haves should occupy at most 60 % of the total project effort