# Sprint Retrospective

> **What this teaches:** I can inspect evidence from one Sprint and choose one measurable process improvement instead of assigning blame or collecting vague wishes.

Before reviewing the evidence, predict what most helped and hindered the Sprint. Then compare the prediction with dates, outcomes, and examples.

## Sprint Goal result

Judge the goal from observable evidence. “Partly met” is useful when it names exactly what remains.

- Goal:
- Result: Met | Partly met | Not met
- Evidence:

## What helped

Identify a repeatable practice, decision, or condition—not praise without a mechanism.

- [Practice, decision, or condition supported the result.]

## What got in the way

Describe a specific obstacle and evidence. Focus on the system and choices you can change, not personal blame.

- [Specific obstacle supported by an example, time record, or failed result.]

## What you learned

Separate technical learning, delivery-process learning, and learning-method insight so one does not hide the others.

- Technical:
- SDLC/Agile:
- Learning method:

## One improvement for the next Sprint

Choose one change within your control and define the signal that would show whether it helped.

**Change:** [One concrete change within your control.]

**Expected signal:** [What observable result should improve?]

**When you will check:** [Date or next Sprint event.]

## Next step

[Write one unambiguous action that can be started without replanning.]

## Explain it back

Explain the evidence behind the improvement, why you chose it over another idea, and when you will decide whether to keep, change, or stop it.
