Techniques BABOK Guide v3, 10.33
Prioritization
In short Prioritization gives stakeholders a structured way to decide what matters most when they cannot have everything at once. You agree on criteria such as value, cost, and risk, apply a method that fits the situation, and end up with an order of work that everyone can defend.
Based on: IIBA, BABOK® Guide v3, technique 10.33 “Prioritization”; Watermark Learning, BABOK v3 Study Tables, section 10.33; K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 16; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 9–10.
On this page
What it is#
The BABOK Guide describes prioritization as a framework that helps stakeholders decide the relative importance of business analysis information: requirements, features, risks, options. The basis can be value, risk, difficulty of implementation, or any other criterion stakeholders care about. The guide names four approaches:
- Grouping — sort items into categories such as high, medium, and low.
- Ranking — put items in a single ordered list from most to least important.
- Time boxing or budgeting — decide what fits into a fixed amount of time or money.
- Negotiation — reach agreement among stakeholders with competing interests.
Methods to choose from#
- In or out. A yes/no decision per item for this release. Fast for long lists, but gives no order among the items you keep (Wiegers and Beatty).
- Pairwise comparison and ranking. Compare items two at a time. It becomes unwieldy beyond a few dozen items, and Wiegers and Beatty call ranking every single requirement unnecessary, since releases ship in batches.
- Importance and urgency. A two-by-two grid that Wiegers and Beatty borrow from Covey: important and urgent is high; important but not urgent is medium; neither is low. Items that seem urgent but are not important should be lowered or dropped.
- MoSCoW. Must have, Should have, Could have, Won’t have this time. The BCS book, drawing on the DSDM method, ties the categories to increments: Musts go in the first increment, Shoulds may slip to the next, Coulds act as a buffer, and Won’ts are consciously deferred. Wiegers and Beatty are critical: MoSCoW gives no order within a category, “Won’t” is unclear (this release or never?), and in practice it often collapses into “Must” versus everything else.
- Hundred-point method. Each participant spreads 100 points across the items. It forces trade-offs, but people can game it by putting all their points on a favorite, and it ignores cost.
- Value, cost, and risk. Wiegers and Beatty’s analytical method, based on Quality Function Deployment (QFD): customers rate the benefit of having each item and the penalty of not having it; developers rate its cost and risk. Priority = value ÷ (cost + risk).
When to use it#
The study tables link the technique to 5.3 Prioritize Requirements and 8.5 Recommend Actions to Increase Solution Value. Use it whenever demand exceeds capacity: before each release or iteration, when a change request arrives, or when choosing which improvement to fund. Wiegers and Beatty point out that priorities are relative, so you can start as soon as you have two requirements; in agile work, ordering the backlog never stops.
What not to prioritize. Items that are mandatory, such as legal obligations or the core functions without which the product makes no sense, are in by definition. Wiegers and Beatty set them aside before applying their analytical method.
How to do it#
- Agree what you are prioritizing and at what level: features, user stories, or individual requirements. Wiegers and Beatty warn against mixing levels in one list.
- Agree the criteria and the decision makers. Who owns value? Who estimates cost and risk? Who settles ties?
- Set mandatory items aside.
- Pick a method that fits the number of items, the stakes, and how comfortable stakeholders are with numbers.
- Collect inputs: value from business stakeholders, cost and risk from the delivery team.
- Run the session. Facilitate the negotiation and record the reasons behind each decision.
- Check dependencies. A high-priority item that depends on a low-priority one will stall. Wiegers and Beatty also advise delivering paired functions, such as undo and redo, together.
- Challenge “everything is high”. Ask Wiegers and Beatty’s questions: is there another way to meet this need? What happens if we defer it? Is it worth delaying everything else with the same priority?
- Publish and revisit at every release or whenever goals, costs, or risks change.
Example#
The Workshop, a fictional chain of 12 bike-repair workshops, has six candidate features for its first release. Consent for marketing messages is a legal requirement, so it is in without scoring. The rest are scored from 1 to 9 (illustrative values):
| Feature | Benefit | Penalty | Value | Cost | Risk | Priority |
|---|---|---|---|---|---|---|
| Status notifications by SMS | 8 | 6 | 14 | 3 | 2 | 2.80 |
| Photo approval of extra work | 6 | 3 | 9 | 3 | 2 | 1.80 |
| Online booking | 9 | 7 | 16 | 6 | 4 | 1.60 |
| Parts pre-order from booking | 7 | 4 | 11 | 7 | 6 | 0.85 |
| Customer accounts with history | 4 | 2 | 6 | 5 | 3 | 0.75 |
| Loyalty discounts | 3 | 1 | 4 | 4 | 2 | 0.67 |
Online booking has the highest value but ranks third because it is costly and risky; notifications deliver a lot for little effort. The team takes the top three into release 1. The dependency check confirms that parts pre-ordering needs bike details from the booking form, so it goes to release 2 with a clear reason the owner can explain to workshop managers.
Common mistakes#
- Everything is “high” → Wiegers and Beatty note that if all items end up with roughly the same priority, you have not prioritized. Force a distribution, or split the “high” group again.
- Priority by volume or rank of who asks → use agreed criteria and record the reasons.
- Value only → include cost and risk from the delivery team.
- Mixing levels → compare features with features, stories with stories.
- Ignoring dependencies → check them before publishing.
- Subjective scoring → the study tables warn that prioritization becomes subjective without metrics and KPIs; tie value to business objectives.
- Team bias → the study tables note the project team can sway priorities, on purpose or not. Let business stakeholders own value and keep the process transparent.
- Stakeholders refuse to choose → the study tables flag this too; show the trade-off explicitly, for example with a fixed budget or time box.
- Prioritizing once → revisit regularly.
Template#
| ID | Item | Mandatory? | Benefit (1-9) | Penalty (1-9) | Value | Cost (1-9) | Risk (1-9) | Priority = Value / (Cost + Risk) | Depends on | Decision and reason |
|----|------|------------|---------------|---------------|-------|------------|------------|----------------------------------|------------|---------------------|
| | | | | | | | | | | |
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Technique 10.33 “Prioritization”.
- Watermark Learning. BABOK v3 Study Tables. 2016. (study aid for the BABOK Guide). Section 10.33.
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Ch. 16 (prioritization methods and their pitfalls).
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Ch. 9–10 (MoSCoW and increments).