When your requirements list is growing faster than the project budget, and three different stakeholders are each convinced their feature is the must-have that defines the whole programme, you need requirements prioritisation techniques that hold up under pressure. Not just a ranked list, but a structured, repeatable approach that you can defend in a steering committee, a sprint planning session, or a workshop where the room is about to turn on itself. This article covers the techniques I reach for most often, how to choose between them, and where things can go wrong even when you apply them correctly.
Before getting into the techniques themselves, it is worth being clear on what prioritisation is actually for. It is not about telling stakeholders their ideas are bad. It is about making transparent, evidence-based decisions on sequencing when time, budget, and capacity are finite. If you are also working out how to gather the requirements in the first place, this guide on how business analysts gather requirements is a useful complement to what follows here.
The Five Techniques Worth Knowing
There are dozens of prioritisation methods in circulation, but in practice most BA work comes down to a handful of techniques that suit different project contexts. Here is how they compare before I go into each one in detail.
| Technique | Best suited to | Stakeholder involvement | Time to apply |
|---|---|---|---|
| MoSCoW | Agile sprints, scope negotiation | High | Low |
| Kano Model | Product development, customer-facing features | Medium | Medium |
| Weighted Scoring | Complex backlogs with multiple competing criteria | Medium | Medium to High |
| 100-Dollar Test | Quick stakeholder preference mapping | High | Low |
| Analytic Hierarchy Process (AHP) | High-stakes decisions with complex trade-offs | Low to Medium | High |
MoSCoW Method
MoSCoW is the technique I use most frequently on time-boxed projects and in agile environments because it produces a shared language very quickly. Requirements are placed into four categories: Must have, Should have, Could have, and Won’t have for this delivery. The categories are not permanent judgements. A Won’t have this sprint is often a Should have next quarter, and making that explicit keeps stakeholders from feeling dismissed.
The practical challenge with MoSCoW is that every stakeholder initially wants everything in the Must have column. I ran a prioritisation workshop on a digital transformation project for a large public sector organisation I will call Organisation B. Fourteen stakeholders attended. Within twenty minutes, 68% of the requirements had been labelled Must have. The categories had become meaningless. I stopped the workshop, recalibrated by asking each stakeholder to imagine the system went live with only their Must haves and nothing else. Would the organisation actually fail? That single question cut the Must have list by half and made the rest of the session productive. The friction was real: the Head of Operations pushed back hard, arguing that their reporting module was operationally critical. We spent thirty minutes working through what “critical” actually meant before agreeing it belonged in Should have for the initial release, with a firm commitment to include it in release two.
Kano Model
The Kano Model approaches prioritisation from the perspective of customer satisfaction rather than business urgency. Requirements are classified into three zones: basic needs that users expect as standard and whose absence causes dissatisfaction, performance needs where more is always better, and excitement needs that users did not know they wanted but that delight them when delivered.
I find the Kano Model most useful when working on customer-facing products where the risk is building features that feel complete to the delivery team but fall flat with end users. The complication is that excitement features become basic needs over time as the market matures, so a Kano analysis done at project inception may need revisiting before release.
Weighted Scoring
Weighted scoring assigns a numerical value to each requirement based on a set of agreed criteria. Typical criteria include business value, implementation cost, delivery risk, regulatory compliance, and time sensitivity. Each criterion carries a weight that reflects its relative importance, and the final score for each requirement determines its position in the priority order.
This technique works well when you need an audit trail for your decisions, which is common in regulated environments. The weakness is that the weights themselves are a judgement call, and different stakeholder groups will argue for different weightings. I address this by running the weighting exercise as a facilitated group activity before scoring any individual requirement, so the framework itself has collective ownership before the results emerge. You can find a broader discussion of how to structure this kind of facilitated session in this article on BA facilitation skills.
100-Dollar Test
The 100-Dollar Test, sometimes called cumulative voting or dot voting with a budget, gives each stakeholder a hypothetical $100 to distribute across the requirements list in whatever way they choose. They can put $50 on one item and spread the rest, or allocate $10 across ten items. The aggregated distribution reveals where the group’s collective weight of preference actually sits, which is often different from what individual stakeholders say in a room together.
- Run it individually first. Ask stakeholders to complete their allocation privately before sharing results, otherwise early contributors anchor everyone else’s thinking.
- Use it to surface disagreement. When one stakeholder puts $40 on a requirement that others have ignored entirely, that gap is the conversation worth having.
- Combine it with MoSCoW. Use the 100-Dollar Test to rank within MoSCoW categories rather than across the entire list, which keeps the exercise manageable on large backlogs.
- Document the allocations. The individual breakdowns are as useful as the aggregate, because they show you whose priorities are outliers and why.
Analytic Hierarchy Process
AHP is the most rigorous technique on this list and the one I reach for least often in day-to-day BA work, but it earns its place on complex programmes where the cost of a wrong prioritisation decision is high. It works by making pairwise comparisons between requirements: for every pair, you ask which is more important and by how much on a structured scale. The results are then synthesised mathematically into a consistent priority ranking.
The value of AHP is that it forces explicit comparison rather than allowing people to rate everything highly in isolation. The cost is time. On a requirements list of thirty items, the number of pairwise comparisons becomes unwieldy quickly, so AHP is most practical when applied to a shortlist of high-stakes candidates rather than a full backlog.
Factors That Should Inform Every Prioritisation Decision
Whichever technique you use, the quality of your prioritisation depends on the quality of the inputs. These are the factors I consider before applying any scoring or categorisation method.
- Business value. How directly does this requirement contribute to the stated organisational objectives? Requirements that cannot be traced to a business goal are candidates for descoping before prioritisation even begins.
- Implementation cost. A high-value requirement that will consume 60% of the budget needs a different kind of scrutiny than one that can be delivered in a week.
- Delivery risk. Technical uncertainty, dependency on third parties, and integration complexity all affect whether a requirement should be tackled early or late regardless of its perceived value.
- Regulatory compliance. Non-negotiable legal or policy obligations sit outside the prioritisation framework in one sense, because they are not optional, but they still need to be sequenced intelligently within a delivery plan.
- Time sensitivity. Some requirements have external deadlines attached, such as a legislative change date or a contractual milestone. These constraints narrow the sequencing options regardless of relative value scores.
If you are working in an environment where requirements management is handled across multiple workstreams, it is worth pairing your prioritisation work with a solid requirements traceability matrix so that priority decisions remain visible as the project evolves and scope pressures mount.
A Worked Example: When the Prioritisation Was Challenged Mid-Project
On a systems replacement programme for a utility organisation I will call Organisation C, I led the requirements prioritisation process across four business units. We used weighted scoring as the primary technique, with criteria agreed upfront: business value (40%), risk of not delivering (30%), implementation cost (20%), and regulatory obligation (10%). The scoring was done collaboratively in a workshop, and we landed on a priority order that the steering group signed off.
Six weeks into delivery, the Head of Billing submitted a formal challenge to the priority ranking. Her team’s customer statement redesign had scored mid-table and was slated for phase two, but she argued that a regulatory update she had only recently been briefed on made it a phase one obligation. The friction was significant because the delivery team had already committed to a phase one scope, and reopening the priority list felt to them like scope creep dressed up as governance.
What resolved it was going back to the original weighted scoring model and re-running the regulatory obligation criterion for the statement redesign with the new information. The score shifted enough to move the requirement into phase one. We then had to identify what displaced it, which required a further negotiation with a different stakeholder group. It added two weeks to the planning cycle, but it produced a defensible outcome that held for the rest of the programme. The lesson I took from it is that the prioritisation framework needs to be treated as a living document with a defined change process, not a one-off exercise that closes when the workshop ends. This connects directly to the broader discipline of scope creep and governance, where the same principle applies: decisions made without a clear process for revisiting them tend to unravel under pressure.
Making Prioritisation Stick
The technique itself is rarely the hard part. What makes requirements prioritisation work in practice is the combination of a transparent process, documented rationale, and an agreed mechanism for revisiting decisions when circumstances change. I have seen well-constructed MoSCoW exercises collapse because nobody recorded why a particular requirement landed where it did, leaving the decision open to reinterpretation six months later. I have also seen weighted scoring models survive significant project turbulence because the criteria and weightings were agreed publicly and the audit trail was intact. Prioritisation is not a single workshop output. It is an ongoing analytical activity that runs for the life of the project, and the BA’s job is to hold the framework steady even when the pressure to abandon it is intense.
Frequently asked questions
What is the best requirements prioritisation technique for agile projects?
MoSCoW is the most commonly used technique in agile environments because it is fast to apply and produces a shared vocabulary that works well in sprint planning. It works best when stakeholders are coached to use the categories strictly, with Must have reserved for genuine delivery blockers only. Combining MoSCoW with the 100-Dollar Test can add useful nuance when ranking within categories.
How do you prioritise requirements when stakeholders disagree?
Start by agreeing the criteria for prioritisation before scoring any individual requirement, so the framework itself has collective ownership. Techniques like weighted scoring and the 100-Dollar Test surface disagreements in a structured way that makes them easier to resolve objectively. Documenting the rationale for every prioritisation decision is essential so that challenges can be addressed against the agreed criteria rather than through politics.
What factors should influence requirements prioritisation?
The most important factors are business value, implementation cost, delivery risk, regulatory compliance, and time sensitivity. Requirements that cannot be traced to a business objective should be questioned before prioritisation begins. Regulatory obligations are not always the highest priority in terms of value, but they may constrain sequencing options significantly.
What is the MoSCoW method in requirements prioritisation?
MoSCoW categorises requirements into Must have, Should have, Could have, and Won’t have for the current delivery scope. It is designed to help teams reach agreement quickly on what is genuinely essential versus desirable. The most common failure mode is allowing too many requirements into the Must have category, which defeats the purpose of the exercise.
How often should requirements priorities be reviewed during a project?
Priorities should be reviewed whenever there is a significant change in business context, budget, regulatory requirements, or project scope. Treating prioritisation as a one-off workshop output is one of the most common mistakes I see on mid-to-large programmes. A defined review trigger and a clear change process for the priority list will protect the integrity of decisions already made.
Try Ash, Your Virtual BA
If you have just worked through a prioritisation technique and now need to translate those ranked requirements into a structured document, Ash can help you move from priority list to properly written business or functional requirements without starting from a blank page. Ash understands BA methodology, asks the right questions to draw out the detail, and produces output that is ready to share with stakeholders and delivery teams. Try Ash Virtual BA and turn your prioritised requirements into a document that holds up to scrutiny.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.