Mad Sad Glad

Mad, Sad, Glad helps a team explore how it felt about the past sprint before moving on to the next one. By naming what made people angry, what saddened them and what brought joy, the team surfaces emotional signals that plain metrics miss. Done well, it builds emotional awareness, strengthens team spirit and turns frustration into a constructive conversation.
😡 Mad

What made you angry — the things that went wrong more than once

Roman

Roman

The build broke four times and nobody owned the fix
Maria

Maria

Requirements changed on day six of a ten day sprint
Kirill

Kirill

Third time this quarter we found out about a launch from Slack
😟 Sad

What was disappointing — expectations that were never met

Anna

Anna

We cut the accessibility work again
Daria

Daria

The feature we rushed had no users in the first week
Roman

Roman

Two people were pulled onto a different project mid-sprint
😀 Glad

What went well and is worth protecting next sprint

Maria

Maria

The outage was handled calmly and documented the same day
Kirill

Kirill

New hire shipped their first ticket on day three
Anna

Anna

Customer wrote in to thank us for the export fix

What is Mad Sad Glad?

Mad Sad Glad is a retrospective format that sorts the sprint by emotion instead of by process. Each person writes what made them angry, what disappointed them and what made them happy, and the board turns those feelings into concrete, discussable events. It is one of the easiest formats to explain — three words, no training required — which is why it is often the first retrospective a new team runs.

The reason it works is that emotion is a faster index than analysis. People struggle to answer "what went wrong with our process this sprint" and answer instantly when asked what annoyed them. The annoyance points at the process problem, and the process problem is what you actually fix.

When to use Mad Sad Glad

  • A team's first retrospective — the format needs no explanation and produces material immediately.
  • After a tense or chaotic sprint, when there is unspoken friction that a process-shaped format will route around.
  • When previous retrospectives produced only safe, technical items and no one mentioned how the work actually felt.
  • After a release, an incident or a deadline crunch, when people need to say the thing out loud before they can analyse it.
  • With a mixed group — designers, analysts, support and engineers all have feelings about a sprint even when they do not share a process vocabulary.

It is a weaker choice when the team needs to plan a change rather than surface one. If you already know the problem and need options, a format built around actions — Start Stop Continue, DAKI or Starfish — will get you there faster.

The columns explained

Mad

Things that made people angry: repeated interruptions, a build that broke for the fifth time, a decision reversed without explanation, a review that sat untouched for three days. Mad cards are the highest-signal column because anger is usually attached to something repeatable. Push for the event, not the adjective: "the deploy pipeline failed on Thursday and nobody owned it" is workable, "the pipeline is terrible" is not.

Sad

Things that were disappointing rather than infuriating: a feature cut at the last minute, a colleague leaving, a demo nobody attended, an estimate that turned out to be fantasy. Sad cards often point at expectations that were never made explicit, which makes them the most useful column for uncovering unspoken assumptions inside the team.

Glad

Things that went well and made people happy: a painful migration that finally landed, help that arrived unprompted, a quiet week that let someone finish deep work. This column is not a courtesy round. It tells you what to protect — the practices in the Glad column are the ones that quietly disappear when the team gets busy.

Example board

A seven-person team ran Mad Sad Glad after a sprint in which two people were pulled onto an urgent customer escalation.

MadSadGlad
Pulled onto the escalation on Tuesday with no handover of my sprint workThe onboarding docs I planned to write got cut again — third sprint runningThe escalation was actually resolved, and the customer said so publicly
Three pull requests waited two days because the only reviewer was on the escalationWe demoed to an empty roomPairing on the hotfix meant two of us now understand the billing service
Nobody told the rest of us the sprint goal had changedI still do not know whether the API redesign is happeningThe new alerting caught the issue before support did

The discussion did not stay on the escalation. Two Mad cards and one Sad card all pointed at the same thing: when priorities change mid-sprint, nobody announces it. That became the single action item — any mid-sprint change of the sprint goal gets posted in the team channel by whoever makes it, same day.

Timing for a team of 5–10

