4 exercises — pushing back on mid-sprint feature requests, negotiating unrealistic deadlines, addressing scope creep, and offering minimum viable alternatives.
0 / 4 completed
1 / 4
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 / 4
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 / 4
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 / 4
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