All skills

ROI Sprint Planning™

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

What it does

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.

Who it is for

Two or more candidates are competing for the same sprint or the same capacity.

It adapts its questions and its output to 10 roles, delivery and technical.

1. Pick your role

2. Preview

This is the full SKILL.md for Project / Program 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 Project / Program Manager.

# Lens: Project / Program Manager - ROI Sprint Planning™

## How the pillar plays out in your day

Priorities reach you as pressure: a sponsor wants their module first, another wants the date held, a third wants a late requirement added. The plan is yours, so every reorder lands on your schedule. ROI Sprint Planning™ gives you a neutral way to sequence work: each competing item is scored on Impact and Effort, adjusted for risk, dependency, urgency and learning, and the trade-off is shown to the people who pay for it.

It also gives you a defense for scope. "We can do that, and here is what moves down" is a stronger sentence than "we cannot fit it".

## Where the ranking happens

In the steering committee, the change-control board or the monthly planning review. You prepare the table beforehand, test it with each sponsor separately, and bring it to the forum as a decision, not a discussion.

## What you own vs what you influence

**You own:** the sequencing of work packages, the schedule consequences of a reorder, the change log, the benefits timeline, the escalation path when sponsors disagree.

**You influence:** the criteria the sponsors use, how Impact is anchored, which dependencies are visible, whether urgency is backed by a cost of delay. The final call on business priority belongs to the sponsor or business owner.

## The sharpest questions

1. "If the program had to release only one thing this quarter, which would the sponsor choose and why?"
2. "What does each week of delay cost on this item, in a number or a named consequence?"
3. "Which items share a dependency, approval or environment, so that doing them together is cheaper?"
4. "What moves down if this request moves up, and has the owner of that item seen it?"
5. "When does the benefit of each item start in the benefits timeline, and would a different order bring it forward?"
6. "Which item is only high on the list because someone asked loudly?"
7. "What is the earliest date at which we will know we ranked right?"
8. "What would make us reopen this ranking before the next planning cycle?"

## The artifact you produce, and where it lives

The **ranked table** (rank, QVR, Impact, Effort, ROI, adjustments, status) with the named discards and the "what would change this" line. It is attached to the steering pack and stored with the change log. Each reorder decision is recorded with the date, the decision owner and the trade-off accepted.

## Erosion patterns to watch

1. **Priority by escalation.** Whoever escalates last wins, and the plan thrashes. Fix: every request enters the same table with scores and a cost of delay before it is discussed.
2. **Fixed order for the whole program.** The sequence is set at kickoff and never revisited. Fix: re-score when a QVR is read or a dependency changes; keep the queue to one active, one next, one in analysis.
3. **Urgency inflation.** Every item is critical. Fix: urgency counts only with a named date or cost of delay; otherwise it is neutral.

## Who to involve

Each sponsor or business owner whose item competes, the delivery manager or team leads for effort, the product owner for impact assumptions, finance or operations for cost-of-delay numbers, and the steering committee chair for the decision slot.

## First 15 minutes

List the five items currently fighting for the next window. Next to each write who is asking for it and what happens if it waits a month. Anything without an answer to the second question is not urgent yet. Take the two with the loudest sponsors and score them against the others with the same scale before the next meeting.

3. Get it

Install

Claude.ai

  1. Download the full skill (.zip).
  2. In Claude, open Settings, then Capabilities, then Skills.
  3. Upload the .zip.
  4. Start a chat and describe your situation. The skill is chosen from its description.

Claude Code

  1. Download and unzip the full skill.
  2. Put the folder in ~/.claude/skills/roi-sprint-planning/ (all projects) or in .claude/skills/ inside your project.
  3. Restart Claude Code and ask for the skill by name, or describe the task.

Cannot install skills?

Use "Copy as instructions" and paste the text into a Claude or ChatGPT chat, or into the instructions of a Project. You can also run the method with the VDS Assistant.

These files are plain Markdown in the SKILL.md format (a name and description, then instructions). Menu names in Claude can change; if you cannot find the option, use the paste route. We have not published test results for specific Claude versions.

Did you use it?