If we're talking about agile feats, a sprint retrospective is what you do after crossing the finish line at a track meet. If we're talking about Agile feats, it's actually kind of the same thing—just with (hopefully) a lot less sweating and probably fewer cramps.
I'll assume you're here for the less sweaty version, where you look back on what your team accomplished during their last work sprint.
If so, here's what goes into an effective sprint retrospective meeting, how to run one yourself with a quirky metaphor-based framework, and even a handy agenda template you can use to hit the ground running (once you're done sprinting).
Table of contents:
What is a sprint retrospective?
A sprint retrospective is a recurring touchpoint after each sprint where all relevant team members catch up on what they've done and what's left to do. These regular meetings mark the end of a sprint—the unit of time a team establishes to perform work toward a specified goal—and give space (around three hours per month) to talk about things like:
Overall project progress
Specific challenges faced
Successes
Learnings
Useful features or shortcomings of the tools used in the sprint
Effective (or ineffective) strategies
Insights into potential roadblocks
The goal of a sprint retrospective is to keep progress transparent. These regular check-ins allow people who may not work together directly (but who are working on a shared deliverable or project) to get on the same page, share knowledge to improve teamwide performance, and get ahead of possible issues that could derail the project.
Who should attend a sprint retrospective?
The short answer: the team actively involved in working on the same product in said sprint. In a traditional Scrum environment, a Scrum retrospective includes people like the Scrum Master, product owner, and developers. For more Scrum-adjacent teams, that means anyone who worked together during the sprint or managed the project.
Another thing that makes sprint retrospectives effective is that they're generally limited to a need-to-know kind of basis—that is, only those who played an active role in the work that period and who could realistically benefit from talking about that work.
There are no rigid rules about these meetings, though. Sometimes it can help to involve Scrum Masters or managers who are new to the greater team and could benefit from observation, members of other teams who could have outside-the-box perspectives, or stakeholders with a vested interest in the project's progress.
But just keep in mind that honest feedback is vital to a sprint retrospective, so it's best to limit the presence of anyone who might make attendees more inclined to nod their heads mechanically and say, "Everything's great!" with the energy of a hostage on FaceTime during a bank robbery.
How to conduct a sprint retrospective meeting
If you're new to running a sprint retrospective meeting, remember that the key is setting a reliable cadence and fostering an atmosphere of honesty. Here's how to do that.
1. Schedule them predictably
What makes a sprint retrospective effective (say that five times fast) is that it's regular enough that teams can use the takeaways to pivot their strategy and gauge how realistic project milestones are.
And as any meeting-averse-possibly-quasi-anti-social developer knows, it's also helpful that these are occasional enough that they don't get in the way of actually being able to do the work.
Every team's retrospective cadence will vary by sprint length—week-long sprints mean you'll have weekly retrospectives, and month-long sprints mean monthly retrospectives. Whatever your cadence, it's important to be consistent and hold them every time a sprint ends—try setting up a recurring Google Calendar event or scheduling Agile retrospective timeboxes into sprint workflows within your Agile PM software.
2. Set expectations
Once you've got your sprints on the books, I'd argue the most important thing you can do to maximize your retrospectives is to set expectations early. Here's what that might mean:
Preparation: Make sure your team knows ahead of time what kinds of insights, progress reporting, questions, and concerns they should plan to bring with them.
Timebox: The Scrum standard is three hours for monthly retrospectives, which you can scale back to 45 minutes for weekly or 90 minutes for bi-weekly retrospectives. Even if you're not a Scrum-conformist, that's still a useful standard to start with.
Purpose: Retrospectives serve a specific purpose: learn from the previous sprint. Everyone in attendance should come in with the same goal of applying their feedback, learnings, and concerns to the next sprint.
Agenda: Since retrospectives are fairly structured and iterative, you can rely on a predictable agenda that leaves plenty of space for feedback. If you're not sure what to put into yours, try starting with this one.
Format: Structured formats help keep retrospectives focused and predictable. If you're more of a wing-it kind of Scrum Master, you can set your own retrospective structure. Otherwise, you can try a retrospective framework like one of these.
Honest participation: Retrospectives only work if everyone participates and is transparent about their work. Remind everyone this is a judgment-free zone that's designed to help everyone reach the same goal.
3. Maintain open, inclusive feedback channels
While the retrospective itself is where most of the talking will be done, keeping feedback channels open at all times helps ensure that everyone can be heard and that those who need additional support have a way to ask for it without fear of judgment.
Not all members of your team may be comfortable talking in group settings—especially in the context of a retrospective, where they could be opening themselves up to criticism, saying things that could come off as critical to others, admitting to underperformance, or putting themselves in environments where they've historically been excluded, ignored, or unequally treated.
Plus, not all team members may have the same aptitudes for public speaking, ability to communicate in a fast-paced live setting, or language fluency.
Remember, the more people who are able to contribute, the better your team will be at improving performance as a whole. So if you want to make sure all your retrospectives aren't dominated by someone who won a public speaking competition in the sixth grade and feels uncomfortable with more than two consecutive seconds of silence, try these tactics:
Maintain an anonymous feedback submission form (if you don't have a preferred form software, try building one with one of these templates).
Regularly reinforce that the retrospective is a safe space.
Invite feedback or criticism for yourself.
Don't prioritize feedback or contributions by seniority, status, or role.
Send out surveys or leading questions the day before the retrospective.
Start your retrospectives with a short team activity or icebreaker.
Consider regular team-building activities to build trust.
Give everyone time to write or type a response before taking responses.
Break into small groups and assign a rotating spokesperson to each.
Try round-robin style feedback rounds that give everyone an opportunity to contribute.
Follow up afterward with anyone who doesn't regularly contribute and see if there's a feedback method they prefer.
4. Guide feedback toward goals
As someone's grandpa probably once said, talk don't do much. While chatting about your job can be helpful (mainly for mental health purposes), if you want your retrospective to actually change anything, the Scrum Master has to be able to funnel that talk into actionable insights that build toward specific goals.
An easy way to do that is by choosing a retrospective framework like sailboat, mountainclimber, starfish, pickleburger, rumspringa, bloomin' onion, or fiddlestick. (Bonus points if you can guess which of those are real.) These are designed to help ensure that conversations steer toward a collective goal of improving work in future sprints.
Whether you choose a framework or decide to wing it, it's worth reiterating that, as the Scrum Master, you (presuming you're the Scrum Master) have a responsibility to keep the conversations running in a constructive direction. Try asking open-ended questions to get detailed responses, establishing and reiterating SMART project goals to use as North Stars every retrospective, or asking follow-up questions about how the greater team can apply learnings or avoid specific pitfalls.
5. Turn feedback into action
So your retrospective is now in retrospect—time to shift it into a… forespective?
As much as I'm a fan of shouting into The Void until it shouts back at you, that's not a tactic I (or, probably, Nietzsche, who might have been a pretty good Scum Master) recommend for a retrospective. What you don't want is for these conversations to just be for catharsis only, and then move on to the next sprint like nothing happened.
What you do want is for feedback shared in the retrospective to carry over into the next sprint and accumulate over time, refining processes from sprint to sprint until you cut out all inefficiencies, avoid all obstacles, and arrive at your polished product in record time.
Here are a few ways you might help that happen:
Send out retrospective retrospectives that summarize key findings and concerns.
Synthesize feedback and punch up a list of changes to carry over into the next sprint.
Ask individual contributors to recommend strategies for improvement based on their learnings.
Use exit interview-style questions to see how team members plan to apply learnings from the retrospective.
Sprint retrospective agenda template
Don't know how to structure a sprint retrospective? I made a pre-packaged agenda you can use right here. In this template, you'll find point-by-point discussion topics noting the person responsible for leading them and estimated time limits. Click the button above to make a copy in Google Docs, or use this editable PDF version.
Keep in mind that this is designed for a 90-minute retrospective, so if you want to scale it back to weekly, cut all the times in half; if you want to scale it up to monthly, double the times. Or, throw all these times out the window and set your own.
Example sprint retrospective frameworks
If you're someone who takes comfort in time-tested approaches to doing things, you'll appreciate that sprint retrospectives have a lot of frameworks. Kind of—it's more like a few retrospective frameworks that have just been called a lot of things.
I'll break them down below into a handful of general concepts. Try applying these in your retrospective to elicit more comprehensive, transparent, actionable feedback.
Four L's
Key feature: Encourages positive and negative feedback equally
The four L's are designed to help gather and distribute feedback while shifting the way teams think about their work. Here's what they mean:
Liked: Maybe it's hard to imagine people actively "liking" sprints, but you can think of this as "what went well" to share useful strategies.
Learned: This pretty self-explanatory L is about sharing useful wisdom ranging from technical knowledge to process improvements to insights into team dynamics.
Lacked: Talking about what was missing during the sprint that hindered the team's progress helps identify what new tools, workflows, or strategies will be most impactful.
Longed for: This admittedly dramatic L is about what people need for future sprints. It encourages forward-thinking and aspirational feedback about potential improvements, tools, or changes.
Sad, mad, glad
Key feature: Focuses on often hard-to-elicit but useful emotions to help get to core feedback
What I really like about this framework is that the instructions are in the title. Tbh, you probably get the gist already, but here it is spelled out just in case:
Sad: This is intended to see what left team members feeling disheartened, disappointed, or blocked up—but none of those rhyme with "mad" or "glad."
Mad: You can think of this as an escalation from "sad"—what happened in the last sprint that irritated, frustrated, or annoyed your team? Tread lightly here—you might just get honest answers (which is what you want).
Glad: Beyond just what made people happy, for this portion of the retrospective, look for what team members were proud of, pleasantly surprised by, or excited about. This is a good time for people to recognize their own accomplishments and shout out other people's good work.
I wouldn't get too hung up on the specific words—this one's really more about getting to the true emotions behind the work so you can address their root causes. Feelings can get overlooked in retrospectives, but they can often tell a clearer story than just recounting what happened over a sprint.
Start, Stop, Continue
Key feature: Promotes highly actionable feedback
If Sad, Mad, Glad is about giving you the raw materials to use in future plans, Start, Stop, Continue is sort of the inverse: direct actions and explicit recommendations that can go straight into future work, generally sans emotion.
Start: Based on what happened in the last sprint, what should the team start doing in the next sprint? This jumps straight from problems to future solutions.
Stop: And the opposite: what should people stop doing in the next sprint? This helps address ineffective or inefficient processes, strategies, software, etc.
Continue: When you're focused on making continual changes, things that just plain work can get lost in the shuffle. By highlighting the things that are going well, you can make sure no one tries to fix what isn't broken.
Since this framework is actionable by design and doesn't leave much room for talk about feelings, it could be worth using it along with Sad, Mad, Glad or even alternating between the two.
DAKI
Key feature: Creates space for sharing experiences, emotions, and relevant action items
If you're more of an acronym person, DAKI might be the framework for you. This one's a blend of the last two frameworks with more emphasis on the former, giving space for both reflecting on experiences and suggesting changes. Think of it like Sad, Mad, Glad, Had (Better Do This Next Sprint).
Dissatisfiers: Kind of a combination of sad and mad, this is the space to talk about what left team members feeling disappointed, frustrated, upset, or stifled.
Appreciations: Here's where your team can discuss what worked, what they enjoyed, what notable improvements were made, and all the general positive vibes.
Kudos: To keep up rapport, it's important to make time for people to compliment other team members' contributions, collaborations, achievements, and above-and-beyond efforts.
Improvements: After everyone talks about what worked and what didn't and is feeling warm and fuzzy from the kudos, they can synthesize the talking points into concrete suggestions to carry over into the next sprint.
Visualizations
Key feature: Structures retrospectives around easy-to-follow visual metaphors
There are a bunch of frameworks that revolve around quirky metaphors, and honestly, they all kind of do the same thing: prompt talks about the goal, the challenges, what went well, and what comes next.
This isn't an exhaustive list because, as you'll see, these are generic enough that they're easy to just kind of rebrand each list into other metaphors. I'll sum up a few common ones, and you can pick your favorite aesthetic (or just make up your own iteration).
Sailboat
Sail (positive things that propelled the team forward)
Anchor (obstacles that held the team back)
Wind (unexpected benefits and influences)
Rocks (risks, problems, and close calls)
Island (where the sprint was intended to head)
Mountain Climber
Rope (what helped)
Boulder (what hindered)
Weather (how everyone felt)
First aid (what's needed to improve)
Rose, Thorn, Bud
Rose (good things that happened)
Thorn (challenges and setbacks)
Bud (opportunities for improvement)
Starfish
Less of (things that aren't adding much value)
More of (things that work and should be maximized)
Keep doing (things that are working and should continue)
Start doing (things not being done that should be)
Stop doing (unproductive or detrimental things)
Streamline your sprint retrospectives with automation
If you've picked up on a theme about sprint retrospectives, it's probably got to do with the importance of regular communication (or that Scrum Masters have a penchant for metaphors).
While automation can't reflect on your feelings about your last sprint, it can help you make sure your retrospectives run according to schedule. Connected to thousands of apps, Zapier can integrate with the software your team relies on both during your sprint and after, so you can set up automated no-code workflows to do things like send form links ahead of retrospectives, collect feedback, follow up with surveys, and store meeting minutes.
Zapier is the most connected AI orchestration platform—integrating with thousands of apps from partners like Google, Salesforce, and Microsoft. Use interfaces, data tables, and logic to build secure, automated, AI-powered systems for your business-critical workflows across your organization's technology stack. Learn more.
Sprint retrospective FAQ
What is the purpose of a sprint retrospective?
The purpose of a sprint retrospective is to reflect on the work completed over the last sprint so teams can work more effectively during their next sprint. If that's not apparent after reading an entire blog post I wrote about that very subject, I might need to find a different job.
Is a sprint retrospective the same thing as a sprint review meeting?
No—a sprint retrospective is a time for the team involved in a sprint to reflect on how their work went during that sprint, while a sprint review is a meeting where stakeholders assess the work completed during the sprint.
Who attends sprint retrospectives?
Traditionally, sprint retrospectives are attended by the Scrum Master, product owner, and developers. For less traditional teams, think of it as anyone who performed work on the same project during a sprint.
Related reading:
