Standup and retrospective formats that work

Almost every team that has run a standup has run this one. Each person answers three questions in turn: what did I do yesterday, what will I do today, what is blocking me. It is easy to teach and it gives a new team a shape to hold on to.

It is worth knowing that Scrum stopped prescribing it. The 2017 Scrum Guide offered the three questions as an example structure; the 2020 revision removed them entirely and now says only that the Daily Scrum is a fifteen-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the plan, using whatever structure and techniques they choose. The three questions were never the ceremony. They were one implementation of it that outlived its own instructions.

The decay has a mechanism. Organising a meeting person by person makes the unit of attention a person, and once the unit of attention is a person, every update is implicitly an account of how that person spent their time. People start padding. Nobody wants to be the one with a thin yesterday, so small tasks get narrated at length and the meeting fills with information nobody needed. The manager, if present, becomes the natural audience, because a report needs a recipient. Within a couple of months the team is holding a daily status meeting with a Scrum name on it.

There is a second, quieter failure. A round of individual updates can never surface the thing most worth surfacing: the work item nobody mentioned. A ticket that has been sitting in review for nine days has no owner enthusiastic enough to bring it up, so it simply does not come up. The format is structurally blind to exactly the problem it exists to catch.

Parabol's catalogue of standup variants runs to fourteen, which is more than any team needs. Five cover almost every real situation. The move that most of them share is switching the unit of attention from the person to the work.

If you change one thing, change to walking the board. It removes the incentive to justify your day, and it makes the stalled item impossible to miss, because you physically pass over it on the way to the next column. A useful companion habit is rotating who facilitates. When the same person runs the meeting every day, the meeting points at that person; rotation redirects it back at the team, and it costs nothing to try.

Focus of the day is the most underrated of the five. Asking for one intended outcome, not a list exposes overcommitment quickly: someone who cannot name one outcome usually has five half-started ones. It pairs with the single-priority discipline in Ivy Lee, Eat the Frog and ABCDE.

The timebox is what makes the format work, and Atlassian's guidance on the ritual makes the original reasoning explicit. The meeting is called a stand-up because standing up is uncomfortable, and discomfort ends meetings. Asana's version of the advice adds the other half, same time and same place every day, so no scheduling decision is ever made. Remote teams lose the physical constraint and need to reinstate it deliberately.

• Take it offline by name, not in general. "Let's pick that up after, Sam and Priya, ten minutes" works. "Let's take that offline" without names means nobody owns it and it happens again tomorrow.
• Use a visible timer. On video, a shared countdown does the job standing used to do. It also stops the facilitator from having to police anyone personally.
• Cap the room at the people whose work interlocks. Twelve people in a standup is a status broadcast. Two groups of six, standing separately, are two standups that finish on time.
• Start on time regardless of who is missing. Waiting punishes the punctual and teaches the room that the start time is decorative.

If the standup consistently overruns, treat it as a signal, not a discipline problem. It usually means the team needs a longer weekly coordination or refinement session and the standup is absorbing demand for it. Adding the right meeting is often what lets you shorten the wrong one, which is the inverse of the usual advice in meeting overload.

A retrospective is the inspect-and-adapt step applied to the team's own way of working, not to its product. Scrum places it at the end of the Sprint, after the Review, and timeboxes it at a maximum of three hours for a one-month Sprint, proportionally less for shorter ones. In practice a two-week team runs sixty to ninety minutes.

The canonical structure comes from Esther Derby and Diana Larsen's Agile Retrospectives: Making Good Teams Great, which breaks the session into five stages: set the stage, gather data, generate insights, decide what to do, close the retrospective. Nearly every named format you will encounter is a way of doing stages two and three. The formats differ in what they make easy to say. They do not differ in whether stage four happens, and stage four is the one teams skip.

Norm Kerth's prime directive, from Project Retrospectives: A Handbook for Team Reviews, is the standard opening for stage one: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." Reading it aloud sounds ceremonial the first time and stops sounding that way around the third, when someone is about to describe a decision that went badly and needs to know the room is examining the decision rather than them.

Rotating between two or three formats stops the format itself becoming the ritual. A team that has run Start / Stop / Continue eleven times in a row will produce roughly the same three items on the eleventh occasion, not because nothing changed but because the prompt has stopped prompting.

