What is a retrospective, and why does it matter?
A retrospective is a structured team discussion focused on how the team works - not what the team ships, but how it ships. The goal is to identify what went well (so you keep doing it), what went poorly (so you fix it), and what changes the team should try next. Retros are the primary mechanism for continuous process improvement. Without them, teams repeat the same mistakes, accumulate friction, and gradually slow down without understanding why.
The most common failure mode for retros isn't that teams run bad ones - it's that teams don't run them at all. Retros get skipped when deadlines are tight, deprioritized when things seem fine, and abandoned when teams don't see immediate results. But the value of retros is cumulative. Any single retro might produce only one or two small improvements. Over six months of consistent retros, those small improvements compound into a significantly better-functioning team.
Retros are not blame sessions
A well-run retro operates under a core principle: everyone did the best they could given the information, skills, and resources they had at the time. The retro examines the system and the process - not the individuals. If a deployment went wrong, the retro asks "what about our deployment process allowed this failure?" rather than "who broke the deployment?" This distinction is critical. If people feel blamed, they stop contributing honest feedback, and the retro becomes performative.
The facilitator's job is to enforce this principle. If the conversation drifts toward blame, redirect it toward systems. If someone says "Person X always does Y," reframe it as "How can we prevent Y from happening, regardless of who's doing the task?"
Retrospective formats: choosing the right structure
There are dozens of retro formats. The differences are mostly in the categories of feedback they solicit. The underlying process is the same: collect feedback, group related items, discuss, identify actions. Here are the four most widely used formats and when each works best.
Start / Stop / Continue
The simplest and most popular format. Three categories:
- Start. Things the team should begin doing that they aren't doing yet. Examples: "Start writing card descriptions before assigning," "Start doing code reviews within 24 hours."
- Stop. Things the team should stop doing because they're wasteful or counterproductive. Examples: "Stop scheduling meetings for status updates," "Stop merging without tests."
- Continue. Things the team is doing well and should keep doing. Examples: "Continue the Friday async review," "Continue using labels for priority levels."
Start/Stop/Continue works best for teams that are action-oriented and want immediately actionable feedback. Every item in the "Start" and "Stop" columns is inherently an action item. On a kanban board, each category becomes a column, and each piece of feedback becomes a card.
4Ls: Liked, Learned, Lacked, Longed For
The 4Ls format surfaces not just process issues but also morale and growth. The four categories:
- Liked. Things the team enjoyed or found satisfying. Captures positive momentum.
- Learned. New knowledge, skills, or insights the team gained. Highlights growth.
- Lacked. Resources, information, or support that were missing. Identifies gaps.
- Longed For. Things the team wishes it had - tools, processes, time, clarity. Captures aspirations.
The 4Ls format is especially useful after learning-intensive periods - the first sprint with a new technology, a team restructure, or after onboarding new members. It balances process feedback with emotional and developmental feedback.
Mad / Sad / Glad
An emotion-centered format that surfaces team sentiment. The categories are self-explanatory: what made you mad (frustrated, angry), sad (disappointed, disheartened), or glad (happy, satisfied) during the sprint. This format is useful when team morale is a concern or when the facilitator suspects unspoken frustrations. It gives people explicit permission to express negative emotions in a structured way.
Timeline
The timeline format maps feedback to specific events or periods during the sprint. Instead of abstract categories, the board's columns represent weeks or key milestones (Sprint Start, Mid-Sprint, Demo Day, etc.). Team members place feedback cards at the point in time they occurred. This format is useful for long sprints or after multi-week projects where timing and sequence matter. It helps identify patterns - for example, recurring problems in the last two days before a deadline.
| Format | Best for | Board columns |
|---|---|---|
| Start / Stop / Continue | Action-oriented teams, simple facilitation | Start, Stop, Continue |
| 4Ls | Learning-focused teams, after transitions | Liked, Learned, Lacked, Longed For |
| Mad / Sad / Glad | Surfacing team sentiment and morale | Mad, Sad, Glad |
| Timeline | Long sprints, multi-week projects | Week 1, Week 2, Demo Day, etc. |
How to run a retro using a kanban board
A kanban board is a natural fit for retrospectives. Columns map to feedback categories. Cards are individual pieces of feedback. Labels can be used for voting and prioritization. The activity log records who posted what and when. Here's the step-by-step process:
Step 1: Set up the retro board
Create a new board for the retro using a team retrospective template (or reuse a recurring retro board, archiving old cards between sessions). Add columns matching your chosen format - for Start/Stop/Continue, that's three columns. Set the board's workspace access so every team member can create cards but consider limiting edit access to prevent accidental modifications of other people's feedback.
Step 2: Collect feedback (5-10 minutes, or async over 1-2 days)
Each team member adds cards to the appropriate columns. One idea per card. Cards should be specific and descriptive - "Start writing acceptance criteria on cards before sprint starts" is actionable; "Be better at planning" is not. For distributed teams, this phase works well asynchronously: open the retro board on Monday, give people until Wednesday to add cards, then hold the synchronous discussion on Thursday.
Step 3: Group and discuss (15-20 minutes, synchronous recommended)
Review the cards as a team. Group duplicates and related items - use labels to mark clusters, or drag related cards adjacent to each other. Discuss the themes that emerge. The facilitator reads each cluster aloud and invites brief commentary. Keep discussions time-boxed to prevent the retro from becoming a debate about a single issue. If a topic needs deeper discussion, note it and schedule a separate conversation.
Step 4: Vote on priorities (3-5 minutes)
Not every piece of feedback can be acted on immediately. Use labels as votes - create a "Vote" label and ask each team member to apply it to the two or three cards they consider most important. The cards with the most vote labels rise to the top as the team's priorities for the next cycle. This is faster and more democratic than verbal prioritization, where the loudest voices dominate.
Step 5: Create action items (5-10 minutes)
For the top-voted items, define a concrete action item. "Start writing acceptance criteria" becomes a specific card on the main work board: "Add acceptance criteria template to card creation workflow." Assign an owner and a due date. This is the most critical step - the one that separates retros that drive improvement from retros that produce meeting notes. If an action item doesn't become a tracked card with an assignee, it won't happen.
Using the activity log to review the sprint
Before collecting feedback, ground the retro in facts. Open the activity log and filter it to the sprint or period under review. The log shows every card created, moved, completed, and modified - with timestamps and attribution. This prevents the common retro failure where people can't remember what happened two weeks ago and the discussion defaults to whatever is freshest in memory.
Walk through the log as a team (or share it for async review before the retro). Note patterns: Were cards stuck in a particular column for too long? Did a burst of activity happen right before the deadline (a sign of poor planning or scope creep)? Were most cards completed by one or two people while others had light boards? The activity log surfaces these patterns objectively, without requiring self-reporting or estimation.
The log also helps validate retro feedback. If someone says "we spent too long in code review," the activity log can confirm or deny it - check how long cards spent in the Review column. Data-grounded retros produce better action items because they address real problems, not perceived ones.
Turning retro action items into tracked cards
The retro's output is only as valuable as the follow-through. The most common retro failure is generating a list of action items that nobody tracks. Two weeks later, at the next retro, the same issues come up because nothing was done about them. The fix is mechanical: every retro action item becomes a card on the main work board.
Use a dedicated label (such as "Retro Action") to distinguish process-improvement cards from feature work and bug fixes. This makes it easy to filter and track retro follow-through. At the start of the next retro, the facilitator pulls up cards with the "Retro Action" label and reviews whether they were completed, in progress, or abandoned. This accountability loop is what turns retros from a feel-good exercise into a genuine improvement mechanism.
Linking retro boards to the main board
Keep the retro board archived (not deleted) after each session. Over time, the collection of retro boards becomes a record of the team's evolution - what problems they faced, what they tried, and what worked. This history is valuable for onboarding new team members and for recognizing how much the team has improved. A new hire who reads the last three retro boards understands not just how the team works, but how it got there.
Retro cadence: how often and when
The most common cadence is every two weeks, aligned with the sprint cycle. The retro happens at the end of the sprint, after the sprint review and before the next sprint's planning session. This timing ensures that the sprint's work is fresh and that action items from the retro can be incorporated into the next sprint's plan.
For teams that don't use sprints, monthly retros work well. The interval is long enough to accumulate meaningful feedback and short enough to address issues before they calcify. Some teams also run ad-hoc retros after significant events - a production incident, a major launch, or a team restructure. These event-driven retros focus specifically on the event and its aftermath.
Regardless of cadence, consistency matters more than frequency. A retro that happens reliably every two weeks - even if it's only 30 minutes - builds the habit of reflection. A retro that's scheduled for every week but gets canceled half the time teaches the team that improvement isn't a priority.
For more on the rituals that keep remote teams aligned, see the remote team rituals guide. For the kanban board setup that supports retro boards and main work boards side by side, see kanban boards.