Retrospective actions that actually happen

Here is an illustrative list of actions from a retrospective: "Communicate better. Improve our estimates. Be more proactive about blockers. Look into test automation. Reduce meeting load." It sounds sensible, and everyone nodded. Three Sprints later, the same list comes back. Nobody was lazy. The actions were built so that they could not be done.

What the sources ask for

The Scrum Guide is short on this point and clear: the Scrum Team identifies the most helpful changes to improve its effectiveness, the most impactful improvements are addressed as soon as possible, and they may even be added to the Sprint Backlog for the next Sprint.

The SBOK® Guide gives the output a name. Its primary output of the Retrospect Sprint process is a list of agreed actionable improvements, which are actionable items the team has come up with to address problems and improve processes in order to enhance performance in future Sprints. It also lists assigned action items with due dates as a separate output, and treats the lessons learned as input to later Sprints. Both sources agree that the point is a change in the next Sprint, not a record of the last one.

Why they fail

Four reasons cover most cases.

1. They are too vague to start. "Communicate better" has no first step, so nobody can begin it on Monday morning.
2. There are too many. A list of eight competes with the Sprint's real work and loses.
3. Nobody owns them. An action everyone agreed to belongs to nobody in particular.
4. They live outside the work. If an improvement is on a wiki page and not in the Sprint Backlog, it is optional, and optional work is the first to be squeezed.

A fifth reason sits underneath: nothing happens to someone who does not do them. If the next retrospective does not ask what became of last time's actions, the team learns that they were never meant to be done.

Five habits that help

1. Choose few

Pick one to three. The Guide says the most impactful improvements are addressed as soon as possible, which implies ranking, not collecting. A useful question is: "If we only change one thing before the next Sprint, which would help most?" Vote on it, and put the rest on a parking list to revisit.

2. Make each action small and specific

Rewrite a vague action until it describes something a person could start today. Here are some before and after examples.

The test is whether a stranger could tell, at the next retrospective, whether it was done.

3. Give each one an owner and a date

One name, not a group. The owner is not the person who does all the work, but the person who makes sure it moves. In a self-managing team the owner is chosen by the team, not assigned by the Scrum Master. The SBOK output includes due dates for exactly this reason.

4. Put it in the Sprint Backlog

This is the step the Guide points to, and it is the one that works best. An improvement in the Sprint Backlog appears in the Daily Scrum, is subject to the same capacity as any other item, and is visible to the Product Owner. That visibility means the trade-offs are real: if the team takes on an improvement, something else is smaller. That is an honest conversation, and it is better than an unspoken expectation that the improvement happens in spare time that does not exist.

Some improvements are not tasks, such as "start reviewing each other's changes before merging". Capture them as an agreement and add a small checkable item to the board, for example "review pairing agreed; check at Daily Scrum on day 5".

5. Open the next retrospective with the last one

Spend the first ten minutes asking: what did we commit to, and what happened? Give each a status: done, partly, not started, dropped on purpose. "Dropped on purpose" is a good answer. The team looked, decided it no longer mattered, and said so. What is damaging is silent abandonment.

If the same action fails twice, change the way you ask. Make it smaller, or ask what is in the way. Often the real impediment is outside the team and belongs to the Scrum Master, who is accountable for causing the removal of impediments.

A worked example

Here is an invented, realistic case. A team of five finishes a Sprint where three stories were rejected at the review because tests were missing. In the retrospective they discuss several causes and settle on one: the Definition of Done says "tested" but nobody agreed what that means.

• Action chosen: write a one-page test checklist for a story, covering the unit, interface and booking flow checks, by Wednesday of the next Sprint.
• Owner: one Developer, who volunteers.
• Place: a task in the Sprint Backlog, sized at two hours.
• Check: at the next retrospective, did the checklist exist, and did any story miss it?

Nothing about this is dramatic. It is also the kind of change that moves the number of rejected stories, which a general resolution to "test more" would not.

Common mistakes

• Treating the list as the deliverable. The deliverable is a change in behaviour.
• Letting the Scrum Master do all of it. The Scrum Master facilitates and helps remove impediments, but the actions belong to the team.
• Repeating the same items for months. If an action has been on the list for three retrospectives, either it is not wanted or something is blocking it. Ask which.
• Ignoring wins. Noting what improved and why keeps people willing to try the next change.
• Only fixing symptoms. If every retrospective is about late work and the causes sit in how work is accepted, planning or interruptions, the actions need to go there.

The Agile Manifesto asks that the team tune and adjust its behaviour after reflecting. An action that is never done is a reflection without the adjusting.

How to practise it

It is easy to agree on actions and hard to commit to the right ones. In the simulator the retrospective ends with a choice about which improvements the team commits to, and the project ends with a retrospective on the whole release.