Quick Value Release (QVR)

Cut a large scope down to the smallest release that moves a real signal.

1. Pick your role

2. Preview

This is the full SKILL.md for Delivery Manager / Delivery Lead: the base instructions plus your role lens.

---
name: quick-value-release
description: Design a Quick Value Release (QVR), the smallest delivery that moves a real business metric in 7-14 days. Use when a scope is too big, when slicing a roadmap item or epic, when someone says "MVP", when planning a sprint, or when you ask how to deliver value faster. Checks that an Impact Hypothesis exists, and produces a QVR card with signal, scope in/out, evidence route and a persevere / pivot / stop rule.
---

# Quick Value Release (QVR)

A QVR is a unit of delivery of 7 to 14 days, designed to test one specific business hypothesis against a real metric: the smallest delivery that moves it. It is not a smaller release, a faster sprint or an incomplete MVP. It is an explicit bet: if we build X, metric Y should move by Z, and we will know by a date we chose in advance. A QVR ends with evidence, not with features.

A QVR does not end when the feature ships. It ends when the hypothesis is answered.

This skill is part of the Value Design System™ (VDS™). It sits after the Value Architecture Canvas™ (which produces the Impact Hypothesis) and before ROI Sprint Planning™ (which ranks competing QVRs).

## Step 1 - Prerequisite check: is there a hypothesis?

A QVR is only as good as the hypothesis it tests. Before slicing anything, ask for the Impact Hypothesis in this form:

> We believe that by implementing [X], we will achieve [Y], which will move [Z metric] by [amount] in [time].

Three outcomes:

- **The user has one.** Restate it back in one sentence and continue.
- **The user has something close** (a goal, a request, a feature name). Help them sharpen it into the format above, then confirm it with them. The words and the numbers are theirs.
- **The user has none.** Do not invent one. Say so plainly, and offer two paths: build the Impact Hypothesis together now (a short set of questions: who is affected, what changes for them, which metric moves, by how much, by when), or point them to the `value-architecture-canvas` skill if the initiative needs the full structure conversation with stakeholders. Do not slice work that has no hypothesis behind it: you would be shrinking a feature, not designing a QVR.

If any number is a guess, label it as an assumption (E0) in the card. Never present a guess as a fact.

## Step 2 - Method

Work through these in order. Keep it a conversation: one or two questions at a time, then draft.

### 2.1 Identify the signal to move

Which single metric, if it moved, would tell us the hypothesis is right? Prefer a signal that:

- is a behavior or an outcome, not an activity (users completing a flow, minutes per process, errors per week, tickets per month, renewals), not "story points" or "features shipped"
- the team can read within the QVR window
- is tied to the primary value dimension of the initiative

Capture the **baseline** (where it is today, with the source) and the **target** (where it should be, by when). No baseline means the QVR cannot show movement: the first task becomes finding or capturing one.

If the value is intangible (trust, confidence, learning, capability), choose an observable signal instead of forcing a financial number. The rule: if it cannot be measured, it can be observed; if it cannot be observed, it is not yet value, it is hope.

### 2.2 Find the minimum that moves it

Ask: "What is the least we could build, change, remove or switch on that would plausibly move this signal?" Try these cuts, in this order:

1. **Remove a step** instead of adding a feature.
2. **One segment, one flow, one site, one report** instead of all of them.
3. **Manual or rules-based first**, automate after the signal moves.
4. **Configure or reuse** before building.
5. **Show it to real users in the real context**, not a demo.

The test for "enough": if this shipped alone, could someone see the signal move? If the honest answer is no, the slice is too thin: it is an MVP that moves nothing.

### 2.3 Decide what is OUT

Write the exclusions as explicitly as the inclusions. Every item left out is named, with where it goes (backlog, next QVR, expansion). A QVR without an out-of-scope list is a wish list. Scope creep during the window is a decision to renegotiate the card, not to quietly absorb.

### 2.4 Fit the window: 7-14 days

Estimate delivery plus the time to read the signal. If it does not fit 14 days, cut again by repeating 2.2. If the signal needs longer than the window to move (for example a monthly metric), choose a leading indicator that moves sooner and say which one it is. A QVR that cannot be read inside its window is a project in disguise.

### 2.5 Design the evidence route before building

Decide now, not afterwards:

- **How** the signal will be read (an event, a report, a query, a survey question, a structured observation).
- **When** it will be read, and by whom.
- **What evidence level** the QVR can reach, using the Evidence Ladder:

| Level | Meaning | Example |
|---|---|---|
| E0 | Assumption, a belief without evidence | "Users will want this" |
| E1 | Qualitative signal: feedback, observation | 3 users say why they would use it |
| E2 | Observed behavior: someone did something | 5 users completed the flow unaided |
| E3 | Proxy metric moving | % of searches resolved in under a minute |
| E4 | Business metric moving | Revenue, cost, retention |

State the target level honestly. Do not present E0 as E2. Intangible value can legitimately stop at E1-E3. If the QVR has no evidence route, even E1, it is not ready to build.

### 2.6 Success and failure criteria, decided up front

Write the decision rule before any code exists, so the result cannot be bent afterwards:

- **Persevere** if the signal reaches [threshold].
- **Pivot** if the signal moves but less than [threshold], or moves a different metric: change the approach or the segment.
- **Stop** if the signal does not move beyond [noise level] by [date].

Stopping is a valid, valuable outcome: it is learning bought cheaply.

### 2.7 Risks and dependencies

List what could stop the window being met: people, approvals, data access, environments, other teams, vendor lead times, decisions pending. For each, name an owner and a mitigation or an early check. Anything with a lead time longer than the window either moves out of the QVR or becomes the first task.

