A retrospective board collects what went well, what did not, and what to change, then works through the themes together. It is the standard end-of-sprint practice in agile teams and works equally well after any project.
The value depends almost entirely on whether anything changes afterwards. A retro that surfaces the same problems every sprint without resolving them stops being useful and quickly becomes something people resent attending.
Formats worth knowing
The simplest format asks what went well, what did not, and what to try. Start, Stop, Continue is similarly direct and often produces more actionable output because each column implies a decision.
Rotate formats occasionally. Teams that run the identical structure every sprint tend to produce increasingly formulaic answers, and a change of prompt often surfaces things the usual columns miss.
Frequently asked questions
- How long should a retrospective take?
- Around an hour for a two-week sprint. Longer sessions rarely produce proportionally more, and shorter ones tend to skip the discussion where the useful thinking happens.
- Why do retrospectives stop being useful?
- Almost always because nothing changes as a result. When the same issues recur without action, people stop raising them, and the meeting becomes a formality.
- How many actions should come out of a retro?
- Two or three at most, each with a named owner. Long action lists are a reliable sign that none of them will be done.
- Should managers attend?
- It depends on the team's trust level. Honest retros need psychological safety, and if people moderate what they say because of who is present, the session loses most of its value.