PI Goals

A PI goal describes a working output that a DVS commits to having in place by the end of a Program Increment — and that we hypothesize will create value when used.

Outputs are the things we build. Outcomes are the impact those things have. PI goals live in between: they are working outputs — integrated, runnable, demonstrable — combined with a value hypothesis about what happens when those outputs are put to use. The output is verified at PI-end. The outcome is verified later.

This is not a feature list, and it is not a promise of business outcome. It is a shared hypothesis: we believe this capability, once used, will deliver value.

What a PI Goal Is

A PI goal has three components that together make it meaningful.

A working output. The goal describes something that will exist, run, and function at PI-end — not a set of activities completed or stories delivered. “Incident data is available and visible in the operational dashboard” is a working output. “Implement incident data stories” is not. Following the Agile Manifesto’s principle that working software is the primary measure of progress, a PI goal that cannot be demonstrated in running software at PI-end is not established — it is still in progress.

A value hypothesis. The goal carries an explicit belief that the working output can produce value if used. This belief is held jointly by the DVS, its product managers, and its stakeholders. It is not a guarantee. It is the best available judgment about where value lies given current knowledge. The hypothesis is tested when the capability is adopted and used — typically visible in outcome goal review at portfolio level.

A verification point. The goal is demonstrable at the System Demo and Inspect & Adapt at PI-end. Did the output get built and integrated? Does it run? These questions are answerable within the PI timebox — without waiting for adoption data or market response.

Why This Framing Matters

The distinction between outputs and outcomes is where most delivery systems break down.

Organizations that only track outputs — features shipped, stories completed, velocity — have no way of knowing whether their work has mattered. They optimize for delivery without knowing if delivery created value.

Organizations that only track outcomes — NPS, revenue, market share — have no natural accountability point at the pace of delivery. The feedback loop is too long to guide sprint-by-sprint and PI-by-PI decisions.

PI goals bridge this gap. Each PI produces working outputs that represent the current best hypothesis about where value lies. The hypothesis is tested when those outputs are adopted and used. That test happens in a different forum, on a different timescale. The PI goal is not the end of the value question — it is a step in a continuous loop: build, use, verify, learn, build again.

The Relationship to the Delivery System

PI goals sit at the DVS level. They are set during PI Planning and owned jointly by the value stream — product managers, the Value Stream Owner, technical leads, and the teams that deliver them.

Sprint goals nest inside PI goals: each sprint is a step toward one or more of the PI-level working outputs. A sprint goal that cannot be connected to any PI goal is a signal that scope has entered the sprint without shared intent.

PI goals align with outcome goals at portfolio level. They do not mechanically decompose from OKRs — they represent the DVS’s best judgment about which working outputs, if built this PI and subsequently used, will move the outcome goals most. The connection is directional, not mathematical.

Formulating a PI Goal

A well-formed PI goal answers three questions:

• What working output exists? State the capability or condition that will be in place and runnable.
• For whom? Identify who can use or benefit from it.
• What is the value hypothesis? Make the belief explicit — even briefly.

Example: Coordinated operational delivery planning is established and in use — common forums, clear roles, and shared visualization of work-in-progress. We believe this gives teams and leaders a shared operational picture that reduces coordination waste.

The “we believe” is not rhetorical. It signals that the goal is a hypothesis, not a guarantee — and that the organization will look back at PI-end and ask not only whether the output was built, but whether the hypothesis is holding up.

Evaluating PI Goals

At the System Demo and Inspect & Adapt, the DVS evaluates two things.

Delivery: Was the working output built and integrated? Can it be demonstrated in running software?

Hypothesis quality: Does the value belief still seem reasonable? Did we learn anything during the PI that changes our view of where value lies?

The second question is as important as the first. A PI that delivers all its working outputs but learns nothing about value has not closed the loop. The purpose of PI cadence is not just reliable delivery — it is the acceleration of organizational learning about what creates value.

See: Goals and Objective Setting for how PI goals relate to outcome goals at portfolio level and sprint goals at team level.