StepTimeWhat happens
Frame the sprint5 minState the period under review and remind the team of the main events, so everyone is recalling the same weeks.
Write in silence8 minEveryone adds cards to all three columns at once. Cards stay hidden until the timer ends.
Read and group10 minReveal, read every card aloud, and merge duplicates into themes.
Vote3 minThree votes per person across all columns, including Glad.
Discuss the top themes20 minTake the top two or three. Ask what caused them, not who caused them.
Agree on actions10 minOne to three items, each with a named owner and a date.

Facilitator prompts

  • Mad: "What made you swear at your screen this sprint?" — "What did we do more than once that we should not have done at all?"
  • Mad: "What blocked you for longer than half a day?"
  • Sad: "What did you expect to happen that did not?" — "What did we lose this sprint that nobody mentioned?"
  • Sad: "What did you plan to do and never got to?"
  • Glad: "What went so well you would want it to happen again next sprint?" — "Who helped you, and how?"
  • On any card: "What happened right before that?" This turns a feeling into a chain of events, which is the only version you can act on.

Common mistakes

  • Letting Mad become a list of names. Redirect to the event and the system around it. "The review sat for three days" is a process fact; "Alex is slow" is an accusation and ends the conversation.
  • Skipping Glad because time ran out. The Glad column is where you learn what to defend. Teams that always cut it end up losing the practices that were working.
  • Accepting adjectives as cards. "Frustrating sprint" cannot be acted on. Ask for the specific moment.
  • Discussing every card. Ten people produce thirty cards. Group them, vote, and take the top two or three — the rest are recorded, not debated.
  • Ending without owners. An action item with no name attached is a wish. One owner per item, even when several people will do the work.
  • Running it every sprint forever. Emotional formats lose their edge with repetition. Alternate with an action-shaped format such as Starfish or DAKI.

How to run Mad Sad Glad in QRetro

  1. Create a board from the Mad Sad Glad template — the three columns are ready.
  2. Share the link; participants join in the browser without creating an account.
  3. Set a timer for eight minutes and let everyone write in silence, with cards hidden.
  4. Reveal the board, read every card, and group duplicates into themes.
  5. Give each person three votes and sort the columns by score.
  6. Discuss the top themes and turn the outcome into action items with an owner and a due date.

Frequently asked questions

Similar templates

Other formats teams pair with this one — open any of them as a board in one click.
Thumbs up, Thumbs down, new ideas and recognition
A light, balanced format that keeps the conversation moving between the good, the bad and the forward-looking. The team marks what deserves a thumbs up, what gets a thumbs down, the new ideas worth trying and the people worth recognizing. Adding recognition to the mix keeps the tone positive while still leaving room for honest criticism.
Lean Coffee
A meeting format that minimizes wasted time and boosts engagement by letting participants build the agenda themselves. Topics are proposed, voted on and discussed in order of priority, so the team spends time only on what truly matters to everyone in the room. First run in Seattle in 2009, Lean Coffee is easy to learn and adapts to almost any team conversation.
Original 4
The classic retrospective that laid the foundation for every method that followed. Built around four questions proposed by Norman Kerth in Project Retrospectives: A Handbook for Team Reviews, it asks what went well, what didn't, what the team learned and what still puzzles it. This timeless structure helps teams reflect honestly and keep striving for continuous improvement.
Starfish Retrospective
The Starfish gives the team five degrees of nuance instead of a simple good-or-bad split. Across keep doing, more of, less of, start doing and stop doing, participants fine-tune their practices rather than just label them. This granularity is especially useful for mature teams that want to adjust what already works rather than overhaul everything.
Three Little Pigs
Based on the fairy tale, this retrospective sorts the team's work by how sturdy it is. The house of straw stands for things that could easily fall apart, the house of sticks for what works but needs reinforcing, and the house of bricks for what is solid and stable. The playful metaphor makes it easy to spot fragile areas before they collapse.
Dot Voting
A fast, democratic way to prioritize when there are more topics or ideas than time to discuss them. Everyone gets a limited number of dots to spend on the items that matter most to them, and the team's attention naturally flows to what gathers the most votes. It's a simple technique to reach quick alignment without long debates.
Try Template