ROI Sprint Planning™

Choose what to build next by impact and effort, adjusted for risk, dependency, urgency and learning.

1. Pick your role

2. Preview

This is the full SKILL.md for Scrum Master / Agile Coach: the base instructions plus your role lens.

---
name: roi-sprint-planning
description: ROI Sprint Planning™ - prioritize competing work by Impact / Effort. Use for backlog prioritization, competing initiatives, stakeholder pressure, or when someone asks "what do we do first". Requires at least one QVR or candidate, scores Impact and Effort (1-10), adjusts for risk, dependency, urgency and learning, and returns a ranked table with one-line reasoning and what would change the ranking.
---

# ROI Sprint Planning™

ROI Sprint Planning™ turns a pile of competing options into a short, defensible queue. It does not fill a sprint with work. It chooses, on purpose, which Quick Value Release (QVR) maximizes value and minimizes friction in the next cycle, and says out loud what is not being done.

The unit of planning is the QVR (or a candidate for one), not the individual story. Stories are how a QVR gets built. QVRs are what gets prioritized.

The planning hierarchy is: business objective / KPI, then Impact Hypothesis, then QVR candidate (the unit of planning), then stories and technical tasks (the unit of execution). A QVR can contain several stories, never the other way round. A sprint counts as successful only if the QVR is delivered and measured, not merely because the work was completed.

In VDS the roles around this decision are: the Impact Owner defines and defends the impact of each QVR; the Technical Value Leader estimates the effort of the whole QVR; the Value Facilitator keeps focus and removes friction; the Strategic Tech Advisor weighs sustainability and systemic risk. Teams without those titles map them to whoever plays the part today.

Part of the Value Design System™ (VDS™). It follows Quick Value Release (the `quick-value-release` skill) and precedes the Value Dashboard™.

## Step 1 - Prerequisite check

You need at least one QVR, or a candidate that can become one. Ask for the list of competing options.

- **QVR cards exist.** Use them. Read signal, scope and effort straight from the cards.
- **Only a loose list** (features, epics, requests). Do a quick pass per item: which metric would it move, and by how much? Anything that cannot name a signal is flagged as "not yet a candidate". Offer to slice the top ones with the `quick-value-release` skill. Do not score items that have no signal; scoring them produces false precision.
- **No hypothesis anywhere.** Point to the `value-architecture-canvas` skill or offer to build the Impact Hypothesis first. Do not invent options or numbers.

Also ask for the decision context: what window is being planned (sprint, month, quarter), who decides, and what constraint is real (people, budget, a date, a dependency).

## Step 2 - Score Impact and Effort (1-10)

Score every candidate on the same two scales, and write the reasoning next to each number. Scores are estimates; the goal is comparability, not precision.

**Impact (1-10): how much does this move the primary signal, in the value dimension that matters?**

Anchor the scale with the user before scoring: what would a 10 look like (the best result any candidate here could plausibly deliver), and what is a 1? Then judge each item against that. For intangible value, score with explicit criteria: reach (how many people), depth (how much changes for each), and duration (how long it lasts).

**Effort (1-10): the cost of the whole QVR, not of one task.**

Include build, dependencies, waiting time, environments, approvals, instrumentation of the evidence route, and the technical debt it adds or removes. Anchor it the same way: what is a 10 here, what is a 1.

**ROI = Impact / Effort.**

Ask each score's owner for the assumption behind it. A number with no assumption is an opinion; a number with a stated assumption can be challenged and improved.

## Step 3 - Adjust for risk, dependency, urgency and learning

Raw ROI is a starting point. Apply four adjustments, each with a short written reason. This is a heuristic, not a formula: there is no universal weight, and pretending otherwise is false precision.

| Adjustment | Question | Typical direction |
|---|---|---|
| Risk | How likely is it that the QVR will not deliver or not move the signal? | Lowers priority when high |
| Dependency | Does it need something outside our control, or does something else need it? | Lowers it when blocked; raises it when it unblocks other QVRs |
| Urgency | Is there a real cost to waiting: a date, a window, a regulation, a seasonal peak? | Raises it, only when the cost of delay is real and nameable |
| Learning | Would the result invalidate or confirm a critical assumption that many other decisions rest on? | Raises it, sometimes above raw ROI |

Mark each adjustment as up, down or neutral and explain it in one phrase. Keep adjustments visible so the ranking can be audited. "Urgent" without a stated cost of delay is pressure, not urgency (see below).

Also check shared friction. If two QVRs need the same data feed, environment or approval, doing them together or in sequence may change the order.

## Step 4 - Read the result carefully

- **Ties and ranges.** Treat scores as ranges. Two items with a ROI of 2.4 and 2.6 are tied. Small differences are noise at this level of estimation. When items are tied, prefer the one that generates the most learning, or the one that is cheaper to reverse.
- **Do not defend the decimals.** If the ranking changes when one score moves by a point, say so: the ranking is fragile and the real work is to learn more, not to argue the number.
- **Everything similar?** Then pick the item that teaches the most, and say it is a learning bet.
- **Check the result against intuition.** If the ranking feels wrong, one of the scores is wrong, or the intuition is carrying a criterion the scores do not capture. Find which one, and write that criterion down.

## Step 5 - Handle stakeholder pressure with data

When a stakeholder pushes for their item, do not argue about importance. Make the trade-off visible:

1. Put their item in the same table, scored with the same scales, with their help.
2. Ask for the signal and the cost of delay: "Which metric moves if we do this first, and what do we lose per week by waiting?"
3. Show what moves down if it moves up: "To put this first, these two wait. Here is what each one was expected to deliver."
4. Offer options, not a refusal: do it now and defer X, slice it into a smaller QVR, or schedule it with a clear trigger.
5. Record the decision and who made it. The decision belongs to the person accountable for the outcome, not to the loudest voice.

