Requirements Prioritization
How an analyst ranks scope and cuts a backlog under constraints — MoSCoW, RICE, Kano, weighted scoring, cumulative voting, and resolving conflicting-stakeholder priority calls.
9 questions
JuniorTheoryVery commonWhich requirement-prioritization methods do you know, and why prioritize at all?
Which requirement-prioritization methods do you know, and why prioritize at all?
You prioritize because time, budget, and people are limited — you can't build everything at once, so you order work by value against cost and ship the most valuable slices first. Common methods are MoSCoW, RICE, the Kano model, weighted scoring, and WSJF.
Common mistakes
- ✗Thinking prioritization is optional when the backlog exceeds capacity
- ✗Ordering purely by cost or effort and ignoring value
- ✗Confusing a prioritization method with an estimation technique
Follow-up questions
- →When would you switch from MoSCoW to a numeric method like RICE?
- →Who should be in the room when the backlog is prioritized?
MiddleDesignVery commonYour team's single backlog holds both new features and incoming bug reports, and every sprint the two compete for the same capacity. Product wants to keep shipping features; support escalates a stream of defects — some cosmetic, some blocking checkout for a slice of users. You have no separate bug budget, and stakeholders disagree on whether a given bug outranks a planned feature. Describe how you prioritize bug fixes against features in one ordered backlog: which inputs you gather for a bug (severity, user reach, frequency, workaround availability, SLA or regulatory exposure, revenue at risk), how you make a bug and a feature comparable on one scale, how you keep a steady flow of fixes without stalling the roadmap, and how you justify each ordering decision to product and support so that neither side feels ignored.
Your team's single backlog holds both new features and incoming bug reports, and every sprint the two compete for the same capacity. Product wants to keep shipping features; support escalates a stream of defects — some cosmetic, some blocking checkout for a slice of users. You have no separate bug budget, and stakeholders disagree on whether a given bug outranks a planned feature. Describe how you prioritize bug fixes against features in one ordered backlog: which inputs you gather for a bug (severity, user reach, frequency, workaround availability, SLA or regulatory exposure, revenue at risk), how you make a bug and a feature comparable on one scale, how you keep a steady flow of fixes without stalling the roadmap, and how you justify each ordering decision to product and support so that neither side feels ignored.
Put bugs and features in one backlog and score both on the same axes — value against cost. For a bug, gather severity, reach, frequency, workaround, and revenue or SLA risk, then rank its value against effort like a feature. Reserve steady capacity for fixes so quality holds.
Common mistakes
- ✗Blanket-ranking all bugs above all features, or the reverse
- ✗Scoring bugs and features on different, incomparable scales
- ✗Leaving no reserved capacity, so fixes never actually ship
Follow-up questions
- →How do you handle a cosmetic bug that a major client keeps escalating?
- →When does a recurring bug justify pausing the feature roadmap?
MiddleTheoryCommonWhat is the Kano model, which feature categories does it define, and how do you survey users for them?
What is the Kano model, which feature categories does it define, and how do you survey users for them?
The Kano model classifies features by their effect on satisfaction: Basic (expected; absence angers), Performance (more is better, linear), and Delighters (unexpected wow, not missed). You survey with a paired functional and dysfunctional question — present versus absent.
Common mistakes
- ✗Confusing Delighters (unexpected) with Basic (expected) features
- ✗Assuming more of a Basic feature keeps raising satisfaction
- ✗Surveying with a single question instead of the functional/dysfunctional pair
Follow-up questions
- →Why do today's Delighters decay into tomorrow's Basic expectations?
- →How large a sample do you need before Kano results are trustworthy?
MiddleTheoryCommonWhat is MoSCoW, what do its four buckets mean, and what is the trap in the Won't-have bucket?
What is MoSCoW, what do its four buckets mean, and what is the trap in the Won't-have bucket?
MoSCoW sorts scope into Must have (release fails without it), Should have (important, not vital), Could have (dropped first), and Won't have (out of scope now). The trap: Won't have means deferred, not rejected — a recorded scope decision.
Common mistakes
- ✗Stuffing everything into Must have, which defeats the method
- ✗Reading Won't have as permanent rejection rather than deferral
- ✗Treating MoSCoW as a numeric score instead of categorical buckets
Follow-up questions
- →How do you push back when the business marks every item Must have?
- →Where do you record Won't-have items so they resurface next release?
MiddleTheoryCommonHow does the RICE prioritization method compute a score, and what does each factor change in the ranking?
How does the RICE prioritization method compute a score, and what does each factor change in the ranking?
RICE = Reach × Impact × Confidence ÷ Effort. Reach is users affected per period; Impact is goal movement per user; Confidence discounts shaky estimates; Effort is person-time. The first three raise the score and Effort divides it down.
Common mistakes
- ✗Summing the factors instead of dividing by Effort
- ✗Forgetting Confidence, so optimistic guesses dominate
- ✗Treating RICE as categorical buckets rather than a numeric score
Follow-up questions
- →How do you keep Reach and Impact on comparable scales across teams?
- →What stops people from gaming their own Confidence estimates?
SeniorDesignCommonIn your MoSCoW session the business marks every single backlog item as Must have — nothing is Should, Could, or Won't. They insist the release cannot go live without all of it, yet the team's capacity covers maybe half. Pushing back once with the plain claim that they cannot have everything has already failed and dented trust. Describe exactly how you break the deadlock: how you re-frame what Must have really means (the release fails without it), the questions and techniques you use to force real trade-offs, how you make the cost of 'everything is Must' visible, how you get the group to re-rank without anyone feeling overruled, and what you do if they still refuse to differentiate the list at all.
In your MoSCoW session the business marks every single backlog item as Must have — nothing is Should, Could, or Won't. They insist the release cannot go live without all of it, yet the team's capacity covers maybe half. Pushing back once with the plain claim that they cannot have everything has already failed and dented trust. Describe exactly how you break the deadlock: how you re-frame what Must have really means (the release fails without it), the questions and techniques you use to force real trade-offs, how you make the cost of 'everything is Must' visible, how you get the group to re-rank without anyone feeling overruled, and what you do if they still refuse to differentiate the list at all.
Redefine Must have as 'the release genuinely fails without it', then test each against that bar — most fall out. Make the cost visible: show capacity versus the total and ask what ships if only half fits. Use forced ranking or a Must-have budget, and escalate only if they still refuse.
Common mistakes
- ✗Accepting an all-Must-have list and absorbing the overrun
- ✗Re-ranking silently instead of driving the business to choose
- ✗Ordering by cheapest effort rather than by real must-have status
Follow-up questions
- →What single question best forces a Must-have item to reveal itself?
- →How does a fixed Must-have capacity budget change the conversation?
SeniorDesignCommonIt is sprint planning. The engineering team wants the whole sprint for tech debt — a fragile module that breaks weekly and slows every change. The business owner wants that same capacity for a customer-facing feature promised to a big client this quarter. Both are adamant, capacity fits only one, and whichever you defer will feel deprioritized. You have to make the call and defend it. Describe how you prioritize tech debt against a revenue feature: how you translate the debt into business terms the owner can weigh, how you quantify the cost of delay on both sides, how you use a scoring or value-versus-effort view to compare them on one scale, and how you justify the final decision so both engineering and the business accept it rather than feeling overruled.
It is sprint planning. The engineering team wants the whole sprint for tech debt — a fragile module that breaks weekly and slows every change. The business owner wants that same capacity for a customer-facing feature promised to a big client this quarter. Both are adamant, capacity fits only one, and whichever you defer will feel deprioritized. You have to make the call and defend it. Describe how you prioritize tech debt against a revenue feature: how you translate the debt into business terms the owner can weigh, how you quantify the cost of delay on both sides, how you use a scoring or value-versus-effort view to compare them on one scale, and how you justify the final decision so both engineering and the business accept it rather than feeling overruled.
Translate the debt into business terms — the fragile module costs delivery speed and incidents — so it competes as value, not a 'techie ask'. Put both on one scale: estimate each side's cost of delay and score value against effort. Let the numbers and owner's risk appetite decide.
Common mistakes
- ✗Leaving debt as a 'techie ask' the business cannot weigh
- ✗Comparing the two on different scales instead of one shared one
- ✗Deciding by whoever argues hardest rather than by cost of delay
Follow-up questions
- →How do you put a number on the cost of delaying tech debt?
- →When is a timeboxed partial debt slice better than all-or-nothing?
MiddleTheoryOccasionalHow does weighted scoring work, and how do you choose the criteria so the result can't be gamed?
How does weighted scoring work, and how do you choose the criteria so the result can't be gamed?
Weighted scoring rates each item against several criteria (value, cost, risk, fit), multiplies each rating by that criterion's weight, and sums to one number. To resist gaming: fix the criteria and weights before scoring, keep them few and independent, and score as a group.
Common mistakes
- ✗Setting weights after seeing the scores, which invites gaming
- ✗Using many overlapping criteria that double-count the same thing
- ✗Letting one person score alone instead of a cross-functional group
Follow-up questions
- →How do you handle a criterion measured in different units per item?
- →When does weighted scoring add more overhead than it is worth?
MiddleTheoryOccasionalWhat is WSJF and cost of delay, and when does it beat MoSCoW?
What is WSJF and cost of delay, and when does it beat MoSCoW?
WSJF (Weighted Shortest Job First) ranks work by cost of delay divided by job size, so costly-to-delay, quick jobs go first. Cost of delay is the value lost per unit of time an item waits. It beats MoSCoW when everything is Must have and you need a numeric tiebreaker.
Common mistakes
- ✗Multiplying by job size instead of dividing by it
- ✗Reading cost of delay as money already spent, not value lost over time
- ✗Thinking WSJF is categorical like MoSCoW rather than numeric
Follow-up questions
- →How do you estimate cost of delay when the revenue impact is unclear?
- →Why does WSJF favour splitting a large item into smaller ones?