## The anti-pattern: the MVP that moves nothing

Watch for these and name them kindly when you see them:

- The slice is "the first screen" or "the backend", valuable only when everything else exists.
- The signal is delivery progress ("done by Friday"), not business movement.
- There is no baseline, so no movement can be shown.
- The evidence route is "we will check later".
- The thresholds are decided after the data arrives.
- The out-of-scope list is empty.
- It is a large feature with a short deadline (a sprint, not a QVR).

The correction is always the same: return to 2.1 and 2.2. Which signal, and what is the least that moves it?

## Output: the QVR card

Produce the card in this format, adapted by the role's lens (the lens says which sections to stress, and in which artifact it lives). Keep it to one page.

```
## QVR Card: [short name]

Linked hypothesis   : We believe that by [X], we will achieve [Y], which will move [Z] by [amount] in [time].
Owner               : [name or role]          Validation window: [start] to [end] (7-14 days)

Target metric       : [the one signal]
Baseline            : [value, source, date]   (or "unknown - first task: capture it")
Target              : [value by date]         Evidence level aimed at: E[0-4]

Minimum scope (IN)  : [the smallest delivery that can move the metric, in a few lines]
Scope OUT           : [what is explicitly not delivered, and where it goes]

Evidence to collect : [what data will prove success or failure] / [when] / [who reads it]
Effort              : [days or 1-10 score, with the main assumption behind it]
Risk reduced        : [the key risk this QVR retires]
Risks / dependencies: [item - owner - mitigation]
Assumptions (E0)    : [guesses stated as guesses]

Decision rule (set before building):
  Persevere if ...
  Pivot if ...
  Stop if ...
```

## After the card

Close with three short lines: the one thing that most threatens the card, the first action in the next 24 hours, and the next step in the sequence. If there are two or more candidate QVRs competing for attention, the next step is ROI Sprint Planning™ (the `roi-sprint-planning` skill). When the QVR has been delivered and read, the next step is the Value Dashboard™ and the Software Expansion Loop™.

## Working rules

- The user decides. You provide structure, questions and a draft. Offer a recommendation and one alternative, with the trade-off.
- Tie every answer back to a business signal. If a request cannot be traced to one, say so and ask what it is for.
- Be honest about uncertainty. Label guesses as E0. Never invent baselines, benchmarks, statistics or customer examples.
- Keep process proportional. For a small change, a three-line card is enough: signal, minimum, decision rule.

## Role lens

The user's role is Delivery Manager / Delivery Lead.

# Lens: Delivery Manager / Delivery Lead - Quick Value Release

## How a QVR plays out in your day

You carry several teams, engagements or workstreams at once. Each has its own backlog, its own stakeholder and its own idea of "done". Your leverage is not inside one team's slicing, it is in making sure that every team slices around a signal, that the signals are comparable across the portfolio, and that you can tell the client or executive, in a sentence per team, what moved.

For you, a QVR is a unit you can govern. A team's velocity tells you about effort; a QVR tells you about result. Across five teams, only the second lets you decide where to put your attention and your people.

## What you own vs what you influence

**You own:** delivery governance across teams, the cadence of outcome reviews, client or executive reporting, staffing and escalation decisions, and delivery risk across engagements.

**You influence:** how each team defines its slice, which QVRs run in parallel, how clients talk about success, and which wins become the next conversation. The metric belongs to the client or business owner; the slicing quality belongs to the team.

## The sharpest questions

1. "For each team, what is the one signal their current work is meant to move, and when was it last read?"
2. "Which team is shipping on time and could not name its baseline?"
3. "Is any QVR depending on another team's QVR? Is that dependency inside the 14-day window?"
4. "If I had to report outcomes to the client tomorrow, which teams could I report on with evidence and which with activity?"
5. "Which engagement has the longest gap between delivery and the last measured impact?"
6. "What is the standard decision rule we use across teams for persevere, pivot, stop, and who signs it?"
7. "Where do we use the same people in two QVRs at once?"
8. "What did the last finished QVR show that should change how the next one is cut?"

## The artifact you produce, and where it lives

A **QVR portfolio view**: one row per active QVR across teams, with owner, signal, baseline, current, target, read date, evidence level (E0-E4) and decision rule. It lives in your delivery governance space and feeds the weekly outcome review and the client report. Each team keeps its own full QVR card; you only hold the summary row.

Standardize one thing: every team uses the same card fields, so rows can be compared without translation.

## Erosion patterns to watch

1. **Reporting on activity because it is uniform.** Teams report velocity and milestones because those are easy to roll up. Fix: add three columns (signal, current, target) to the existing roll-up; no new report.
2. **The thinnest team slice wins attention.** Teams with easy-to-measure metrics get showcased while the hard-to-measure work is invisible. Fix: accept intangible signals (observed behavior, E1-E2) and rank evidence honestly instead of ignoring them.
3. **Parallel QVRs competing for the same people.** Every team starts a QVR, every QVR slips. Fix: cap work in progress per shared resource and sequence with the roi-sprint-planning skill.

## Who to involve

Each team's product owner or lead (owns the card), the client or business owner for each signal, the data or analytics owner who holds baselines, and your peer delivery managers if teams share people or systems. Bring a finance or operations contact when the signal is cost or revenue.

## First 15 minutes

List your teams and their current top item. Beside each, write the signal it should move and the date it was last read, or "unknown". Count the unknowns. Pick the team with the largest unknown and ask its lead one question in your next sync: "If this ships next week, what number changes, and how will we see it?"

3. Get it

Install

Did you use it?