Scope Negotiation: Phrases for Managing Expectations
5 exercises on scope negotiation phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
A stakeholder wants to add a feature mid-sprint. You need to say it is out of scope without being dismissive. Which phrase works best?
Option B is the professional way to decline scope additions. 'That's out of scope for this sprint' is a factual boundary, not a personal refusal. 'Could we add it to the backlog and revisit in planning?' immediately offers a constructive path forward rather than a dead end. 'We can't do that' (A) sounds like a capability problem rather than a prioritisation decision. 'That's not happening this sprint' (C) is blunter and gives no next step. 'We don't have time for that' (D) sounds dismissive. Always pair a scope boundary with a path forward — 'not now, but here's when and how' keeps the relationship intact.
2 / 5
A full feature will take three weeks but you want to propose a faster, slimmer version. Which phrase is most effective?
Option D is the complete MVP proposal. It labels the approach ('lightweight version'), specifies what is and isn't included ('core read path without the filtering UI'), and states the benefit ('ship value faster'). 'We could do a simpler version' (A) is too vague — what is included and excluded? 'Let's not do the full thing' (B) proposes reduction without defining what remains. 'A basic version might work' (C) is non-committal and doesn't name the scope. Effective MVP proposals are specific about what is in scope, what is deferred, and what value is delivered by the lean version.
3 / 5
You want to understand what the minimum viable version of a feature needs to be. Which question is most useful?
Option A is the best question because it defines 'minimum' in terms of user value ('for this to be useful') rather than just technical simplicity. This grounds the conversation in outcomes. 'What's the simplest version?' (B) focuses on technical complexity rather than user value — you might build the simplest thing that is still useless. 'Can we cut some stuff?' (C) sounds like cost-cutting rather than principled scoping. 'What's the MVP here?' (D) is the right concept but too jargon-laden — stakeholders may have different mental models of MVP. Framing around usefulness keeps everyone aligned on purpose.
4 / 5
A stakeholder wants to add an export feature, which would require dropping the notification redesign. How do you explain this trade-off?
Option C is precise and respectful. It names both specific items (export feature, notification redesign), states the constraint clearly (need to drop), and explains why (both are substantial pieces of work). This gives the stakeholder the information needed to make a real prioritisation decision. 'If we add that, something else will suffer' (A) is vague — what else? What kind of suffering? 'Adding things means removing things' (B) is a principle, not a decision-point. 'We can't add more without removing something' (D) says the same thing more firmly but still doesn't name the specific trade-off. Name both items when presenting a trade-off.
5 / 5
A useful feature came up late in the sprint and should be given proper attention. Which phrase defers it most professionally?
Option B is the professional deferral. It proposes a specific next touchpoint ('next sprint's planning'), and explains why deferring is actually better for the feature ('give it proper time rather than rushing it in'). This reframes deferral as a quality decision, not a rejection. 'Let's talk about this later' (A) is vague about when and gives no reason. 'Not this sprint, maybe next' (C) is honest but curt, with no reasoning. 'We should defer this item' (D) is procedural language without a commitment to when it will resurface. Good deferrals name the next opportunity and explain what deferring protects.