Ask a team what they think of retrospectives and you get two answers. Some love them: it is the one hour where people say what they really think. Others treat them as a tax paid at the end of every sprint. Both groups usually share one experience: nothing changes afterwards. The same three complaints show up sprint after sprint, the same "we should" items get written down, and the board looks identical two weeks later.
The problem is rarely honesty or effort. It is that most retro formats optimise for collecting opinions, not for producing a change. This is the format we use on our own team. It takes about 40 minutes, it ends with exactly one improvement that has an owner, and it has a built-in check at the next retro so the improvement cannot quietly evaporate.
Why retros fail
Three patterns cover most of it.
- Too many outputs. Twelve action items means none of them are real. People leave the room with a list, not a commitment.
- No owner and no date. "Improve our testing" is a wish. "Bishal adds a smoke test to the deploy pipeline before Thursday's planning" is a task.
- No memory. Nobody reopens last sprint's action item. If it is never checked, it never has to happen.
A retro also drifts into a status meeting or a venting session when the sprint data is not in the room. Opinions about "we were slow" are much less useful than a burndown that shows exactly which day the sprint stalled and which tasks were still open.
The 40-minute format
1. Look at the data first (5 minutes)
Before anyone says a word, put the sprint on the screen: the goal, whether it was met, the burndown, and the list of tasks that carried over. In Kydero this is the sprint dashboard, so nothing needs to be prepared. The point is to anchor the conversation in what happened rather than in how it felt. A sprint that "felt chaotic" often turns out to have had one blocked task that held four others hostage for three days. That is a much more useful thing to talk about.
2. Silent writing (7 minutes)
Everyone writes on their own, no talking, under three headings: what helped, what hurt, and what puzzled them. The silence matters. Once the most senior person speaks, the room starts agreeing with them. Writing first means the quiet developer's observation about the flaky staging environment makes it onto the board next to everyone else's.
3. Group and vote (8 minutes)
Read the notes out, cluster the duplicates, and give everyone three votes. You are not choosing what is most true. You are choosing what is most worth fixing in the next two weeks. That framing matters: a real problem you cannot influence this sprint is a bad candidate, even if it gets the most nods.
4. Dig into one thing (12 minutes)
Take the top-voted cluster only. Ask why it happened until you reach something the team actually controls. "Reviews took too long" becomes "reviews sat for a day because nobody knew they were waiting" becomes "we have no signal for review requests". Now you have something to change.
Resist the pull to also "quickly cover" the second and third items. They will still be there next sprint, and a retro that fixes one thing per sprint fixes 26 things a year. That is far more than most teams manage.
5. Write the improvement as a task (5 minutes)
The output is one task, phrased like any other piece of work: a verb, an owner, a due date inside the next sprint. Put it on the board with the rest of the sprint's work, not in a separate document nobody opens. We tag ours retro so they are easy to find.
6. Close the loop on the last one (3 minutes)
This is the step that makes the format work. Open the retro task from the previous sprint and ask two questions: did it get done, and did it help? If it was not done, it either goes back on the board or you agree to drop it out loud. If it was done but did not help, that is a genuinely useful finding, and it usually means the "why" chain in step four stopped one level too early.
Making the improvement stick
An improvement that only exists in the retro notes has not been made yet.
A few habits that keep the loop closed:
- Treat the retro task like a sprint commitment. It gets the same status updates and the same visibility as feature work. When it shows up in the daily standup, it is real.
- Prefer process changes you can see on the board. A new column, a new label, a definition-of-done checklist item. If the change lives in the tool the team already uses, nobody has to remember to do it.
- Rotate the facilitator. The person who runs the retro should not always be the lead. It changes what gets said, and it spreads ownership of the format itself.
- Keep the history. A list of the last ten retro tasks and whether each one helped is the most honest record of how a team is improving. It is also very persuasive when someone asks whether retros are worth the time.
Signs it is working
You will know the format has landed when the same complaint stops showing up twice, when people start proposing improvements in the middle of a sprint instead of waiting for the retro, and when the "what hurt" column gets shorter without anyone forcing it. That last one takes a few months. The first two usually show up within three or four sprints.
If you only change one thing about your retros, make it step six. Reopening last sprint's improvement in front of the whole team is what turns a discussion into a habit.