4 exercises — pushing back on mid-sprint feature requests, negotiating unrealistic deadlines, addressing scope creep, and offering minimum viable alternatives.
0 / 9 completed
1 / 9
A product manager adds a new feature request mid-sprint: "Can we also add CSV export to the reporting page? It's just one button." How do you respond?
Option C is a professional scope push-back because it does four things simultaneously:
1. Acknowledges the request as legitimate: "CSV export is a reasonable feature" — doesn't dismiss the PM's idea 2. Provides a concrete estimate: "2–3 days for a solid implementation" — makes the cost visible and specific, not abstract 3. Names the actual trade-off: "either push the dashboard refactor OR deliver both partially" — the PM didn't know this; now they do 4. Offers two specific paths: gives the PM a choice between two defined options — not "no", but "here are your options"
Why A fails: Accepting scope growth silently leads to incomplete deliverables with no visibility for the PM
Why B fails: "Can't change sprint scope" is a policy statement, not a negotiation — it treats the PM as an adversary
Why D fails: "Submit it in the backlog" is dismissive and ends the collaborative conversation
Scope push-back formula: Acknowledge validity → Give a concrete estimate → Name the trade-off → Offer two concrete paths
2 / 9
A stakeholder asks your team to add authentication to a microservice by end of next week. The honest estimate is 3 weeks. Which response best protects quality while negotiating the deadline?
Option C is a complete scope negotiation response that includes:
1. Education without condescension: "authentication isn't just adding a login form" — helps the stakeholder understand WHY the estimate is what it is, not just that it is what it is 2. Specific naming of what gets cut: "security review" — not vague "quality issues", but the specific component that gets skipped 3. Names the risk of cutting: "vulnerability risk" — connects the shortcut to a concrete consequence the stakeholder cares about 4. Offers a tiered option: "prototype by next week" vs. "production-ready in 3 weeks" — gives the stakeholder a real choice rather than a take-it-or-leave-it 5. Closing question that clarifies the actual need: "demo or production deployment?" — often stakeholders only need a demo and don't require production quality
Why A fails: "We'll try" without commitment is likely to result in incomplete work with no warning
Why B fails: "Can't be done" without explanation — the stakeholder doesn't know why
Why D fails: "Very complex" without specifics — vague; every engineer says their work is complex
Deadline negotiation formula: Explain the work components → Name what gets cut → Name the risk → Offer tiered options → Clarify the real deadline need
3 / 9
The scope of a project keeps growing ("scope creep"). After three new requirements have been added since kickoff, how do you address this with the stakeholder?
Option C handles scope creep with documented facts + clear impact + a collaborative solution path:
1. Documents the additions with specifics: Names each addition [A], [B], [C] — makes the scope change visible and concrete, not abstract 2. Quantifies the impact: "approximately 8 additional dev-days" — puts a number on the growth 3. Connects scope to plan consequences: "pushing the deadline OR reducing quality on original scope" — the stakeholder now sees the trade-off 4. Demonstrates collaborative intent: "I don't want to block progress" — positions this as help, not resistance 5. Offers two resolution paths: "revise timeline/budget" OR "prioritise additions and remove something" — not "no", but "here are the legitimate options" 6. Proposes a specific next step: "30-minute scope review this week" — moves the conversation toward a decision
Why A fails: "We can't continue like this" is an ultimatum without a solution, creates adversarial dynamics
Why B fails: "I can't keep accepting" uses "I" in a way that sounds personal, not professional
Why D fails: "Freeze scope immediately" is a command, not a negotiation
Scope creep formula: Document additions with names → Quantify dev-days → Connect to timeline/quality consequences → Two legitimate resolution paths → Specific next step
4 / 9
A PM asks your team to deliver a feature by Friday that realistically requires 2 more weeks. The PM says it's for an important client demo. Which response best balances the relationship and the delivery reality?
Option B uses the validate → honest constraint → minimum viable demo offer → clarify structure:
1. Validates the business need: "I understand the importance of this demo" — shows you're engaging with the business context, not just your dev capacity 2. States the honest constraint: "significant quality risk" — doesn't say "impossible", but makes the risk explicit 3. Offers a concrete alternative with specifics: Names the specific workflow that CAN be ready and explicitly names what CANNOT — no surprises on demo day 4. Closes with a clarifying question: "Would that work for the demo?" — puts the decision with the PM who has full business context
Why A fails: "We can't do it" is a refusal without an alternative — leaves the PM with nothing
Why C fails: "We'll do our best" is a commitment without clarity — the PM thinks it will be done; the engineer thinks they've hedged
Why D fails: Making assumptions about what the client will accept is not your decision to make — the PM owns that relationship
Tight deadline formula: Validate the business need → Honest constraint + risk → Specific minimum viable offer (with named exclusions) → Clarifying question
5 / 9
Sarah (the Lead Developer) is reviewing a pull request for a new user profile API endpoint. Another developer, David, has implemented the endpoint but hasn't documented the expected data format. Sarah comments: 'Could you please add JSDoc to this? It's crucial for understanding how to consume this API.' Which of the following responses from David best demonstrates an understanding of scope and requirements negotiation?
This scenario tests proactive communication. Option 2 demonstrates David recognizing the importance of documentation and acknowledging Sarah's request without immediately dismissing it. Options A and D show a lack of understanding about requirements and scope, while option C pushes back for justification – which is valid but less direct than David's response.
6 / 9
Mark (the Backend Engineer) receives a Slack message from Emily (the Product Owner): 'Hey Mark, we need to integrate with the new PaymentGateway API. Can you get that done ASAP? It's blocking the checkout flow.' Mark estimates it will take 5 days. Which response best addresses this request while managing expectations?
This tests proactive negotiation. Option 1 shows enthusiasm but doesn't address the urgency or potential scope. Option 2 is ideal – it acknowledges the request and immediately proposes a discussion about scope, preventing immediate over-commitment. Options A and D are passive and don't manage expectations.
7 / 9
You're writing the PR description for a new feature that adds rate limiting to your API. The description currently states: 'This commit implements rate limiting.' Which of the following additions would best demonstrate an understanding of scope and requirements negotiation, particularly regarding future changes?
The original description is too vague. Option 1 provides details about the implementation, which helps with understanding and future maintenance. Option 2 highlights potential future changes and considerations, demonstrating a proactive approach to scope management – crucial for long-term maintainability. Options A and D are incomplete and lack detail.
8 / 9
Liam (the DevOps Engineer) is presenting a technical update to the team: 'We've been running tests on the new microservice. We found some performance bottlenecks related to database queries and have implemented caching.' The Team Lead asks, 'What's the impact of this change on the overall system performance metrics?' Liam responds: 'It should improve response times by about 20% under normal load.' Which of the following best describes Liam's approach to scope and requirements negotiation?
This probes beyond just stating a result. Option 2 demonstrates Liam acknowledging the initial scope (fixing the bottleneck) but also offering to investigate further based on real-world usage – showing an understanding of ongoing monitoring and optimization. Options A and D are too simplistic, while option B is overly restrictive.
9 / 9
Chloe (the Product Owner) asks your team to build a new reporting dashboard showing daily active users (DAU). The existing dashboards are already heavily utilized and complex. After discussing with the engineering team, you estimate this will require 3 weeks of dedicated effort and could significantly impact other planned features. How do you respond to Chloe?
This tests assertive negotiation. Option 1 is accepting without considering impact. Option 2 directly addresses the scope implications and potential delays, framing it within the context of the existing roadmap - demonstrating clear communication about priorities and tradeoffs. Option A shows a lack of consideration for the team's workload, while option B offers a simplified solution (a lower-quality compromise).
What will I practise in "Scope & Requirements Negotiation"?
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.