It is the last event of the Sprint, after the Review and before the next Planning. Ninety minutes for a two-week Sprint, three hours for a month.
And it isn't optional. It is how Scrum stops being a process you follow and becomes a system you improve.
Before anybody says anything
A Retrospective only works if people say true things. That is the entire mechanism, and it is more fragile than most Scrum Masters realise.
Think about it from inside the room. If a developer believes that naming a problem will be heard as blaming the Product Owner, she won't name it. If somebody thinks admitting he was stuck for a day makes him look slow, he'll describe it as “a bit of investigation”. What you end up with is a perfectly pleasant meeting that improves absolutely nothing.
Whatever we discover, we understand that everyone did the best job they could, given what they knew at the time, their skills, the resources available, and the situation.
It is a rule that makes the conversation possible at all, because it puts the situation on trial instead of the person. Without it, the accurate version of a bad Sprint becomes “Alex didn't check the acceptance criteria” — and Alex spends ninety minutes defending himself instead of helping fix it.
This is the one thing in the event you must protect. Everything else is technique.
Three questions
1 — What went well?
Beauty Spot's answers: the daily rhythm once they found it, the twelve acceptance criteria that felt excessive when written, and refinement homework done before the session.
None of that was luck. Every one was a deliberate choice made earlier. That is part of what this question is for — a team gets to discover which of its habits are genuinely working, so it keeps doing them on purpose rather than by accident.
2 — What could be improved?
Four people, four admissions, no defensiveness anywhere in the room. A developer who raised an impediment and didn't chase it. A Scrum Master who had it and didn't clear it. A Product Owner who accepted an Increment he hadn't checked. A developer who built a workaround and called it done.
It took about four minutes, because the room already trusted each other from two weeks of Daily Scrums. The safety wasn't created in that meeting. It was created before it.
3 — What will we change?
Three candidates went on the board. Everyone wanted all three.
“We're picking one.”
“Why? They're all quick.”
“Because three changes means nobody owns any of them. In two weeks we'll have done none of them and we'll feel bad about it. One change we actually make beats three we agree to.”
They chose the first — correctly, because it was the cause and the other two were symptoms of it.
The action format
Four fields. All four matter, because a retrospective action without an owner and a check is just a wish — and a team that produces wishes for three Sprints running stops believing in the event entirely.
IMPROVEMENT ACTION — SPRINT N What the change, stated so somebody could tell whether it happened Owner one name. Not "the team" How we the observable signal — what you would see will know if it is working Check reviewed at the next Retrospective BEAUTY SPOT, SPRINT 2 What No item enters a Sprint with an unresolved dependency. No exceptions, including "we'll sort it during the Sprint." Owner Christian How we At Sprint Planning, ask out loud, of every will know selected item: "is anything on this unresolved?" Check Reviewed at the next Retrospective.
And what happened to the third candidate.
Nobody made it an action. The Product Owner started reading the acceptance criteria aloud at Reviews anyway, without being asked.
Some improvements don't need an action item. They need somebody to have been embarrassed once.
How Retrospectives die
Five ways. You will meet every one of them eventually.
- The efficient meeting trap — finishes in twenty minutes, everyone says it went fine
- The complaint session — all problems, no actions
- The list — six improvements, no owners, nothing happens
- The audience problem — a manager sits in "just to listen"
- Groundhog day — the same issue raised every Sprint and never fixed
The first is the most dangerous, precisely because it looks like success. A team with nothing to improve is a team that has stopped looking. If yours keeps finishing early, the problem isn't that you're excellent.
The complaint session is cathartic the first time and corrosive by the third. The list teaches the team the whole event is theatrical. The audience problem stops honesty instantly — the Retrospective is for the Scrum Team. And Groundhog day: either fix the thing, or say plainly that it cannot be fixed and stop spending the team's hope on it.
Keep the summary
Retrospectives don't create a Scrum artifact, but they produce real outputs: the improvement action, and a short summary of the discussion points and decisions.
That summary earns its keep slowly. Over several Sprints it lets you see patterns — the same issue recurring, an improvement that quietly stopped being used and nobody noticed.
A single Retrospective changes very little. Twelve of them, tracked, change how a team works.
Where this sits
The Retrospective improves how the chain gets worked. Its actions land in the next Sprint Planning, and they often change a standard — Beauty Spot's Definition of Done gained a line this way, raised by a developer who noticed something slightly off.