Prioritizing Requirements in Practice
In short Prioritization decides what gets built first and what you give up when time or money runs short. Wiegers and Beatty compare several techniques, criticize some popular ones, and recommend a value, cost and risk calculation for contested decisions.
Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed. (Microsoft Press, 2013), ch. 16.
On this page
Key ideas#
Why and when#
Priorities let you spend limited resources well and know in advance what to sacrifice. Because priority is relative, you can start as soon as you have two requirements. On agile projects, backlog prioritization never stops.
Citing Davis, the authors list what you need to know: customer needs, how important each requirement is to customers, the order in which capabilities should arrive, dependencies, groups of requirements that only make sense together, and the cost of each requirement.
Priority games#
Left alone, customers mark most requirements “high”. If everything ends up at one level, you have not prioritized. Watch for: - invented scales that avoid “low” (“high, very high, critical”); - “it’s in the spec, so we’ll build it”, which says nothing about when; - priority by volume (who shouts loudest) or by threat (who has the most power).
To make “low” easier to say, ask: Is there another way to meet this need? What happens if we drop or defer it? Is it worth delaying everything else at the same level? The authors cite Standish Group data suggesting that much delivered functionality is rarely or never used, an argument for cutting boldly.
Five techniques, simplest first#
| Technique | How it works | Good for | Watch out |
|---|---|---|---|
| In or out | Yes or no for this release | Long lists, quick decisions | No ranking among “in” items |
| Pairwise comparison | “If only these two existed, which matters more?” | Small sets, such as quality attributes | Unmanageable beyond a few dozen items |
| Importance × urgency | Important and urgent: high; important, not urgent: medium; neither: low | Most projects | Items that only feel urgent go to low or out |
| MoSCoW | Must, Should, Could, Won’t | Teams already used to it | The authors do not recommend it (see below) |
| $100 | Each person spreads 100 points | Forcing trade-off thinking | Easy to game; ignores cost |
The importance × urgency grid comes from Covey. For large sets, run it in passes: if the “high” group is too big, split just that group into three sub-levels, and repeat. Ranking every requirement individually is unnecessary, because products ship in releases, not one requirement at a time.
Wiegers and Beatty reject MoSCoW because it gives no ranking within a category and “Won’t” is ambiguous (not now, or never?). In practice it tends to collapse into “Must versus everything else”, since people learn that anything below Must rarely gets built. A relative of the $100 test, Beatty and Chen’s objective chain, estimates each feature’s actual monetary contribution to a business objective instead of using imaginary money.
Value, cost and risk#
For contested decisions, the authors recommend a spreadsheet method derived from Quality Function Deployment, which came out on top in a comparison of 17 techniques by Kukreja and colleagues that they cite. Customer representatives rate the benefit of having each feature and the penalty of not having it; developers rate cost and risk. Weighted benefit plus penalty gives value, and:
priority = value % ÷ (cost % + risk %)
Apply it only to discretionary items. Legal obligations and core business functions are mandatory and skip the exercise.
How to apply it#
- Agree on business objectives and who makes the final call.
- Compare items at one level of abstraction: features, use cases or functional requirements, never a mix.
- Pull out mandatory items.
- Use in/out or importance × urgency for the bulk; keep value, cost and risk for close calls.
- Check dependencies: an item that depends on a low-priority item is not really high.
- Keep paired operations (save and load, undo and redo) in the same release.
- When priorities tie, favor the needs of the most important user classes.
Example#
The Workshop, a fictional bike-repair chain, treats online booking as mandatory. Four other features compete for the first release. Ratings are 1 to 9. In this illustration the team weights benefit 2 and penalty 1, and leaves cost and risk unweighted. Each percentage is the item’s share of its column total.
| Feature | Benefit | Penalty | Cost | Risk | Value % | Cost % | Risk % | Priority |
|---|---|---|---|---|---|---|---|---|
| Email status updates | 5 | 3 | 2 | 1 | 20.3 | 11.8 | 7.1 | 1.07 |
| SMS status updates | 8 | 6 | 4 | 3 | 34.4 | 23.5 | 21.4 | 0.77 |
| Parts reorder suggestions | 7 | 5 | 6 | 6 | 29.7 | 35.3 | 42.9 | 0.38 |
| Customer photo upload | 4 | 2 | 5 | 4 | 15.6 | 29.4 | 28.6 | 0.27 |
Email beats SMS because it is cheap and low-risk, so the team ships email first and SMS next. Parts suggestions have high value but high risk; a short technical experiment (a spike) could lower the risk score before the next round. Treat the numbers as a structured conversation, not a verdict.
Pitfalls#
- Accepting “all high” → force a spread or run another pass on the top group.
- Mixing epics with small requirements → compare at one level.
- Letting the loudest stakeholder decide → tie every priority to a business objective.
- Treating priorities as permanent → revisit them every release.
Sources and further reading#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 16 (including the authors’ references to Davis, Covey, Beatty and Chen, Kukreja et al., and Standish Group).