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 QA Lead / Test 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 QA Lead / Test Manager.

# Lens: QA Lead / Test Manager - ROI Sprint Planning™

## Why this matters for you now

AI generates tests and code faster than ever, so the volume of testable output grows. The leverage moves to deciding what deserves verification effort and which risks to accept. That is a ranking problem, and your risk view is exactly what the table is missing. Value questions come before test design: which behavior protects which signal?

## How the pillar plays out in your day

In planning, quality is often an afterthought bolted onto Effort: a percentage added to the build estimate. ROI Sprint Planning™ lets you make quality visible: test effort is part of Effort, risk of defects or an unreadable signal is part of the risk adjustment, and post-release monitoring is part of the evidence route.

You also help the group decide how much quality each QVR needs. A small slice with a reversible change deserves less testing than a payment flow.

## Where the ranking happens

In planning and refinement (contributing risk and test effort), in release readiness discussions, and in quality reviews where regression or debt work competes with new features.

## What you own vs what you influence

**You own:** test effort estimates, the risk view of the slice, regression strategy, quality gates, the advice on release readiness.

**You influence:** the risk adjustment in ranking, whether instrumentation is included in Effort, how quality work is justified, what the team accepts as untested. You do not own the order.

## The sharpest questions

1. "What is the test effort for this slice, and is it included in the Effort score?"
2. "What is the probability and the cost of failure for this item, in business terms?"
3. "Which items change a shared area, raising regression risk for others?"
4. "Which defects have actually moved a signal, such as support tickets, abandonment or rework?"
5. "What would the item look like if we tested only the critical path, and who accepts the rest?"
6. "Is automation for this area an investment that lowers Effort of later items?"
7. "What does the post-release monitoring cost, and does it belong in this item's Effort?"
8. "Which high-ROI item is risky enough to warrant a staged rollout?"

## The artifact you produce, and where it lives

A **risk and test-effort annex** to the ranked table: per candidate, test effort, top quality risks, regression exposure, monitoring plan and untested scope. It lives in the test management space and is linked from the ranking. For quality investments (automation, test environments), write them as QVR candidates with a signal, such as escaped defects or lead time to release.

## Erosion patterns to watch

1. **Testing as a flat tax.** A fixed percentage added to every estimate regardless of risk. Fix: size test effort per slice by risk to the signal.
2. **Quality work ranked by feeling.** Automation and test debt are argued on principle. Fix: give them a signal (rework, escaped defects, release lead time) and a baseline.
3. **Late discovery of risk.** Risk appears after the item is ranked and started. Fix: bring QA into ranking, not into verification only.

## Who to involve

The Product Owner (impact and accepted risk), the tech lead and developers (testability, effort), operations or support (real failure signals), the engineering manager (investment in quality) and the sponsor for high-risk items.

## First 15 minutes

Take the current ranking. Next to each item write one risk in business terms and how likely you think it is. Highlight any item that is high ROI and high risk, and propose a staged rollout or a thinner slice for the next planning session.

3. Get it

Install

Did you use it?