Home → Part 07
Retrospective: Tracked Actions, Not Wishes
A retro whose output contains the sentence "we should test better" has failed. Definition, owner, deadline — without all three, what you are holding is not an action but a wish.
- An action has three parts: definition, owner, deadline. Missing one makes it a wish.
- Praise has to be concrete too. "We are great" sets no standard.
- Scope is this sprint and your own sphere of influence. Company policy is not solved in a retro.
- Untracked actions kill trust. The second time nothing is followed up, the team stops believing in the retro.
Why the retro is the most important ceremony
Even if you run every other ceremony flawlessly, the process freezes when the retro is neglected. The reason: Planning, Daily and Review manage the work; the retro manages how the work is done. The first saves this sprint, the second saves the next thirty.
To use the racing metaphor: if the sprint is the race, the retro is the pit stop — but not only to change tyres. It is there to remove the small frictions in the engine. Big transformations do not arrive in one go; they come from the compounding effect of small, consistent corrections.
1. Praise — but praise with substance
"What did we do badly?" is usually the first question in a retro. But analysing what went well matters just as much — because for something to be repeatable, it first has to be named.
"Thanks to X for their help this sprint."
It floats, it is forgotten, it sets no standard.
"Thanks to X: when we needed to read from several sources, they showed us how to set up the strategy pattern. Instead of three separate if branches we now have one interface, and adding a new source is ten lines."
It recognises and it sets the bar.
Speaking this openly requires psychological safety. If people in the team are wondering "what happens if I say the wrong thing", the retro died before it started. That safety is not built in the retro; it is built every day — starting with a daily where raising a blocker and asking for help feels normal.
2. Actions, not wishes
The biggest killer of retros is the open-ended sentence. A good action has three parts:
| Part | Question | Rule |
|---|---|---|
| Definition | What will be done? | One sentence everyone reads the same way |
| Owner | Who will follow it? | A single person. "The team" is not an owner |
| Deadline | By when? | A date, or "by the end of sprint N" |
"We should improve code quality."
Every two weeks we will hold a one-hour code review session. Each session covers two
people's code: first the author walks through it, then the team discusses "how would we
write this better". Everyone speaks in turn.
Owner: Mehmet · Deadline: first session in week 2 of Sprint 14
Static analysis will be added to the pipeline. Rule: when I touch a class, I leave it
better than I found it. New code produces no additional warnings; PRs are not approved
until the quality gate passes.
Owner: Ayşe · Deadline: end of Sprint 14
Tracking metric: coverage, warning count, technical debt trend — reviewed at every retro
My own rule: a retro should produce at most three actions. A retro with eight actions produces the same result as one with none — none of them happen. Finishing three and taking a fourth beats starting eight and leaving them all half done.
3. Follow-up: the first five minutes of the retro
This is the most commonly skipped step. A retro should not open with new topics but with the actions from the last one. One question per item: was it done, and if not, why?
Without those five minutes the system quietly collapses. The first time, nobody notices. The second time, the team keeps writing actions but stops believing in them. By the third, the retro is a formality — and getting it back is very hard.
4. Scope: this sprint only, your influence only
How you worked in this sprint, technical bottlenecks, communication failures inside the team, process friction, tooling.
Catering, commuting, office layout, HR policy, general management decisions and anything else outside your sphere of influence.
These may be genuine problems, but discussing them in the retro only burns time — the team cannot change them. When focus disperses, so does the ability to produce solutions.
One framing helps here: assume everyone did the best they could with the knowledge, skills and conditions they had at the time. That assumption turns the discussion from a personal reckoning into process improvement. A room that stops looking for someone to blame becomes a room that finds causes.
Common mistakes
| Mistake | Symptom | Fix |
|---|---|---|
| Ending with a wish | "We should communicate more" | Require definition + owner + deadline |
| No follow-up | The same topic reopens every retro | Open the retro with last time's actions |
| Drifting off topic | HR, office and company policy get discussed | Park out-of-scope items on a separate list |
| Empty feedback | "It was great" / "It was terrible" | Ask for a concrete event behind every comment |
| The same people speaking | Two talk, six stay silent | Silent writing round first, then read out |
The last row is my addition and the one that helps most: before any discussion, everyone writes their items on their own, then they are read out. In retros that start verbally, the first speaker sets the entire agenda and the quieter people's observations are never heard.
Checklist
- Were last retro's actions reviewed one by one?
- Did this retro produce at most three actions?
- Does each action have a definition, an owner and a deadline?
- Is the owner one person, or did you write "the team"?
- Was at least one piece of concrete praise given?
- Were out-of-scope topics moved to a separate list?
- Did everyone in the room speak at least once?
Conclusion
The retrospective is the moment the team looks in the mirror. If you want a blurred reflection, keep producing wishes. If you want a clear one and real improvement, your praise has to be concrete, your criticism constructive and your actions trackable.
That is the end of the series. The common thread across all seven parts: the ceremonies are a chain, and each link feeds on the output of the previous one. The retro is the link that repairs itself — because it is the only place the other six can be fixed.
The concrete-praise distinction, the three-part action rule and the scope limit are adapted from İbrahim Demir's Retrospective post. The "at most three actions" rule, opening the retro with last time's actions and the silent writing round are my additions. Derby & Larsen's Agile Retrospectives and Amy Edmondson's The Fearless Organization are the base references.