How to … prioritize requirements
Delivering a software product without compromising quality may mean that some of the scope has to be postponed until a later time or left out completely. Effective prioritization and reprioritization during a project is the key to delivered within time and cost, without compromising quality.
Requirements are features, functionality, improvements that the business wants. As projects are under budgetary pressures, some requirements might be descoped.
Prioritizing requirements
There are many ways to prioritize requirements such as:
- Assign numbers from 1 (most important) to 5 (least important)
- Assign High, Medium, Low categories
- Assign Showstopper, Highly Desirable, Desirable categories
- Use MoSCoW (Must Have, Should Have, Could Have, Won’t Have) — where the Must Have requirements represent the MVP
- Use Kano model
- Use WSJF
MoSCoW
The use of this technique provides the clear indication of the importance of a requirement and the expectation for its completion.
The omission of one of the requirements classified as Must Have means that the project has failed to meets its minimum level: it is not legal/safe/not a viable solution/no point in delivering it at the target date.
Should Have requirements are important, but not vital, as the solution is still viable, however it may need some workaround.
The distinction from a Should Have to a Could Have implies assessing the pain of leaving the requirement unfulfilled, measured in terms of business impact or number of affected users. Could Have requirements are less important than Should or Must Haves, however they are still wanted or desirable. If a problem occurs and the project delivery is at risk, the Could Have represent the main pool of contingency — you can drop requirements from here.
Won’t Have requirements will not be developed nor delivered in the Sprint/quarter etc., but they might be at a later date, therefore it is important to keep them in the list of requirements.
In order to deliver the MVP, a maximum of 60% of the estimated effort should be for Must Have, and the rest for Should and Could Have. If more than 60% of the effort is dedicated to Must Have, it is a risk of not meeting the MVP. A 20% pool of contingency is needed in case of unexpected.
Take into consideration any dependences between requirements. Sometimes a lower priority requirement may need to be included to enable a Must Have to work, therefore it should be higher prioritized.
Kano
The level of customer expectation might help prioritize requirements as well. The Kano model takes into consideration the following types of customer need:
- basic needs (“will”) — e.g The car will have an engine.
- performance needs (“want”)—e.g I want a car with average fuel consumption.
- delighters (“wow”)—e.g This car will never break down.
There are also two dimensions of value:
- reality — addressing the need (scale 0–100%)
- perception — satisfaction (scale 0–100%)
Below is the Kano Model, as per https://dmexco.com/stories/kano-model/.
Over time with the maturity of a product, wows become wants, and wants eventually become wills. For example, the touch screen was once a wow, but now it is more like a will.
The Kano model can be used along with MoSCoW, to help define the MVP and the Should, Could and Won’t Have requirements.
WSJF
Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs (eg., Features, Capabilities, and Epics) to produce maximum economic benefit. It is used in Scaled Agile Framework (SAFe).
As a formula, WSJF is the Cost of Delay (CoD) divided by the job size (duration). CoD represents the sum of:
- user/business value: revenue or potential negative impact, preference
- time criticality: deadlines, if customer satisfaction is affected if delayed
- risk reduction or new business opportunities if delivered
Tips and tricks
- Agree what the priorities mean early in the project
- Control the number of the Must Haves by taking into consideration project schedule and the MVP
- Keep the prioritization visible, so that it won’t be any confusion regarding what needs to be delivered
- If you use WSJF, set the values collaboratively with the team members/stakeholders. Some requirements might feel like they provide more business value/opportunity/time criticality from one perspective to another.
