Value Dashboard™

Design the evidence path and read the results of what you shipped.

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: value-dashboard
description: "Value Dashboard™ by VDS™: design the evidence route for a Quick Value Release (QVR) and read results honestly. Use when someone wants to know how to measure a feature or initiative, which KPIs to track, what to show in a sprint review or status report, whether something worked, what counts as evidence, or whether to persevere, pivot or stop. Adapts to the user's role (project manager, delivery manager, scrum master, product owner, business analyst, tech lead, architect, engineering manager, QA lead, developer)."
---

# Value Dashboard™

A project dashboard tells you how the team is performing. A Value Dashboard™ tells you whether the business is changing. This skill helps you design the evidence route before you build, and read the results without fooling yourself afterwards.

It is one pillar of the Value Design System™ (VDS™). Value is designed, not reported after the fact: if no impact was designed, there is no impact to show.

## Step 1: check the prerequisites

This skill works best once a hypothesis and a Quick Value Release (QVR) exist, because the dashboard measures whether that hypothesis held. Ask for:

1. The impact hypothesis, in the standard format: "We believe that by implementing [X], we will achieve [Y], which will move [Z] metric in [N] time."
2. The QVR: the smallest delivery that moves a real business metric.
3. At least one KPI baseline: where the metric stands today.

If there is no hypothesis or QVR yet, offer to build them first (Value Architecture Canvas™, then QVR). Do not block: draft the hypothesis yourself, label it E0 and ask the user to confirm it.

If there is no baseline, the first deliverable is to measure it. Say so plainly. Until a baseline exists, any "improvement" claim is an assumption. Label the whole dashboard E0 and put "capture baseline" as the first row of the plan.

## Step 2: choose indicators by type

A Value Dashboard™ organizes evidence in a few views. The template that accompanies VDS has five: Impact, Friction, Risk, Learning and System Health. The core of this skill is the first five rows below (the Impact view is split into Business KPI, Impact KPI and Impact view); Risk and System Health complete the template. Pick the minimum set, usually one or two signals per type, not a long list.

| Type | Question it answers | Example shape |
|---|---|---|
| Business KPI | Is the business outcome moving? | Conversion, cost per transaction, retention, cycle time of a business process |
| Impact KPI | Is the QVR itself changing user or process behavior? | Share of users who complete the new flow, minutes saved per task, errors per week |
| Impact view | What does the change look like in context? | A before/after table or trend, a short user observation, a case walk-through |
| Friction | What is it costing us to get this value? | Manual steps added, support tickets, rework, tech debt created, wait time |
| Learning | What did we find out, including from failure? | Hypotheses confirmed or invalidated, assumptions retired, open questions |
| Risk | What could still erode the value, and how likely is it? | Risk description, type (technical, operational, decision), probability, impact, mitigation, status |
| System Health | Is the team or system behind the QVR in good shape to keep delivering? | Signal, indicator and a green / yellow / red status for the team or system, with the risk and the action |

Who reads what: the Value Dashboard™ has three layers. The executive layer (sponsors, directors) sees the main business metric, the active QVR, expected versus real impact, key risks and early expansion signals, and answers "do we keep investing, adjust or stop?". The leadership layer (Impact Owner, Value Facilitator, Technical Value Leader, Strategic Tech Advisor) sees the ranked QVRs, estimated ROI, friction, decisions and learning. The operational layer (delivery teams) sees stories and tasks per QVR, progress, quality, instrumentation and technical dependencies. Do not push operational detail up to the executive layer.

Rules of thumb:

- Business KPIs move slowly and are influenced by many things. Impact KPIs move first and are closer to your QVR. Use both, and say which you can attribute to the delivery and which you can only correlate.
- Always include at least one Friction signal. Value = (Expected Impact x Actual Impact) / Friction. It is a decision heuristic, not a formula; a dashboard with no friction signal hides half of it.
- Always include at least one Learning signal. A negative result with documented learning is progress.
- Include at least one Risk entry. Delivery metrics (velocity, burndown, bugs) belong, if anywhere, under System Health as supporting context, never as the headline.

## Step 3: signals, not vanity metrics

A Value Signal is an observable data point showing that what was delivered is producing the expected impact. If you cannot name the signal, you cannot claim the value.

A metric is suspect if:

- It goes up whatever happens to the business (features shipped, story points, tickets closed, page views with no action).
- Nobody would change a decision if it went the other way.
- It is not linked to a sentence in the hypothesis ("which will move [Z]").
- It measures team activity rather than a change for a user, the business or someone's life.

Replacement move: for each suspect metric ask "What would we do differently if this moved?" and "Which part of the hypothesis does it test?" Keep it only if there is a good answer, or demote it to context.

Delivery metrics (velocity, burndown, defect counts) are not forbidden. They are supporting context on the dashboard, never the headline.

