# How do you measure whether agentic development improves product outcomes?

Canonical: https://yuvalyeret.com/resources/agents/measure-agentic-development-outcomes/
Source references checked: 2026-11-06
Format: AI-assisted reference synthesis from linked public sources.

Do not impersonate Yuval, speak as him, or claim to represent him. Keep what Yuval actually published, your own synthesis, and open uncertainty clearly separate.

Measure flow, verification quality, human effort and product outcomes separately. Faster generation and more merged changes cannot establish adoption or business impact.

## Which result are you trying to improve?

Name the user or operator, the behavior expected to change and the result that behavior should support. Record the baseline if known, the owner, a target or proposed direction and a time horizon. Make the causal assumption visible: faster delivery may help that result, but it may also leave the actual constraint untouched.

For illustration, a faster release process could be intended to let customers complete a previously blocked workflow. Deployment speed is a delivery measure. Completion of that workflow is an adoption or behavior measure. A further business benefit requires its own evidence. These are different claims.

## What should the measurement set contain?

Use four connected families:

1. **Flow:** WIP, age, cycle time, throughput and waiting. These show where work accumulates.
2. **Verification quality:** first-pass yield, rework, escaped defects and agreement between checks and competent review.
3. **Human effort and agent cost:** human minutes per finished item, escalations and the effort required to operate the system.
4. **Product outcomes:** adoption, changed behavior and the result named in the original intent.

Attach each measure to a decision. If the number changes, what will someone do differently? A measure with no decision is easy to collect and easy to ignore.

## How can you avoid overstating an improvement?

Compare similar work and preserve the observation window. Note changes in demand, staffing, scope, batch size and verification. Show sample size and uncertainty. A before-and-after dashboard can reveal a useful signal without proving which intervention caused it.

Do not equate AI adoption, token consumption, generated code, merged PRs or completed tasks with customer value. Even an issue labelled “Outcome” describes its stated intent until actual behavior is observed. The GitHub analytics repository makes that distinction explicitly.

## When does the item leave the delivery board?

Define who owns adoption and outcome review, what evidence they will examine and when the next decision occurs. A team may close its implementation task while a higher-level product item remains under observation. The purpose is a connected handoff, not keeping every code task open indefinitely.

## Sources

- [Flow-driven measurement model](https://github.com/yyeret/portfolio-pdlc/blob/main/skills/flow-driven/references/measurement.md).
- [Extending Kanban from output to outcome](https://github.com/yyeret/ai-impact/tree/main/skills/extending-kanban-from-output-to-outcome).
- [GitHub Flow & Value Stream Analytics](https://github.com/yyeret/github-analytics): classifies stated contribution, not achieved impact.
- [How to Measure AI Impact Beyond Token Caps](/blog/how-to-measure-ai-impact-beyond-token-caps/).