Atlassian's Team Playbook and most facilitation guides converge on the first three. The sailboat is a descendant of Luke Hohmann's Speed Boat exercise from Innovation Games, and 5 Whys comes from Sakichi Toyoda and the Toyota Production System, where it is a root-cause tool, not a retrospective format. That lineage matters in one respect: 5 Whys assumes you already know which event to examine, so choosing it means choosing the topic in advance.

Pick the format after looking at the cycle, not before. A quiet, slow cycle wants Start / Stop / Continue. A tense cycle wants Mad / Sad / Glad. A cycle that ended a project wants 4L. A cycle with one bad outage wants 5 Whys on the outage and a short normal retro on everything else. Choosing afterwards is most of what separates a useful retrospective from a recurring calendar entry.

The characteristic retrospective failure is a productive-feeling ninety minutes, forty sticky notes, broad agreement that things could be better, and an identical set of notes next cycle. Five rules fix it, and the first two do most of the work.

• Leave with one action, two at most. A retrospective that produces nine improvements produces none. Dot-vote the clusters, take the top one, and let the rest go. Anything that matters will come back next time, louder.
• Every action has a named owner and a date. "The team will improve estimation" is a sentiment. "Priya adds a sizing step to refinement, in place by the 14th" is an action. A team, collectively, is not an owner.
• Open the next retrospective with the last one's action. Five minutes, done or not done, no discussion of why beyond a sentence. This is the single change that makes people take the actions seriously, because it is the only moment at which not doing one becomes visible.
• Timebox each stage, not just the meeting. Gathering data expands to fill whatever you give it, and then the decision stage gets four rushed minutes at the end. Ten minutes to set the stage, twenty to gather, twenty to generate insights, twenty to decide, five to close.
• Separate what you control from what you do not. Keep a short second list for organisational constraints, escalate it to someone who can act on it, and refuse to relitigate it every cycle. A team that spends forty minutes on a company-wide policy is learning that retrospectives change nothing.

Two conditions sit underneath all five. The first is psychological safety: if the person who writes performance reviews is in the room and the team has not agreed how that works, you will get a polite retrospective containing no information, and no format will rescue it. The second is that actions need somewhere to live. An action that exists only in the retro board is an action nobody will see again. The commitment has to land in the tracker the team actually opens.

Both rituals have an async form. GitLab's all-remote handbook, the most detailed public description of an async-first company, treats written updates as the default and synchronous time as the exception that has to justify itself. Forbes contributor Laurel Farrer has estimated that roughly forty per cent of meetings could be handled asynchronously without loss; whatever the exact share, the daily standup is near the top of the list, because most of its content is broadcast, not discussion.

The async standup is a fixed prompt posted in a channel, answered by a deadline, not in a meeting. Keep the prompt short, two lines per person at most, because an update that takes ten minutes to write will not be written by Thursday. Require a reply and not just a post. The value is in the thread under the blocker, and a channel where nobody replies is a status report with extra steps. Set a real deadline, since an update posted at 4pm coordinated nothing. Most teams keep one live call a week for the discussion that threads handle badly.

The async retrospective splits Derby and Larsen's stages across time instead of compressing them. Open a board two days before the cycle ends and let people add items as they think of them, which reliably produces items from week one that nobody would have recalled live. Vote asynchronously. Then hold a short live session, twenty-five to thirty minutes, for generating insights and deciding, since those two stages depend on people building on each other in real time. The hybrid usually beats either pure form. The data is more complete and the live part is short enough that people show up.

The general principle is that async is not the same meeting in text. It is a different split between what is broadcast and what is discussed, and a ritual has to be redesigned around that split instead of transcribed into it.

These two ceremonies sit inside a larger frame. The principles underneath them, inspect and adapt, work in progress limits, pull rather than push, are covered in Agile, Scrum and Kanban. For the general question of which meetings should exist at all, see meeting overload. The retrospective's close relative, run after one discrete event rather than on a cadence, is the debrief, and the two are worth keeping separate, not merged. Neither ritual needs a tool, a licence or a mandate. A standup needs a different organising unit and a timer; a retrospective needs one owned action and someone willing to read it out next time.