Requirements Prioritization Scenarios
Part of the Business Analyst Roadmap
In short
'You have 10 requirements and time for 4. What do you do?' A good answer shows a method, not a gut feeling, and shows you know prioritisation is agreed with stakeholders, not done alone.
'You have 10 requirements and limited time, how do you prioritize?' — testing structured, evidence-based prioritization using frameworks like MoSCoW from Phase 3.
Think of it like this
Packing the hostel suitcase
The airline allows 15 kg. Mum wants pickle jars, you want your speaker, and the books are heavy. You sort it: must take, should take, nice to have, leave behind. Then you weigh it. That's MoSCoW with a hard limit.
Watch it happen
Answer structure for prioritisation scenarios
1/5Anchor to the goal: 'First I'd confirm what this release must achieve, like launching before admissions.'
The big ideas
What you need to know
Goal first
Without a clear goal, every requirement looks important. The goal is your tie-breaker.
Name a framework
MoSCoW for quick buckets, value vs effort for a 2x2 view, WSJF when cost of delay matters.
Mandatory beats popular
Legal and regulatory requirements usually go to the top, however unexciting they are.
Communicate the 'no'
Explain what happens to deprioritised items. Stakeholders accept 'later' far more easily than silence.
See it in code
Walk through the code
1A: Requirement B: Value (1-5) C: Effort (1-5)2D2: =B2/C2 (value per unit of effort)3E2: =RANK(D2, D$2:D$11) (1 = do first)4F2: =IF(E2<=4, "This release", "Later")1/3Inputs: value from the business, effort from the team.
A quick value-to-effort sheet for 10 requirements. It's a conversation starter for stakeholders, not an automatic decision.
Save yourself the pain
Common mistakes
Oops
Saying 'I'd prioritise what the most senior stakeholder wants'.
Do this instead
Use an agreed method and data, then escalate genuine conflicts to the sponsor.
Oops
Forgetting dependencies, like login before profile.
Do this instead
Mention checking dependencies and technical risk before fixing the order.
Your mission
Prioritise ten features
Quick check
A low-value requirement is needed for a new data-protection rule. Where does it go?
Go deeper
- 1Practice prioritizing a sample list of requirements using MoSCoW, explaining your reasoning.
- 2Prepare to defend your prioritization against a stakeholder pushback scenario.
- 3Practice being decisive — a clear ranked list reads better than 'it depends' with no resolution.
More requirements & documentation at this stop
Requirements Gathering Scenario Questions
Documentation & Traceability Questions
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.