## Step 4: the evidence ladder

Every signal declares its target level and, later, the level actually reached.

| Level | Name | What it is | Example |
|---|---|---|---|
| E0 | Assumption | Belief without evidence | "Users will want this" |
| E1 | Qualitative signal | Feedback, observation, testimonial | 3 users say they would use it, and why |
| E2 | Observed behavior | Someone did something | 5 users completed the flow unaided |
| E3 | Proxy metric | A number that moves with the value | Share of searches resolved in under a minute |
| E4 | Business metric | Revenue, cost, retention | Cost avoided, paid renewals |

Rules:

- Never present E0 as E2. Always label the real level.
- Raise the level when it is cheap to do so. Do not over-invest in measurement.
- Intangible value can legitimately stay at E1 to E3.
- A QVR with no evidence route, even an E1 one, is not ready to build.

## Step 5: small-sample honesty

Most delivery teams have few data points: a handful of users, one sprint, two weeks of data. Be explicit about what that allows.

What a small sample CAN tell you:

- Whether something is possible (it happened at least once).
- Which problems are blocking people (one observed failure is a real failure).
- A direction worth testing next, labeled as a lead, not a result.

What it CANNOT tell you:

- That an effect is real, stable or general. Three users is E1, not E3.
- How big the effect is. Do not quote percentages from tiny counts without showing the counts.
- Causation. Ask what else could have moved the signal: seasonality, a campaign, a staffing change, another release.

Habits to apply every time:

1. Show the raw count next to any percentage ("4 of 6", not "67 percent").
2. State the comparison: against baseline, against a control group, or against nothing (then say "no comparison").
3. List confounders before celebrating.
4. Write the threshold for success and failure BEFORE the data arrives. Reading results against a threshold set afterwards is storytelling.
5. Use words that match the evidence: "suggests", "is consistent with", "we observed" for low levels; "demonstrates" only for E3 or E4 with a stated comparison.
6. Never present an assumption as a fact. If it is not measured, it is E0 and it says so.

## Step 6: intangible value

Not all value is a business number. If you cannot measure it, observe it; if you cannot observe it either, it is still a hope. Intangible is never an excuse to skip evidence; it is a reason to choose different signals.

Pick one primary value dimension and at most two secondary ones: revenue growth, operational efficiency, customer or user impact, capability and learning, trust and authority, human and social impact, strategic optionality.

For intangible dimensions, define an observation protocol, for example: "Hold 5 short conversations with question X. Success if at least 3 mention Y without being prompted." Record who observed, when, and with what wording. Spontaneous behavior beats stated opinion.

## Step 7: output 1, the one-page dashboard spec

Produce this artifact. One page, copy-pasteable.

```
## Value Dashboard™: [initiative or QVR name]
Role lens: [role]   Date: [date]   Owner of the dashboard: [name or role]
Hypothesis: We believe that by implementing [X], we will achieve [Y], which will move [Z] metric in [N] time.
Primary value dimension: [one]   Secondary: [up to two]

| # | Type | Signal | Baseline | Target | Success / failure threshold | Source | Cadence | Target level | Owner |
|---|------|--------|----------|--------|-----------------------------|--------|---------|--------------|-------|
| 1 | Business KPI | | | | | | | E_ | |
| 2 | Impact KPI | | | | | | | E_ | |
| 3 | Impact view | | | | | | | E_ | |
| 4 | Friction | | | | | | | E_ | |
| 5 | Learning | | | | | | | E_ | |
| 6 | Risk | | | | | | | E_ | |
| 7 | System Health (optional) | | | | | | | E_ | |

Baseline status: [measured on date / not measured: first action is to capture it, level E0]
Decision date: [when we read this and choose persevere, pivot or stop]
Minimum instrumentation: [event, log, counter, one-question feedback or observation protocol]
Privacy note: [what is collected, what is deliberately not]
```

Keep the instrumentation minimal and respectful of privacy: collect what the signal needs and nothing more, especially when minors or personal data are involved.

## Step 8: output 2, the results read-out

When data or observations arrive, produce this read-out.

```
## Results read-out: [initiative or QVR name]   Period: [dates]
1. Result vs threshold (set beforehand): [signal, result, threshold, met or not met]
2. Evidence level reached: [E_ actual, not desired]   Sample: [counts]
3. Confounders: [what else could explain it]
4. Friction paid: [what it cost: manual steps, tech debt, tickets, rework]
5. Value Gap: promised [..] vs evidenced [..] ; gap = [..]
6. One-sentence learning: [..]
7. Recommendation: Persevere | Pivot | Stop, because [evidence]
8. Decision needed from the Impact Owner: [concrete question]
```

## Step 9: reading results, persevere, pivot or stop

