Mad Sad Glad Retrospective: The Emotional Intelligence Your Team Needs

Mad Sad Glad Retrospective: The Emotional Intelligence Your Team Actually Needs

Most teams don’t need another framework. They need the courage to say, “I’m angry we shipped that,” or “I’m proud of this, and nobody noticed.”

That’s what the Mad Sad Glad retrospective is for.
Not more stickies. More honesty.

Yet most teams either:

Treat it like a fluffy feelings circle, or
Avoid it because “we’re engineers, not therapists”

Both are wrong. Used properly, Mad Sad Glad is one of the most practical, data-rich formats you can run—because emotions are signals about system health.

Let’s make it tactical, not touchy-feely.

What Is a Mad Sad Glad Retrospective (Really)?

The basic format (stripped of buzzwords)

You ask the team to reflect on the last sprint/iteration and categorize their experiences into three buckets:

Mad – What frustrated or angered you?
Sad – What disappointed or demotivated you?
Glad – What made you proud, energized, or hopeful?

Usually done with:

Silent writing (stickies or digital cards)
Grouping and discussion
Turning insights into concrete actions

That’s the mechanics. But mechanics aren’t the point.

The real purpose: emotional telemetry for your system

Your team’s emotions are real-time telemetry for:

Process friction (Mad)
Culture and trust (Sad)
Motivators and strengths (Glad)

You already track:

Cycle time
Lead time
Defect rates

But if you ignore how people feel about the work, you’re blind to:

Burnout risk
Hidden conflict
Unspoken misalignment
Quiet quitting before it happens

A 2023 Gallup report showed that only 23% of employees are engaged at work globally. You can either wait for that to show up as attrition and missed deadlines, or you can surface it early in retros.

Mad Sad Glad is a low-friction way to do exactly that.

Why Most Retros Don’t Work (and How Mad Sad Glad Fixes It)

The usual retro is a status meeting in disguise

Typical retro pattern:

“What went well?”
“What didn’t?”
“What can we improve?”

What happens:

Same three issues every sprint
People stay on the surface
Blame gets disguised as “root cause analysis”
Action items are vague: “Communicate better”, “Plan more”, “Be proactive”

You leave thinking, “We did a retro,” but nothing changes.

Emotions force specificity

When you ask:

“What made you mad?” you get:

“We got a surprise ‘urgent’ feature from sales again on Thursday.”
“What made you sad?” you get:

“We closed 14 tickets, but the only thing leadership cared about was the one bug in production.”
“What made you glad?” you get:

“Pairing on that tricky refactor actually saved us time and was fun.”

These are:

Concrete
Human
Actionable

Suddenly, your retro isn’t about generic process labels. It’s about specific events that actually affected people.

Emotional language ≠ therapy session

Let’s be blunt:
If your engineers roll their eyes at “feelings,” that’s a trust problem, not a format problem.

You’re not asking:

“Tell me about your childhood.”

You’re asking:

“What in this sprint made you angry enough that you considered ignoring that ticket?”
“What made you feel like your work didn’t matter?”
“What made you think, ‘I want more of this’?”

That’s not therapy. That’s operational feedback with emotional context.

How to Run a Mad Sad Glad Retro That Doesn’t Suck

1. Set a clear, sharp focus

Don’t just say, “Let’s reflect on the last sprint.”

Pick a lens like:

“This retro is about how we worked with other teams.”
“This is about our release process.”
“This is about the last production incident.”
“This is about the last 4 sprints as a whole.”

Specific focus → specific insights.

2. Create psychological safety without being fluffy

You don’t need a TED Talk on vulnerability. You need three sentences:

“We’re here to improve the system, not judge individuals.”
“Speak from your own experience: ‘I felt…’ not ‘They always…’.”
“No consequences for honest feedback. If that’s not true, that’s my failure as facilitator.”

Then back it up by:

Shutting down blamey language
Protecting quieter voices
Not letting leadership dominate the conversation

3. Collect input silently and (ideally) anonymously

Process:

Give people 5–10 minutes of silent writing.
Ask for at least 2–3 items per column (Mad, Sad, Glad).
Use a digital tool or sticky notes.

Why anonymous helps:

Reduces performance/manager pressure
Surfaces dissent from quieter or newer team members
Avoids anchoring on the first loud opinion

Example prompts:

“What made you mad enough that you thought, ‘This is broken’?”
“What made you sad enough that you thought, ‘Why am I doing this?’”
“What made you glad enough that you thought, ‘We should do more of this’?”

4. Group, then vote, then dig deep

Steps:

Cluster similar items under themes (e.g., “surprise work”, “testing pain”, “handoff chaos”).
Give everyone 3–5 votes to pick topics they care about most.
Discuss top 2–3 themes only. Depth beats breadth.

For each theme, ask:

“What’s really going on here?”
“Who is impacted and how?”
“What’s the smallest experiment we can run next sprint to improve this?”

Write down actions in this format:

Action – clear behavior change
Owner – single name
When – specific date or “by end of next sprint”

Example:

“Action: Add a ‘no new work after Wednesday’ rule for the sprint unless PO + team agree. Owner: Priya. When: Starts next sprint.”

Real-World Examples: What Teams Actually Surface

Mad examples (frustration / anger)

“Mad: We merged a huge feature on the last day of the sprint again.”
- Signal: Risky delivery habits
- Possible action: WIP limits + feature flags
“Mad: Product changed priorities mid-sprint without talking to us.”
- Signal: Broken commitment model
- Possible action: Explicit “change process” with trade-offs