If the item has a political reason that the numbers do not capture, name it as a criterion and score it. A priority that wins for an unspoken reason will erode trust in the whole method.

## Step 6 - Keep the queue short

The queue has three places:

- **1 active:** the QVR being built now.
- **1 next:** ready to start when the active one is read.
- **1 in analysis:** being sliced, baselined or de-risked.

Everything else waits or is discarded, and the discards are named. A backlog without discards is a wish list. Revisit the queue when a QVR is read, not on a calendar alone.

## Output format

Return a ranked table, one line of reasoning per item, and what would change the ranking. Each item gets a decision: Do, Delay or Discard.

```
## ROI Sprint Planning: [planning window] - [date]
Decision owner: [name/role]     Constraint: [capacity, date, dependency]
Scale anchors: Impact 10 = [..]   Effort 10 = [..]

| Rank | QVR / candidate | Strategic objective | Impact (1-10) | Effort (1-10) | ROI | Adjustments (risk / dep / urgency / learning) | Decision | Queue |
|------|-----------------|---------------------|---------------|---------------|-----|------------------------------------------------|----------|-------|
| 1    | ...             | ...                 | 8             | 3             | 2.7 | risk neutral, unblocks #3, urgency: yes (cost of delay named) | Do | Active |
| 2    | ...             |                     |               |               |     |                                                | Do | Next |
| 3    | ...             |                     |               |               |     |                                                | Delay | In analysis |
| -    | ...             |                     |               |               |     |                                                | Delay / Discard | Waiting / Discarded |

Reasoning (one line each):
1. ...
2. ...

Ties / fragile calls: [which differences are within noise]
What would change this ranking: [a score assumption proven wrong, a dependency cleared, a deadline appearing, evidence from the active QVR]
Not doing (and why): [named discards]
Decision needed: Do we build [QVR] first?
```

Mark the scoring as a heuristic in the output. Do not present a ranking as a calculation that proves the answer.

## Working rules

- The user and their stakeholders decide. You structure, question and recommend, with one alternative and its trade-off.
- Never invent candidates, metrics or numbers. Scores come from the user and the evidence at hand; label guesses as assumptions.
- Aim for comparability, not false precision. Name what you assumed.
- Tie each ranked item to its signal. An item with no signal is not ranked, it is sent back to be sliced.
- Keep the process light. For two options and ten minutes, a two-row table and a clear reason is enough.

## Role lens

The user's role is Scrum Master / Agile Coach.

# Lens: Scrum Master / Agile Coach - ROI Sprint Planning™

## How the pillar plays out in your day

You facilitate the conversation in which the order of the backlog gets challenged. The Product Owner owns the ordering, but the team, the stakeholders and the pressure all show up in refinement and sprint planning. ROI Sprint Planning™ gives you a structured exercise to run when the ordering is contested: score together, make assumptions visible, and let the Product Owner decide with the data in front of everyone.

It also gives the sprint goal a basis. The goal is the top of the ranked list, expressed as an outcome.

## Where the ranking happens

In backlog refinement and sprint planning. A 30 to 45 minute scoring session before the planning meeting, with the Product Owner, a couple of developers and, when needed, a stakeholder.

## What you own vs what you influence

**You own:** the facilitation of the scoring session, the working agreements on how estimates are discussed, the visibility of assumptions, coaching the Product Owner on ordering.

**You influence:** whether the team challenges the order, whether effort estimates include instrumentation and dependencies, whether urgency is evidenced. You do not own the order (the Product Owner does) or the impact numbers (the business does).

## The sharpest questions

1. "What would a 10 for Impact look like in this backlog, and a 10 for Effort?"
2. "Who scores Impact, and who scores Effort? Are they the same people?"
3. "What assumption sits behind this number, and who can check it by tomorrow?"
4. "Does this Effort include building the evidence route and waiting on other teams?"
5. "Which two items are within a point of each other? Can we call it a tie and choose the one that teaches more?"
6. "What is the cost of delay for the item someone calls urgent?"
7. "Which item in the sprint is there because of habit, not because it ranks?"
8. "What would we have to see in the review to change the next sprint's order?"

## The artifact you produce, and where it lives

A **one-page scoring board** from the session: items, Impact, Effort, ROI, adjustments, and the assumptions noted by the team. It is photographed or saved with the refinement notes and linked from the sprint board. The sprint goal is written beneath it as an outcome sentence.

Retrospective input: compare predicted ROI with what the review showed, and talk about why the estimate was off, without blame.

## Erosion patterns to watch

1. **Ordering by the most senior voice.** The Product Owner or a manager decides without discussion of the numbers. Fix: silent scoring first, discuss the gaps, then decide.
2. **Estimation as a negotiation.** Effort is bargained down to fit the date. Fix: record the original estimate and the assumption that changed; flag when scope shrank rather than effort.
3. **The scoring session becomes a ritual.** It is repeated with no effect on decisions. Fix: skip it when the order is not contested; run it when a conflict, a new item or new evidence appears.

## Who to involve

The Product Owner (decides), two or three developers or the tech lead (effort), a stakeholder with a competing request when there is one, and the person who holds the data for the impact assumption.

## First 15 minutes

Pick the three items most debated in the last refinement. Ask the team to silently write Impact and Effort for each on sticky notes. Reveal them together. The biggest gap in any number is your first discussion, and it is usually an assumption nobody had said aloud.

3. Get it

Install

Did you use it?