Skip to Content
DocsPortfolioGoals
DRAFT — This document is under development and not yet reviewed.

Outcome Goals

Updated 27 March 2026

An outcome goal describes a change in the world — a shift in behavior, capability, or condition — that the organization wants to bring about. It is not a delivery commitment. It is the measure of whether delivery has mattered.

Outcome goals exist at portfolio level. They are set on a strategic cadence — typically annually or per planning horizon — and reviewed at portfolio governance forums. They are the verification layer of the goal system: sprint goals and PI goals express value hypotheses; outcome goals test whether those hypotheses were right.

OKR: The Dominant Model

Objectives and Key Results (OKR) is the most widely adopted framework for setting and tracking outcome goals. Developed at Intel by Andy Grove and popularized at Google by John Doerr, OKR structures the goal in two parts.

The Objective is qualitative and directional — it describes the desired state in terms that are meaningful and motivating. It answers: what do we want to be true? An objective that could be achieved by doing nothing, or that describes activity rather than state, is not an objective.

The Key Results are quantitative and verifiable — they answer: how will we know we got there? Each key result is a measurable signal that the objective is being achieved. Key results measure outcomes, not outputs. “Three features shipped” is not a key result. “Support resolution time reduced by 40%” is.

A well-formed OKR creates a testable claim: if these key results are achieved, the objective has been realized. If the key results can be achieved without the objective becoming true, the key results are wrong.

What Outcome Goals Are Not

Outcome goals are frequently misused. Two failure modes are common.

Output disguised as outcome. “Deliver the new reporting module” is not an outcome goal — it describes a delivery. The outcome would be what changes when the module is in use: faster decision-making, reduced manual reporting effort, improved data quality in governance forums. Outcome goals require asking so what? of every delivery intent until a real-world change is named.

Outcome goals cascaded as delivery plans. OKRs are not a decomposition mechanism. A portfolio-level OKR does not break down mathematically into DVS-level PI goals or team-level sprint goals. DVS teams align toward outcome goals — they make their own judgment about which capabilities, if established, will move the outcomes most. Forcing mechanical cascade produces false precision and removes the judgment that makes delivery valuable.

The Verification Role

In a lean-agile delivery system, outcome goals are where the value hypotheses carried by PI goals and sprint goals are ultimately tested.

The loop works as follows: portfolio-level outcome goals express where value is sought. DVS teams form hypotheses about which capabilities, if established and used, will contribute to those outcomes. Those hypotheses are carried as PI goals. Individual sprints establish pieces of those capabilities. When the capabilities are in use, the organization observes whether the outcome goals are moving.

This means outcome goals are not inputs to planning in the same way that PI goals are. They are the reference frame against which the accumulated delivery of many PIs is evaluated. The question at strategic review is not “did we deliver what we planned?” — it is “are our outcomes moving, and are our current value hypotheses still aligned with where we want to go?”

Where to Go Next

FlowMetrics