Sad examples (disappointment / demotivation)

“Sad: No one from leadership joined the demo.”
- Signal: Work feels invisible
- Possible action: Require at least one stakeholder for demo; rotate invites
“Sad: We keep postponing tech debt tickets we agreed were important.”
- Signal: Values vs. reality gap
- Possible action: Reserve a fixed % of capacity for debt/refactoring

Glad examples (energy / motivation)

“Glad: Pair programming on the new service cut our debugging time in half.”
- Signal: Collaboration works
- Possible action: Schedule 2–3 pairing blocks next sprint
“Glad: The new CI checks caught a bug before it hit prod.”
- Signal: Good investment
- Possible action: Expand coverage / add more checks

Patterns over 3–4 sprints become hard data:

“Mad about surprise work” every sprint → your planning is theater
“Sad about lack of recognition” → engagement risk
“Glad about pairing and TDD” → invest more there

Common Mistakes in Mad Sad Glad (What Not to Do)

Mistake 1: Treating it as a venting session

If people walk out feeling lighter but nothing changes, you’ve wasted their time.

Avoid:

Letting discussions spiral into storytelling with no outcome
Ending topics without a clear next step

Fix:

End each theme with: “What’s one concrete experiment we’ll run next sprint?”

Mistake 2: Ignoring the “Glad” column

Teams love to:

Spend 80% of the time on Mad/Sad
Rush through Glad in 3 minutes

That’s backwards.

The Glad column tells you:

What to protect
What to amplify
What actually motivates your team

If you only fix pain but never double down on what works, you end up with a team that’s… fine. Not engaged, not proud. Just… fine.

Mistake 3: Letting managers or senior devs dominate

Symptoms:

Everyone waits for the tech lead to speak
Junior devs never add cards
All “Mad” items are safely about external teams

Fixes:

Use anonymous collection
Have leaders speak last, not first
Explicitly invite: “We haven’t heard from anyone who joined in the last 6 months—anything in Mad or Sad you want to highlight?”

Mistake 4: Turning emotions into blame

Bad pattern:

“I’m mad that QA didn’t catch that bug.”
→ Discussion becomes “why QA failed”

Better:

“I’m mad that bugs keep reaching production.”
→ System-level discussion: requirements, test strategy, environments, time pressure

Facilitator move:

Redirect from “who” to “how”:
“Let’s talk about the system that made this likely, not the person who was last in the chain.”

Mistake 5: Making it a rare, “special” retro

Using Mad Sad Glad only:

Once a year
After a disaster
As a “fun” retro

…means you only hear real emotions when things are already bad.

Instead:

Rotate it in regularly (e.g., every 3rd retro)
Use it after high-stress events (big release, outage) and after normal sprints

Consistency normalizes emotional honesty.

Turning Feelings into Measurable Improvement

Emotional data is useless unless you treat it like data.

1. Track themes over time

Keep a simple log:

Date
Top 2–3 Mad themes
Top 2–3 Sad themes
Top 2–3 Glad themes
Actions taken

After 6–8 weeks, look for:

Repeated Mad/Sad themes → systemic issues
Disappearing themes → successful changes
New Glad themes → emerging strengths

2. Turn emotions into hypotheses

Example:

Observation: “Mad about surprise work” appears 4 sprints in a row.
Hypothesis: “If we introduce a ‘change request’ policy, frustration will drop.”
Experiment: For 2 sprints, any mid-sprint change must:
- Be visible in the board
- Have something else explicitly dropped
- Be acknowledged by PO + team in Slack

Measure:

Number of Mad cards about surprise work
Qualitative feedback in retro

3. Connect emotional signals to business outcomes

When leadership asks, “Why are we doing this touchy-feely retro format?” answer with:

“We reduced production incidents by 30% after addressing repeated ‘Mad’ themes about rushed testing.”
“We cut cycle time by 20% by leaning into practices that showed up in ‘Glad’—pairing and trunk-based development.”
“We stabilized attrition after we tackled ‘Sad’ themes around lack of recognition and unrealistic deadlines.”

Emotional intelligence is not “soft.” It’s leading indicators of hard metrics.

Practical Facilitation Tips for Scrum Masters & Product Owners

If you have 60 minutes

Suggested timebox:

5 min – Frame purpose and focus
10 min – Silent writing (Mad/Sad/Glad)
10 min – Grouping and reading themes
25 min – Discuss top 2–3 themes and define actions
10 min – Summarize actions, owners, and next steps

If your team is skeptical

Try:

Framing it as “debugging how the sprint felt”
Starting with Glad to avoid immediate negativity
Sharing one of your own items first (especially if you’re PO/SM):
- “Mad: I committed us to too much this sprint and you paid the price.”
- This models vulnerability without being dramatic.

If your team is remote or hybrid

Use a lightweight tool that supports:

Anonymous input
Easy grouping
Quick voting

You don’t need a heavy platform. Even something like ScrumPoi works well: it’s free, supports anonymous voting, and lets you spin up a retro without signups, right alongside your planning poker sessions.

Conclusion: Feelings Are a Feature, Not a Bug

If your retros are:

Repeating the same issues
Producing vague action items
Quiet, awkward, or performative

You don’t need a new canvas. You need emotional signal strength.

Mad Sad Glad:

Forces specificity
Surfaces hidden friction
Highlights what actually motivates your team

Use it regularly. Treat emotions as data. Turn that data into experiments.

Your codebase has logs and metrics.
Your process should too. Mad Sad Glad is how you finally start reading them.