A team can build exactly what was specified, at the agreed quality and on the committed schedule, and leave the business no better off. Every item on the backlog moved to Done and nothing the business cares about changed. That isn't a failure of execution. The features were never tied to the result they were supposed to produce.
The same gap shows up after release. Someone asks whether things are getting better, five people bring five numbers, and each one answers a different question. The meeting turns into an audit of the dashboards instead of a decision about the work. This practice keeps the backlog anchored to outcomes, makes those outcomes measurable before anything ships, and routes each question to the person whose evidence can actually answer it.
When to use this
- Use it when deciding what goes on the backlog and in what order.
- Use it when writing acceptance criteria and planning what a release should prove.
- Use it in sprint reviews and outcome reviews, whenever someone asks "did it work?"
- Use it when a new technology or tool is proposed as the answer to a problem.
- A team on a fixed-scope contract, where the client owns the outcome, still needs the first two practices. The outcome review may sit with the client.
Principles
Somebody is paying for this. Every backlog item spends a business owner's money, and that owner expects a return. Velocity, rollover, test coverage and release readiness are instruments for getting there; they aren't the objective.
A feature is what you build; an outcome is what changes. A project that ships every feature and moves no business measure has failed. A project that ships half its features and measurably improves retention has succeeded.
State the outcome in numbers before you build. "Better user experience" is a direction. "Cut the time to produce a sales quote from 45 minutes to under 15" is an outcome. Only the second one can tell you whether a feature helped.
Instrument before you need the data. Take the baseline before the change ships. Measurement added after go-live can't tell you what the change did.
Every number answers exactly one question. Development answers what should change, QA answers whether the change worked, and analytics answers whether it mattered. A number brought to the wrong question produces an argument, not a decision.
The fixer shouldn't also be the judge. One person believing a fix works and another person proving it are separate acts. Don't design the process around anyone being unbiased about their own work.
Judge technology by the outcome it serves, not its appeal. A new framework that is more interesting to work with and a framework that produces better business outcomes are two different arguments.
The practice
Start from what should be true afterward
- Ask the business owner what they want to be true when the work is done, rather than what they want built. What will they be able to do faster, more reliably or at all?
- Turn the answer into an outcome with a measure, a baseline, a target and a date. If you can't name the measure, you have a direction, and the next conversation is about finding the measure.
- Trace every backlog item to the outcome it serves. An item that traces to nothing gets questioned before it gets estimated.
- Order the backlog by contribution to the outcome, not by who asked loudest. An order nobody can explain turns every planning meeting into a negotiation. The product owner owns that order and can explain it.
Put the outcome into acceptance criteria
- Write acceptance criteria that include the observable business effect, not only the technical behavior. That keeps the definition of done pointed at the outcome.
- Before the sprint closes, ask the question that sets up the analytic contract: how will anyone know this feature is working, from the data it produces? Agree which fields or events carry that signal.
- Make an explicit durability decision for any field a report depends on. If a field drives an executive report, it's part of the product, and changing it needs the same notice as changing a screen.
Baseline and instrument before release
- Capture the baseline for the outcome measure before the change ships.
- Confirm the instrumentation is in production and producing data, not merely written.
- Set the date of the first outcome review now. Some outcomes take weeks or months to show, and a review date that isn't scheduled doesn't happen. I treat that date as part of the release's definition of done.
Review the outcome, not just the output
- In sprint reviews, report what shipped and what the outcome data shows since the last release. Velocity and story points describe output. They don't tell anyone whether the work mattered.
- Hold an outcome review at the scheduled date with the business owner and analytics.
- When a feature shipped and the measure didn't move, treat it as information to act on. The questions are in Decision aids below.
- Report outcomes that didn't move as readily as features that shipped. Business owners ask for feature lists when they don't trust outcome reporting; that trust comes from bad news delivered alongside good.
Route each question to its owner
When someone asks whether things are improving, start by asking which question each number answers. Development, QA and analytics each own one question on a different time horizon, and only one of them can say whether the outcome moved. The routing table is in Decision aids.
Check proposals for sizzle
When a new technology, framework or tool is proposed, run the sizzle check before anyone builds a pilot. I keep it short on purpose. A proposal with a clear outcome passes it in minutes, and a proposal without one should stall there.
Decision aids
Direction or outcome?
Use this when a goal arrives in vague terms.
| Direction (can't be measured) | Outcome (can be measured) |
|---|---|
| Better user experience | Quote time from 45 minutes to under 15 |
| Improve system reliability | Month-end incidents from an average of 12 to under 3 |
| Modernize the platform | Release lead time from three weeks to one |
| Make reporting easier | Monthly report produced without manual reconciliation |
Which question does this number answer?
Use this before a review meeting, or when two dashboards disagree.
| Function | Question it answers | Time horizon | Can it say whether the outcome moved? |
|---|---|---|---|
| Team | What should change, and is it in and behaving as designed? | Today | No |
| QA | Did the change hold under real conditions? | Today | No |
| Analytics | Did the change matter to the trend? | Weeks to months | Yes, once the measure's definition is agreed |
| Customer feedback | How did people feel about it? | Days | Only as a signal |
QA saying a fix failed and analytics saying the trend improved can both be true, because they cover different horizons.
When a feature shipped and the measure didn't move
- Did the feature reach the people it was meant for?
- Was the assumption about what would produce the outcome correct?
- Was the feature right but the outcome target wrong, or too early to judge?
- Is the measure still defined the same way it was at baseline?
Sizzle check
Ask these about any proposed technology before a pilot is funded:
- What outcome does this support, stated as a measure?
- What evidence says this approach is the most effective way to reach that outcome?
- What new dependencies, failure modes and learning time does it bring?
- Would the business owner fund it if it were described only in outcome terms?
If the answers sound like "it's more current" or "it's what everyone is moving to," pause. That isn't a no; it means the outcome case hasn't been made yet.
Who owns what
| Decision or task | Owner | Advises | Informed |
|---|---|---|---|
| The outcome, its measure and target | Business owner | Product owner, analytics | Team, sponsor |
| Backlog order and tracing items to outcomes | Product owner | Delivery lead, engineering lead | Business owner |
| What should change, and building it | Team | Engineering lead | Product owner |
| Proving the change works | QA | Team | Product owner |
| Whether the outcome moved, and the measure's definition | Analytics | Product owner | Business owner, sponsor |
| Durability of fields that reports depend on | Engineering lead | Analytics | Product owner |
Signs it's going wrong
- Sprint reviews celebrate velocity and completed stories and never mention the outcome measure. The team is optimizing output.
- Backlog items can't be traced to an outcome. Prioritization has become a negotiation.
- An outcome has a target but no baseline. Nobody will be able to say whether it moved.
- Review meetings turn into arguments between dashboards. Nobody agreed which question each number answers.
- A report breaks after a release because a field changed. The analytic contract conversation isn't happening before the sprint closes.
- "Done" is declared at deployment and the outcome review never gets scheduled.
- Technology proposals are justified by novelty. The sizzle check is being skipped.
Related terms
Business Owner, Product Owner, Outcome, Output, Definition of Done, Analytic Contract, Delivery Lead, Rollover, Sponsor
Where this came from
- From Features to Outcomes: Keeping Your Eye on the Prize: outcome versus feature, measurable targets, instrumenting early, and the real definition of done.
- Tactical Excellence, Strategic Truth: Who Checks Whom: three questions with three owners, and why the fixer shouldn't be the judge.
- Stop Digging Through Logs. Start Designing for Learning.: asking how a feature will be observed before the sprint closes.
- Sidetracked by Sizzle: Staying Focused on True Value: judging technology by the outcome it serves.
- A Journeyman's Guide to Three-Week Sprints: somebody is paying for this, and the metrics are instruments.