# Sprint Retrospective

A Sprint is one week of planned work. This page looks back at one Sprint and picks a single change to try next.

## Sprint Goal result

Judge the goal from proof you can see. "Partly met" is useful when it names exactly what is left.

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

## What helped

Name a practice, decision, or condition you can repeat. Not praise without a reason it worked.

- [A practice, decision, or condition that supported the result.]

## What got in the way

Describe one specific obstacle and the proof. Focus on the system and the choices you can change, not on blaming yourself.

- [A specific obstacle, backed by an example, a time record, or a failed result.]

## What you learned

Keep technical learning, process learning, and learning about how you learn separate. Then one can't hide the others.

- Technical:
- SDLC/Agile:
- Learning framework (how you learn best):

## One improvement for the next Sprint

Pick one change that is within your control. Say what signal would show whether it helped.

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

**Expected signal:** [What visible result should get better?]

**When you will check:** [A date or the next Sprint event.]

## Next step

[Write one clear action you can start without planning again.]

---

## About this template

A retrospective is a short look back at one week of work. It picks one change to try next, based on what the week's results actually showed.

> **What this teaches:** I can look at the proof from one Sprint and pick one process change I can measure. I don't blame anyone or collect vague wishes.

Before you look at the proof, guess what helped the Sprint most and what got in the way most. Then compare your guess with the dates, results, and examples.

Save this template to the exact private path printed by the current Sunday block, such as `weeks/week-01/retrospective.md`. Before Action 01, that block's **EXACT RECORD FILES** panel prints the complete commands. They download the template, then open, save, read back, and commit the file privately. Use its exact path. Don't create an unnamed copy.

**Explain it back:** Explain the proof behind your improvement and why you chose it over another idea. Then say when you will decide to keep, change, or drop it.

**Delete this whole section once you have filled the document in.** What is left should read as a finished document on its own.