Made for Engineering Managers
Make the Scope Tradeoff Explicit
Also useful for: people in Engineering Managers
Turn an urgent scope request into a decision brief that shows delivery impact, displaced work, technical risk, and the cost of waiting.
We'll use them to write your prompt.
Make Your Play
Give us the situation. We’ll build the prompt.
Expose the real tradeoff behind a mid-sprint request so stakeholders can choose deliberately instead of quietly overloading the team.
Your answers save as you type.
What you'll do
This is the plan inside your prompt. Add your details first. Then follow these steps with ChatGPT or Claude.
Make Your Play
Make the Scope Tradeoff Explicit
Tell us what the prompt needs to know
Start with the questions below. Each answer personalizes the playbook and builds the prompt you’ll use at the end.
Your situation
Describe the new work being requested, including the smallest useful outcome.
0/10000
Explain why the request matters now and whether the deadline is fixed or preferred.
0/10000
List the work already committed and identify anything that could realistically move.
0/10000
Summarize time remaining, current progress, available capacity, and active blockers.
0/10000
Estimate the effect on planned work if the request enters the sprint.
0/10000
List technical unknowns, dependencies, testing needs, and quality or operational concerns.
0/10000
Describe what could happen if the request waits until the next sprint and note any workaround.
0/10000
Name who requested the change, who approves scope changes, and who needs the final explanation.
0/10000
This playbook was updated. Review your inputs before copying.
What you'll do
Check a step when you finish it.
Fill in the fields above to generate your prompt preview.
Assembled prompt
Beginner instructions
Fill in what is known, even if the estimates are rough. Mark unknowns instead of guessing. Use the recommendation to start the decision conversation, not to replace technical review or stakeholder approval.
Advanced instructions
Add confidence ranges for estimates, name dependency owners, and test whether the recommendation changes under a best-case and worst-case delivery scenario.
Use this when
A stakeholder wants new work added after the sprint has started, and you need a fast, defensible response before the team changes direction.
You'll need
- Scope request
- Business reason
- Current sprint commitment
- Sprint status
- Likely delivery impact
- Technical risk
- Cost of waiting
- Decision context
You'll get
- A comparison of add, swap, reduce, and defer paths
- A visible displacement cost for every feasible in-sprint option
- One recommended decision with rationale
- Material unknowns and approval needs named
- Stakeholder talking points ready to use
By the end of this playbook
You will have:
- A comparison of add, swap, reduce, and defer paths
- A visible displacement cost for every feasible in-sprint option
- One recommended decision with rationale
- Material unknowns and approval needs named
- Stakeholder talking points ready to use