4 exercises — responding to "everything is P1", handling conflicting priorities, escalating priority conflicts between stakeholders, and making the case for a priority change.
0 / 9 completed
1 / 9
Your PM says: "Everything on the backlog is P1. Can you just do all of it?" How do you respond?
Option C responds to the "everything is P1" problem by:
1. Acknowledging the legitimacy of each item: "every item matters" — not dismissive 2. Making the capacity constraint concrete: "3–4 items per sprint" and "12 items = ~6 sprints" — translates backlog volume into time so the PM sees the trade-off 3. Proposing a collaborative prioritisation process: "rank by business impact + dev effort" — structured, fast, and brings both parties' expertise 4. Creating a positive outcome: "commit to the top tier with confidence" — the PM gets certainty on the most important items
Why A fails: "We'll try" without a plan leads to all 12 items starting and none finishing
Why B fails: "Can't do everything" is a refusal without a path forward
Why D fails: "I need you to prioritise for me" puts the problem back on the PM without any value added from the engineer
2 / 9
A PM asks you to drop your current security fix and start a new UX feature immediately. How do you handle this conflicting priority?
Option C handles a conflicting priority request professionally:
1. Flags the consequence of switching, not just the inconvenience: "active SQL injection vulnerability unpatched for 24–48 hours" — connects the task switch to a real, specific risk 2. Returns the decision to the PM with full information: "Is the UX feature launch-blocking in a way that outweighs that risk?" — the PM is now making an informed decision, not an uninformed one 3. States the consequence if they say yes: "I'll switch and note the ticket as openly vulnerable" — no passive aggression; just transparency 4. Offers a compromise if they say no: "finish by end of day, start tomorrow" — reasonable, concrete, likely acceptable
Why A fails: Switching without flagging leaves a security vulnerability unpatched with no stakeholder awareness Why B fails: Refusal without reasoning Why D fails: Escalation when a simple conversation would resolve it — looks like avoidance
3 / 9
Two senior stakeholders disagree on the priority of two projects and are both asking your team to start immediately. How do you respond?
Option C escalates a prioritisation conflict professionally:
1. Names the structural problem: "both projects have been flagged as highest priority" — makes the conflict explicit without blaming either stakeholder 2. Quantifies the cost of multitasking: "both take approximately 3× longer" — not a guess; reflects the real cost of context-switching at team level 3. Refuses to make the decision unilaterally: "rather than my team deciding" — correctly identifies that priority decisions belong with the stakeholders who own the business context 4. Offers to support the decision process: "one-page brief with impact and timeline" — adds value instead of just escalating the problem
Why A fails: Passive — waits for them to resolve it when they may not even know the conflict exists
Why B fails: "Work on both" looks productive but actually slows both projects
Why D fails: Seniority is not a legitimate prioritisation criterion; it causes the more senior person's preferences to always win regardless of business value
4 / 9
You think the current sprint's top-priority feature is wrong — there's a critical infrastructure item that will block three future sprints if not addressed now. How do you raise this?
Option B is a strong priority challenge because it:
1. Names the specific ticket: "INF-112" — concrete, not vague 2. Names the downstream blockers specifically: Sprint 15 auth refactor, Sprint 16 notifications, Sprint 17 mobile API — not "it will cause problems later" but specific future tickets 3. Quantifies the cost of deferral: "6–9 days of avoidable blocked time" — business-language framing of a technical risk 4. Quantifies the cost of the fix: "3 days of work" — so the audience can compare 3 days now vs. 6–9 days later 5. Scopes the ask correctly: "one-time priority bump — not a permanent change" — shows you understand the concern about precedent-setting 6. Asks appropriately: "Could we discuss this in sprint planning?" — the right venue
Why C fails: Bare assertion without reasoning
Why D fails: Doing work without agreement is a classic scope/trust violation — even if the technical call is correct
5 / 9
Sarah (Lead Engineer) comments on your PR: 'This is a good start, but the performance implications of this approach haven't been fully considered. Could you investigate and provide some metrics?' How do you respond to Sarah's feedback?
This scenario tests acknowledging concerns without immediately dismissing them. The key here is to accept responsibility and propose further investigation. Option A is dismissive, option B avoids addressing the core issue, and option D is confrontational. Demonstrating willingness to explore performance metrics shows a collaborative approach, aligning with prioritization discussions.
6 / 9
You're drafting a PR description for a new API endpoint. The documentation states this endpoint is 'low priority' and should only be used in exceptional circumstances. Which phrasing best reflects this in the PR description?
The goal here is to accurately represent the documented priority. Option A overstates the value, option B highlights the risk appropriately, and option D misrepresents the situation. Honest communication about limitations is crucial for managing expectations during prioritization.
7 / 9
During a standup meeting, Mark (Product Owner) asks: 'Can you please start working on the new analytics dashboard? It's been requested by sales.' You realize that fixing a critical security vulnerability in the user authentication system is actually blocking several other features and will take approximately two sprint days. What do you say?
This tests asserting your priority based on impact. Option A ignores the critical vulnerability, option B simply states the facts without a proposed solution, and option D deflects responsibility. Clearly stating the blocking issue is essential for influencing prioritization decisions – demonstrating technical understanding is key.
8 / 9
You receive an email from a client: 'We absolutely need this feature delivered by Friday. It's critical for our upcoming marketing campaign.' You've just completed a complex refactoring of the codebase and are now facing significant technical debt. How do you respond to the client's request?
This scenario focuses on setting realistic expectations. Option A accepts an impossible request, option B directly addresses the issue and proposes a discussion, and option D avoids a direct answer. Managing client expectations is vital; a firm but polite response highlighting constraints demonstrates professionalism.
9 / 9
You're reviewing a colleague's code and leave a comment: 'This solution is technically correct, but it's not the most efficient. We should explore alternative approaches that optimize for performance.' How does your colleague likely react?
This tests anticipating potential responses to constructive criticism. Option A is a positive response, option B reveals a common reason for suboptimal decisions, and option D indicates confusion or defensiveness. Understanding the likely reaction helps frame your communication strategy – acknowledging constraints can be helpful in this situation.
What will I practise in "Prioritisation Language"?
This module focuses on Negotiation English — real workplace phrasing you'll use on the job. It contains 9 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 9 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Negotiation English exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around negotiation english — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Negotiation English exercises?
See the Negotiation English hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.