# Read sprint metrics without overstating delivery

Illustrative planning brief; no automatic product import.

Illustrative case: completed-task counts increased, but the sprint outcome has not yet been accepted by its reviewer.

## Decision

Report the metric observation and obtain separate acceptance evidence before calling the outcome delivered.

## Owned work

- Resolve the sprint scope
  - Owner role: Reviewer
  - Acceptance evidence: The metric request targets the intended sprint and workspace.
- Read the metric boundary
  - Owner role: Analyst
  - Acceptance evidence: The summary states whether evidence is current or daily and notes unavailable values.
- Connect to acceptance
  - Owner role: Outcome owner
  - Acceptance evidence: The accepted outcome is supported by its actual review evidence.

## Workflow

1. Read the scoped sprint metrics.
2. Inspect the documented meaning of each field.
3. Pair the observation with acceptance evidence and explain limits.

## Judgment

Task counts do not establish productivity gains or customer impact.


## Illustrative metrics note

Observed: report the supported metric and its observation scope.
Not established: acceptance of the sprint outcome.
Next decision: the outcome reviewer checks actual delivery evidence.


## Workflow questions

### Can a count prove the sprint goal was met?

No. The goal needs its own acceptance condition and evidence.

### How should missing metrics be shown?

As unavailable unless the source semantics establish zero; do not fill gaps with invented values.

## Product connection

Use the TeamBoost CLI sprint metrics example as a starting point for checking what changed, alongside evidence of accepted work.

Confirm account availability before adopting this manual outline.