TL;DR: Identify what happens if each request waits, separate immediate incidents from planned work and present the capacity conflict to the decision owner. Make the chosen order and the consequences of deferral visible to the people relying on the work.
How to approach it
Explain how you verify urgency without requiring every requester to produce a revenue estimate. Distinguish a priority label from the consequence it represents. Use a concrete collision to show how your method produces a decision.
A strong answer
Start by checking for work that needs immediate incident or specialist triage. A credible security report may be poorly quantified and still require prompt attention. Route that assessment to the appropriate owner rather than sending it to the bottom of the backlog because its cost of delay is unknown.
For planned work, ask what outcome is affected, when the consequence begins and what workaround exists. Identify external dependencies and the latest time a decision can preserve an option. A task due next Friday might need action today because its approval takes several days.
Use this fictional sprint exercise. After existing commitments, a platform team has six engineer-days available. Three requests arrive:
| Request | Work estimate | Consequence and timing |
|---|---|---|
| Repair a failing backup verification job | Two days | Recovery evidence is missing; current backup usability is uncertain |
| Add a customer demonstration environment | Three days | Demonstration in five days; a shared environment might suffice |
| Reduce nightly log-storage cost | Three days | Ongoing expense; no stated near-term service failure |
Eight days of estimated work do not fit into six. The table is a starting point rather than an automatic ranking. Investigate the backup risk promptly: a reporting bug with verified usable backups differs from discovering that restore attempts fail. Check whether the demonstration workaround meets its data and access requirements. Quantify the log cost if a large commitment or storage limit creates an earlier consequence than the requester stated.
Suppose the exercise confirms that restore verification is broken, the existing backup is not yet proven unusable, and the approved shared environment can serve the demonstration with one day of preparation. Recommend two days to repair and run the restore check, one day for the demonstration and three days for log work only if the investigation stays bounded. Keep a decision checkpoint after the restore check; a failed recovery may displace the remaining work.
This recommendation changes scope using evidence. It does not make six days of capacity absorb eight by asking people to work faster. If the demonstration truly needs three days and all requests remain necessary, present the deferral choice to the authorized owner. Show what waits and who must be informed.
Use estimates from the same team and basis. Story points from different teams are not directly comparable engineer-days, and neither is a precise promise. Reserve capacity for unplanned work using the team's actual interruption history and service obligations rather than assuming a universal twenty-percent rule.
Record the accepted order and revisit it when material facts change. If a new incident arrives, explain which planned item moves and the effect on its stakeholder. A visible queue supports this conversation, but a tool alone cannot assign authority or settle conflicting business priorities.
If accepted demand repeatedly exceeds capacity, raise the operating constraint. Options include reducing supported scope, adding capacity or accepting longer lead times. Reordering the same impossible plan every sprint can hide that decision from the people responsible for making it.
What interviewers probe next
“Your manager's request is in the queue.” Use the same evidence and state their decision authority. A strategic priority can legitimately win, but record what it displaces instead of retrofitting an invented impact score.
“There is not enough data to rank a request.” Assign a bounded investigation proportional to its consequence and urgency. Missing information can itself be the next task; it is not proof that the request is unimportant.
“What if requesters will not agree?” Summarize the unresolved tradeoff for the authorized decision owner, with your recommendation. Consensus is useful but is not a prerequisite for every priority decision.
Common mistakes
An elaborate scoring formula can make uncertain inputs look objective. Keep the assumptions visible and use the score as a discussion aid.
Silently dropping a task leaves its dependency owners planning against a false commitment. Notify them when the decision changes, with the next checkpoint or revised date.