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 Product Owner / Product Manager: 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 Product Owner / Product Manager.

# Lens: Product Owner / Product Manager - ROI Sprint Planning™

## How the pillar plays out in your day

The order of the backlog is your decision, and it is the most visible thing you do. Every item has an advocate. ROI Sprint Planning™ lets you make that decision with scales and assumptions that others can see, so the decision can be challenged on its inputs rather than on your authority.

At your level the candidates are QVRs, each tied to a hypothesis. The backlog below the queue is a pool; the queue itself is short: one active, one next, one in analysis.

## Where the ranking happens

In your own backlog work, in refinement, and in stakeholder reviews where you present the next cycle. You score alone first, calibrate with the team and then show the table to stakeholders.

## What you own vs what you influence

**You own:** the order of QVRs, the Impact scores (with business input), the discard list, and the communication of what is not being done.

**You influence:** Effort estimates (through scope cuts), dependencies, how stakeholders understand trade-offs. Capacity belongs to managers; the technical effort estimate belongs to the team.

## The sharpest questions

1. "Which hypothesis is the riskiest, and would testing it first change everything below it?"
2. "What does Impact 8 mean here: more users, deeper change, a larger metric?"
3. "Who asked for this, and which metric did they say would move?"
4. "Can I slice this item smaller and get most of its Impact at half the Effort?"
5. "What is the learning value of this QVR for the other items on the list?"
6. "What is the cost of delay in a number, or is it just impatience?"
7. "What am I explicitly not doing this cycle, and who needs to hear it from me?"
8. "What evidence from the active QVR would reorder the queue?"

## The artifact you produce, and where it lives

The **ranked table** with one line of reasoning per item, the discard list and the "what would change this" line. It sits at the top of the backlog tool or product wiki and is the single source for the roadmap view. After each QVR is read, update the scores that the result affected, and note what you learned about your own estimation.

## Erosion patterns to watch

1. **The loudest stakeholder wins.** Priority follows access, not impact. Fix: score every request on the same scales and show the table.
2. **The backlog never shrinks.** Nothing is discarded, and everything is "next quarter". Fix: name discards with reasons; a backlog without discards is a wish list.
3. **False precision.** Decimals in ROI settle arguments that the data cannot settle. Fix: treat small differences as ties and break them by learning or reversibility.

## Who to involve

The sponsor or business owner (for Impact), the tech lead (for Effort and dependencies), stakeholders with competing requests (to score together), the analytics owner (for evidence), and the Scrum Master or delivery manager to facilitate the scoring session.

## First 15 minutes

Take the top five items on your backlog. For each, write the metric it moves and a first-pass Impact and Effort. Mark the items where you cannot name a metric: they are not ready to rank. Look at the top two by ROI and ask whether your gut agrees. The disagreement is the missing criterion; name it.

3. Get it

Install

Did you use it?