What is a Mad Sad Glad retrospective?
A Mad Sad Glad retrospective is a structured team reflection that asks people to describe what made them mad, what made them sad, and what made them glad during a defined period of work. It is a lightweight way to gather emotional signals alongside facts, identify recurring conditions, and decide what the team should change or preserve. It is not a performance review, a vote on who is at fault, or a promise that every concern can be fixed immediately.
The words are deliberately human. “Mad” can point to blocked work or repeated interruptions; “Sad” can reveal a missed expectation or a difficult trade-off; “Glad” can uncover helpful collaboration or a practice worth keeping. A feeling is valid as a report of someone’s experience, but it is not automatically proof of another person’s intent. The team explores the conditions behind it with curiosity.
When should you use this format?
Use it after a sprint, launch, event, incident, or project milestone when the group needs a short, accessible way to compare experiences. It is especially useful for teams that are new to retrospectives or need more than a metrics-only review. It may be insufficient by itself after a serious safety incident, harassment report, or unresolved interpersonal harm; those situations need the appropriate confidential reporting and support process, not a public board exercise.
Copy-ready Mad Sad Glad retrospective template
Copy this structure into a document, whiteboard, spreadsheet, or team workspace. Duplicate it for each session so the original remains clean.
Session details
- Team or project:
- Period being reviewed:
- Date and facilitator:
- Participants and absent voices to consult:
- Purpose and desired outcome:
- Previous actions to review:
Mad — what frustrated or blocked us?
- What created unnecessary effort, waiting, confusion, or rework?
- Which expectation or agreement was not met?
- What would you change if you could remove one source of friction?
Sad — what disappointed, worried, or cost us something?
- What did we hope would happen that did not?
- What was difficult to lose, defer, or compromise?
- What concern should we understand before it grows?
Glad — what helped, succeeded, or gave us energy?
- What are you proud of from this period?
- Who or what made the work easier? What specifically happened?
- Which practice should we repeat or strengthen?
Patterns and actions
- Pattern or insight:
- Evidence or examples (without assigning blame):
- Action / small experiment:
- One accountable owner:
- First step and due date:
- How will we know it helped?
- Review date:
Keep the prompts open. People may contribute to one, two, or all three columns; they do not owe the group a disclosure about their private life or emotional state. “Pass” is a valid choice. For some teams, rename the columns “friction,” “concerns,” and “wins” if the emotional labels feel unnatural, while retaining the intent of the exercise.
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.
How do you facilitate a Mad Sad Glad retrospective?
A useful session usually takes 45 to 60 minutes for a team of five to eight. Scale the time to the number of participants and the complexity of the work, not to a rigid agenda. The facilitator’s job is to make participation possible, keep the conversation focused on learning, and ensure decisions are visible—not to defend the process or force consensus.
1. Prepare the room and define the scope
Choose a period everyone can remember, such as the last two-week sprint or the release from kickoff to launch. Share the purpose, agenda, and any relevant facts beforehand. Prepare three labeled areas and a separate action area. If the previous retrospective produced commitments, bring their status so the group can see whether the process follows through.
Agree whether notes will be attributed, anonymous, or summarized without names. Explain who can access them and how long they will be retained. Do not promise anonymity if the tool or small group makes authors identifiable. If a topic involves confidential personnel information, route it to the right channel rather than recording sensitive details on a shared board.
2. Open with safety and a check-in
State that the aim is to improve the work system, not judge people. Invite specific observations and curiosity. A simple opening might be: “We are here to understand what shaped this period and choose a change we can test. We will discuss actions and conditions, not label people. You may pass, write privately, or ask for a pause.”
A brief check-in can help people arrive, but avoid requiring everyone to disclose feelings. Let participants know what happens if a serious concern comes up. Safety is built through consistent responses—especially when feedback is uncomfortable—not by displaying a slogan and moving on.
3. Write before discussing
Give everyone five to eight quiet minutes to add notes. Silent writing reduces anchoring on the first speaker and gives people who need more processing time a fair start. Ask for one observation per note, with enough context to understand it later. Participants can use initials, anonymous input, or a private message to the facilitator if agreed in advance.
The facilitator should not read each note aloud in a way that exposes its author. Invite clarification without cross-examination: “What was happening when this occurred?” is more useful than “Who did that?” If the board becomes crowded, group similar observations together while preserving differences in impact.
4. Find patterns, then choose what to discuss
Read the notes, name recurring themes, and invite participants to add missing context. A dot vote can help identify topics, but it should guide time allocation rather than determine whose experience matters. A low-vote item may still need immediate attention if it signals risk, exclusion, or a serious blocker.
Use questions that move from reaction to learning: What conditions made this likely? What did we expect? What was within our control? What would make the next attempt safer or easier? What evidence would tell us the change worked? Avoid debating whether someone is “right” to feel mad or sad. Explore impact and context instead.
5. Convert insight into a small experiment
Do not turn every note into a project. Select one to three changes the team can realistically test before the next review. Write each as a clear behavior or experiment, name one accountable owner, define a first step and a date, and agree how to evaluate it. The owner coordinates the action; that does not mean they alone must do all the work.
For example, “communicate better” is too vague. “For the next two sprints, the delivery lead posts dependency changes in the shared channel by 3 p.m.; the team reviews whether surprise blockers decrease at the next retrospective” is observable and testable. If an action depends on a manager or another team, name that dependency and a follow-up route rather than pretending the team has authority it does not have.
6. Close with appreciation and follow-through
Read back the selected actions, owners, dates, and review point. Ask each participant whether anything important is missing or unsafe to record. Close by naming one thing the team wants to carry forward. After the meeting, share a concise summary with participants and any stakeholders who need the actions—not a raw transcript of sensitive disclosures.
What do useful Mad Sad Glad examples look like?
| Column | Vague note | More useful observation | Possible follow-up |
|---|---|---|---|
| Mad | “Planning was bad.” | “The API dependency changed on Thursday, after testing had started, so two people repeated the same work.” | Add a dependency-change check to the weekly planning review. |
| Sad | “The launch was disappointing.” | “We postponed the accessibility review twice and shipped without feedback from keyboard users.” | Reserve review time before the next release and identify a reviewer at kickoff. |
| Glad | “The team was great.” | “When support shared three customer examples on Tuesday, we agreed on the priority within one hour.” | Keep the customer-example section in the weekly triage agenda. |
A useful note describes an event or condition and its effect. It does not diagnose a person’s character. A facilitator can help turn “Alex never responds” into “Two handoffs waited more than a day because the response expectation was unclear.” If a participant has a specific interpersonal concern, do not erase it by over-generalizing; discuss privately and safely through an appropriate process.
Example 1: A product sprint with repeated blockers
A six-person product team spends eight minutes writing notes. Three Mad notes mention waiting for access to a test environment. Two Sad notes say that a planned user test was canceled after the environment was unavailable. Glad notes recognize that engineering and design paired to reproduce a customer issue quickly.
The team separates the immediate access problem from the broader scheduling concern. It chooses one experiment: the QA owner checks environment readiness at sprint planning and posts a status by noon on the first day. The engineering manager owns a separate access request because the team cannot grant permissions itself. At the next retrospective, they compare the number of blocked test sessions with the previous sprint rather than claiming success based on memory alone.
Example 2: A distributed team with unequal airtime
A remote team notices that the same three people usually speak first. The facilitator switches to silent writing, offers an anonymous form, and lets participants add comments in their own time zone before the meeting. During discussion, the facilitator reads themes without identifying authors and asks people who have not spoken whether they want to add context—without putting anyone on the spot.
The Glad column identifies that written design decisions helped colleagues in another time zone. The team agrees to record decision, owner, and rationale in the shared project space within one working day. They also set a review date to see whether late-night clarification messages decrease.
Example 3: A project with a difficult trade-off
A service team is glad that it met a regulatory deadline, mad that urgent requests repeatedly displaced planned work, and sad that documentation was postponed. Rather than frame the discussion as “speed versus quality,” the facilitator asks what decision rule was missing. The team tests a small intake policy: urgent work must include impact, deadline, and approver; a weekly capacity review makes the trade-off visible. It tracks unplanned work and overdue documentation for one month, then revisits whether the policy helped or created extra overhead.
How can you adapt the format for remote, in-person, and async teams?
| Setting | Helpful adaptation | Watch out for |
|---|---|---|
| In person | Use sticky notes, quiet writing, and a visible action board. Provide large text and verbal descriptions of clusters. | Fast talkers can dominate; do not make handwriting or standing at a wall mandatory. |
| Remote, live | Use a shared board or document, an accessible video call, and a quiet writing period. Read themes aloud and allow chat contributions. | Tool fluency, bandwidth, time zones, and screen-reader compatibility can exclude people. Offer a low-tech alternative. |
| Asynchronous | Keep the board open for 24–72 hours, state the time zone and deadline, and publish a short synthesis afterward. Discuss only the most important themes in a brief follow-up. | A silent board with no response or action plan feels like a suggestion box. Explain who will review input and when. |
For asynchronous work, do not assume that a longer window automatically creates inclusion. Give people a clear prompt, examples of useful specificity, an optional private route, and a date when themes and decisions will be shared. If a live discussion follows, send the summary in advance so people can prepare. Record a text summary for anyone who cannot attend; a recording is not a substitute for consent or accessible notes.
How do you protect psychological safety and inclusion?
Psychological safety does not mean avoiding disagreement or guaranteeing that every idea is accepted. It means people can raise questions, admit uncertainty, and describe risks without predictable humiliation or retaliation. Leaders have particular influence: they should speak last when possible, respond to criticism without defensiveness, and show what will happen to feedback that cannot be acted on.
Offer more than one way to participate: speaking, writing, anonymous input when honestly supported, chat, or a follow-up conversation. Use plain language and define team-specific terms. Make the board compatible with keyboard navigation and screen readers, do not rely on color alone to distinguish columns, and read visual groupings aloud. Send prompts ahead for people who benefit from additional processing time. Consider language proficiency, disability access, caregiving schedules, and time-zone constraints when setting the format.
Do not force emotional labels. Some cultures, roles, or individuals may prefer to describe events and impacts rather than say “I am mad.” Accept “I noticed…” or a neutral “friction” column. Do not demand consensus on an experience; different people can have different accounts. Protect privacy by collecting only what is needed, restricting access, and keeping sensitive details out of broadly shared artifacts.
If someone reports harm, discrimination, harassment, or a safety risk, pause the group exercise and follow the organization’s established reporting and support process. A retrospective is not an investigation and the facilitator may not be equipped to resolve the matter. Be transparent about any limits to confidentiality before inviting input.
What are common Mad Sad Glad retrospective mistakes?
- Using the columns as a complaint session: Give people space to name frustration, then ask about causes, impact, and a possible next step. Do not rush past emotion, but do not stop at venting.
- Treating “Mad” as blame: Redirect from labels and assumed intent to observable behavior, conditions, and effects. Do not silence a concern merely because it is uncomfortable.
- Letting a manager answer every criticism: The leader can acknowledge impact, ask what context is missing, and follow up later. Defending each decision in the moment can close the conversation.
- Trying to fix everything: Too many actions dilute ownership. Choose a few experiments, record the rest as observations, and be explicit about what is deferred and why.
- Writing actions without owners or dates: A board full of intentions is not follow-through. Every commitment needs one accountable owner, a first step, and a review point.
- Repeating the same retrospective without checking previous actions: Start by reviewing prior commitments. If actions repeatedly stall, discuss the blockers and reduce scope rather than producing another list.
- Assuming anonymity: Small groups and writing styles can identify people. Describe the actual privacy limits and offer a safer channel where appropriate.
- Measuring success by how positive the board looks: A quiet or entirely Glad board may mean the period went well, but it may also mean people do not feel safe. Check participation and follow-up, not just sentiment.
How do you know the retrospective worked?
A successful session is not necessarily one where everyone agrees or leaves happy. Look for a shared understanding of important patterns, balanced participation, realistic decisions, and visible follow-through. At the next session, review whether actions happened and what changed. You can also track a small, relevant signal—such as repeated blockers, escaped defects, waiting time, or the percentage of actions completed—but avoid turning the measure into a target that encourages people to hide problems.
Ask participants occasionally whether the format is useful, accessible, and safe enough. If people consistently contribute only generic notes, change the prompts, facilitation, or privacy model. If the same action recurs, investigate the authority, workload, or dependency that prevents it from happening. The method is a tool, not a ritual: change it when it is not helping the team learn.
FAQ
Conclusion
A Mad Sad Glad retrospective is most useful when the team can name friction and progress without turning either into a verdict on a person. Start with a clearly scoped period, let people write before discussion, explore patterns with curiosity, and finish with a small number of measurable actions. Make participation accessible, be honest about privacy, and review commitments at the next session. The template is only the beginning; trust grows when the team sees that its observations lead to thoughtful follow-through.
SEO (Final Output)
- SEO Title: Mad Sad Glad Retrospective: Free Template & Examples
- Meta Description: Use a Mad Sad Glad retrospective template to surface team friction, concerns, and wins. Get facilitation steps, real examples, and practical follow-through tips.
- URL Slug: mad-sad-glad-retrospective
- Primary Keyword: Mad Sad Glad retrospective
- Secondary Keywords: Mad Sad Glad retrospective template, retrospective prompts, sprint retrospective, team reflection, psychological safety
- Featured Snippet Suggestion: A Mad Sad Glad retrospective asks a team what made them mad, sad, and glad during a defined period, then uses shared patterns to choose a few owned, measurable improvements.
- Internal Linking Suggestion: Link “single source of truth for projects” to the existing guide; link “plan team capacity” to the existing capacity guide.
- Featured Image Suggestion: A diverse remote and in-person team reviewing three clearly labeled reflection columns on a shared board.
- Alt Text Suggestions: “Team reviewing Mad Sad Glad retrospective notes”; “Three-column retrospective board with team actions.”
- Chart Title Suggestion: “From reflection to experiment: Mad Sad Glad retrospective flow” (process diagram, not numerical data).
- FAQ Questions: How long should a session take? Can one person use the format? Should notes be anonymous? What if nobody contributes to Mad or Sad? What if there are too many problems? Is it only for Agile teams? How does it differ from Start Stop Continue? What happens to notes afterward?
- Schema Suggestion: Article; FAQPage only if the FAQ content remains visible and eligible under current search-engine guidelines.
Admin Actions (Manual Completion)
Images
- Featured image: team reviewing three reflection columns; alt text: “Team reviewing Mad Sad Glad retrospective notes.”
- In-article visual: a simple three-stage process diagram from private reflection to patterns to owned experiment; alt text: “Mad Sad Glad retrospective process from reflection to action.”
CTA
Use the approved English Doitify CTA after the early instructional section and at the end of the article.
SEO
Preserve the existing URL slug. Apply the SEO title, meta description, and focus keyword above.
Links
Retain relevant links to the project single-source-of-truth and team-capacity guides where available.
Schema
Use Article schema. FAQ schema should reflect visible FAQ content only.
Table of contents
Add anchors for template, facilitation, examples, delivery formats, psychological safety, mistakes, measuring success, and FAQ if the theme supports a TOC.
If this post on Mad Sad Glad retrospective was helpful, you might also enjoy Project Timeline: How to Create One (Step-by-Step Guide) and Free Workload Planning Template.
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.