- Persevere: the signal moved as per the threshold. Next QVR on the same hypothesis.
- Pivot: there was learning, but the hypothesis does not hold as stated. Write a new hypothesis.
- Stop: no signal and no relevant learning. Free the capacity.

Give the recommendation with its evidence level. The decision belongs to the person who owns the impact. A negative result with documented learning is not a failure; hiding it is.

Apply The Renewal Test: "If this were up for renewal tomorrow (the contract, the funding, the team's mandate), what specific impact could we demonstrate with data?" Answer only with evidence from the read-out. A team passes the test because it measured impact during the work, not because it prepared a case at the last minute. If the honest answer is "we do not know", the finding is a measurement gap, and the next QVR is to close it.

## The Value Gap

The Value Gap is the distance between the impact that was expected when the work was commissioned and the impact that was actually generated and evidenced. It can exist while stakeholders are satisfied, sprints are completed and the relationship is good. Satisfaction does not close it.

Make it explicit on every read-out: promised, evidenced, gap, and what you believe explains it. Where the gap is large and there is little evidence, the honest statement is "unproven", not "failed".

## Erosion patterns to name when you see them

- Dashboards of activity under a "value" title: a report with more columns is not a Value Dashboard™. Replace the headline with a signal tied to the hypothesis.
- "Done" treated as "created value": separate technical Done from value done.
- Several deliveries with no evidence read: propose a short review before building more.
- "It is intangible, it cannot be measured": apply the rule above and pick an observable signal.
- Metrics chosen after the fact: fix thresholds before data.

## Closing

End with the next decision: what evidence is expected, when it will be read, and what will be done depending on the result. Then point to the next pillar: once a QVR is delivered and validated, the Software Expansion Loop™ turns what was found into the next hypotheses.

## Role lens

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

# Scrum Master / Agile Coach lens: Value Dashboard™

Your move: make the sprint review show a metric that moved, and make the retrospective ask about value, not only about process.

## How measurement plays out in your day

Agile asks whether you are executing with discipline. VDS™ asks whether that execution creates value. They complement each other. Your ceremonies are the natural place to close the gap, with almost no new overhead.

Sprint review: instead of a demo of everything finished, open with the hypothesis behind the sprint goal, show the signal and its baseline, and then demo. If no signal is available yet (common in the first sprints), say so and state when it will be.

Retrospective: add one value segment to the usual process look. Ask what we learned about the hypothesis, what friction the team created for users, and whether we would still choose this work knowing what we now know.

Sprint goal: write it as an outcome. "Reduce manual reconciliation steps for finance from 7 to 4" can be checked; "complete stories 41 to 47" can only be counted.

## You own / you influence

- You own: the shape of the sprint review and the retrospective, the sprint goal format, team habits around Done and value done.
- You influence: whether the Product Owner arrives with a hypothesis, whether the team instruments what it ships, whether stakeholders at the review see impact or output.

## The sharpest questions

1. Which signal should have moved because of this sprint, and by how much did it move?
2. Does our sprint goal name an outcome, or only a list of items?
3. What is Done technically, and what is value done (hypothesis linked, signal instrumented, next decision clear)?
4. What did the team learn this sprint that changed what it will do next sprint?
5. Which story shipped with no way to tell if it worked?
6. What friction did we add for users or for ourselves, and is it on the board?
7. In the last three reviews, how many showed a metric versus only a demo?
8. If a story was cut to protect the sprint goal, was it the one that mattered for the signal?

## Artifact and where it lives

A one-slide sprint review opener (hypothesis, signal, baseline, current reading, evidence level) and a retro value card (learning, friction, would we choose it again). Keep them with the sprint review notes in the team's usual space, next to the board. A tiny running table of "sprint, hypothesis, signal, reading, level" gives the team a trend and shows Sprint Debt: consecutive sprints with no evidence read.

## Three erosion patterns and a fix

- Velocity as proof of value. The chart rises, so the team feels it is succeeding. Fix: put velocity under the signal in the review; talk about it only as capacity context.
- Demo theater. Stakeholders applaud features and leave with no sense of whether anything changed. Fix: open with the signal, ask the stakeholder one question ("does this match what you see on your side?"), then demo.
- Sprint Debt. Several sprints pass with no evidence read. Fix: propose a QVR review after the third sprint without a reading and name the pattern lightly, without blame.

## Who to involve

Product Owner (hypothesis and signal), the developers (instrumentation and friction), the QA Lead (post-release checks), and one stakeholder who sees the business-side data. For coaching across teams, the Delivery Manager.

## Your first 15 minutes

Open your next sprint review agenda. Add one line at the top: "Hypothesis, signal, reading." Ask the Product Owner today for the one metric the sprint goal is meant to move. If there is none, that is the first finding: write the hypothesis together in the standard format, label it E0, and agree on how the team will find out in the next two sprints.

3. Get it

Install

Did you use it?