The Ultimate Guide to Sprint Retrospectives

What is a sprint retrospective?

A sprint retrospective is a review of a past period of work. It’s used to evaluate both team and individual performance. Insights gained from a sprint retrospective informs the next sprint so that it can be even more successful than the last.

To best understand what a sprint retrospective is, we can look at what each word means separately.

A sprint in project management is a short period of time (days or weeks). Every sprint has a set of assigned tasks and a clear deadline. Sprints are used in Scrum project management (an Agile framework) to break larger phases into smaller, more manageable chunks.
A retrospective is a formal analysis held to review past work. Participants in this meeting take an honest look at what went well and what didn’t. Retrospectives show people what they can do better in the future.

A sprint retrospective aims to optimize systems, reduce potential roadblocks, and stay on track to meet big picture goals.

What is the difference between sprint review and sprint retrospective?

The biggest difference between a sprint review and a sprint retrospective is the goal each attempts to achieve.

A sprint review is used to discuss what happened during the project. Sprint reviews are typically limited to managers and team leads. The information gathered in a sprint review will be shared with other relevant stakeholders and collaborators afterward.

A sprint retrospective is used to discuss how a sprint went with an emphasis on process and workflow. The entire Scrum team attends these meetings to provide their boots-on-the-ground feedback. Anything learned during a sprint retrospective is put into action during the next sprint.

What happens in a sprint retrospective meeting?

A sprint retrospective meeting is a discussion that everyone participates in. But if you’re wondering what happens explicitly, here’s an agenda breakdown every organizer needs to know:

Set the toneSprint retrospectives often turn into open forums. To keep it from becoming a free for all employee review, make sure the team is laser-focused by setting the tone upfront. Here’s how:
Make introductionsIntroductions help team members, stakeholders, and freelancers quickly understand who is in the room and why. Quickly listing everyone’s name and role on the project is enough.
Highlight individual wins Choose one specific thing to highlight about each person during this past sprint. If the list is long, share it in your project management platform where everyone can see it.
Have a good attitudeShowing a strong, confident, and positive attitude about the meeting from the very beginning encourages others to do the same no matter what kind of day they had. Encourage the host to greet everyone when they come into the physical or virtual room.

1. Explain how it works

Go over the purpose of the meeting, what will be discussed, and when you plan to wrap things up. If you have a speaking order planned, share that up front.

2. Structure feedback

The most important thing to remember about sprint retrospectives is that they are meant to analyze your team’s process, not its employees. Alienating individuals is counterproductive here. Instead, frame any issues as a group concern and address them as such — even if the person responsible has to come up with a fix.

Go a step further and explain how you want feedback to be given to keep the conversation on track. Here’s an effective feedback formula for sprint retrospectives:

The biggest win
The biggest challenge
Relevant question or request

Feedback can be given in a round-robin format for smaller teams. Or, if your team is larger than 10 people, ask for volunteer speakers ahead of time, then leave room at the end for additional comments.

Need help getting people to participate? Narrow the conversation down to a simple question: what’s your no-nuance take on how the sprint went in one sentence?

3. Keep an eye on the time

In a 45-minute meeting, teams should allocate:

Five minutes for initial introductions and agenda review
30 minutes of evenly divided speaking time
10 minutes to create a list of action steps in order by priority with an implementation plan for each

Sprint retrospectives are meant to be efficient, which means not every concern can be fully addressed in the given timeframe. The solution?

Brainstorm a list of all concerns, then as a team, put them in order from most impactful to least impactful.

Quickly identify how many you plan to get through during this meeting. Whatever isn’t discussed by the time the session is over will be set aside for after the next sprint. If those issues come up again, put them at the top of the list this time. Rinse and repeat.

Have a designated timekeeper who feels comfortable interrupting wandering thoughts and bringing the group back together after tangents.

Pro tip: Put your long-winded team member up for the job. They’ll be hyper-aware of how much they need to summarize their own thoughts.

4. Go over reports

Sprint retrospectives tend to be anecdotal. However, opinions alone won’t always improve your next sprint. Each statement or choice needs to be supported by real data. You can:

Source reports from Wrike
Review Gantt charts for bottlenecks
Review conversations right within delayed or failed tasks on Wrike to see how each roadblock was navigated

Share the sprint reports with everyone in the meeting ahead of time so they can come prepared with questions. When notifying your team, give them one or two main ideas they can reflect on to keep them focused.

Some great report-related questions to ask include:

Did anything unexpected happen during this sprint? How were roadblocks handled? Would you take the same approach again?
What deadlines were met? How can we replicate that success moving forward?
Were resources distributed to best support the team, or will adjustments need to be made moving forward?

Bring or link copies of these reports within your meeting invitation for people to refer to on the day.

5. Turn ideas into action

Before the meeting is over, come up with at least one concrete takeaway from the last sprint with details such as:

What the issue was
How it affected the project
What tasks will be assigned to prevent it from happening again?
Who is in charge of completing and approving that task or tasks?
When each task is due
How your team will know whether or not the action step was successful after the next sprint

In the next sprint retrospective meeting, briefly address the actions taken to resolve past issues. Honestly evaluate whether the issues were resolved or if they need revisiting.

Here are some tips for planning effective next steps after a sprint retrospective:

Give team members time to ask questions about the action steps before the meeting ends.
Make sure each action follows the S.M.A.R.T goal format.
Add all related tasks to your project management platform immediately, so nothing gets lost when the next sprint begins.

What are the benefits of sprint retrospective meetings?

There are countless benefits of sprint retrospective meetings, but here are our favorites:

Streamlined team communication and feedback
Discovery of new opportunities for success during the next phase
Acknowledgment of wins and boosting team morale
Gathering all project members together for a regular check-in
Going back to the big picture objectives and aligning them with the day-to-day
Learning from past mistakes, transforming them from errors into improvements.
Making the process more productive for everyone involved
Building better relationships as a team and with stakeholders or clients
Increasing the opportunity for creativity
Encouraging collaboration between team members who don’t normally interact

How long is a sprint retrospective meeting?

How long a sprint retrospective meeting lasts depends on how long the sprint itself was. But your team size and complexity will factor in too. The typical time-box for a sprint retrospective meeting is 45 minutes to two hours.

Sprint retrospective meetings typically last up to three hours after a month-long sprint. If you’re wondering how long yours should be, the math works out to 45 minutes for every one week in a sprint (based on the example). If your sprint was shorter than seven days, schedule the meeting for at least 45 minutes just in case.

When should a sprint retrospective meeting be held?

Here’s the order in which all major sprint meetings happen:

Sprint planning (here’s a free template you can use)
Sprint with daily Scrum meetings
Sprint review
Sprint retrospective

The next sprint begins right after, and the cycle repeats itself.

So as you can see, a sprint retrospective should be held directly after a sprint review or within a day or two of completing all other sprint tasks. Add your sprint retrospective meetings as a task at the end of each sprint within Wrike to keep everyone on the same page.

What questions should be asked in a sprint retrospective meeting?

Address all three of these question categories at your next sprint retrospective meeting:

Process

What went well, and why?
How can we replicate that success in the next sprint?
What could have gone better, and why?
Is this issue preventable with a process adjustment?
How can we streamline and simplify our process to make it easier?
Are there task redundancies we need to be aware of?
Does everyone fully understand our process?

Time

Were there any task bottlenecks?
Why did bottlenecks occur?
Can we adjust our process to avoid bottlenecks for the next sprint?
Were our original time estimates accurate?
What have we discovered about our timeline now that the plan is in action?
Do we need to make up for the last time in the next sprint? How should we do that?

Resources

Are all of our budgets on track?
Was there a noticeable shortage or excess of necessary project materials?
Will we need more or fewer resources for the next sprint?
Is there a way we can decrease key resource usage during the next round?
Will we need to request additional resources for the next sprint?
Was work distributed evenly?

Hint: Use Wrike to review workloads across your entire team when assigning tasks.

What is the mad sad glad retrospective?

The mad sad glad retrospective is a format for gathering data during the sprint retrospective ceremony, which is the final ceremony of the Scrum process. During the sprint retrospective, the Scrum team reviews what went down during the previous sprint to determine what can be improved in subsequent sprints.

It’s a pretty straightforward concept: The mad sad glad retro calls for each team member to consider what events during the previous sprint made them feel mad, what made them feel sad, and what elements or events made them happy or glad.

What are the benefits of a mad sad glad retrospective?

Scrum teams are typically tight-knit units that work together closely and meet consistently to assess their progress and improve their processes. However, that doesn’t mean that they’re immune to mistakes, oversights, and roadblocks that can impede the project — or from feelings of frustration, disappointment, and even anger that arise from these situations.

Rather than bottling these feelings up and letting them build to the point of resentment for fellow teammates, the sad mad glad retrospective allows Scrum teams to vent their frustrations and disappointments constructively. The mad sad glad acts as a pressure release valve to help the team reach a resolution and reset before the next sprint.

In other words, the sad mad glad framework allows Scrum team members to express themselves in a structured and safe environment. Think of it almost as a group therapy session for your team members. That means that as the Scrum master or team leader running the session, you’re playing the role of the therapist.

How to run a mad sad glad retrospective

Running a sad mad glad is pretty straightforward. If you’re meeting in person, you can begin by labeling a whiteboard with three columns: Mad, Sad, and Glad. Then, gather your team into the conference room. If you’re running the retrospective virtually, you can still utilize a whiteboard if you choose or simply talk through each section.

Next, allow your team members some time to reflect on the previous sprint. Direct them to write down the things that made them feel frustrated, disappointed, and angry, as well as things that made them feel happy, on sticky notes. Events that triggered frustration and anger would fall under the Mad category, while disappointments will go in the Sad column. Considering things for the Glad category is very important, too, as it balances the exercise and helps team members not focus solely on the negative.

When everyone has written down their thoughts, have the team members place their sticky notes under the corresponding column on the whiteboard. In a virtual setting, consider using an online document or Wrike task that everyone can access.

Next, comb through the notes to find common themes. These will help guide the discussion. The discussion portion of the retro is where the rubber meets the road. Without pointing fingers or laying blame, discuss how the events that led to anger or sadness can be avoided in future sprints. You should also talk about the events that caused feelings of happiness and ways to incorporate those in subsequent sprints.

What are the outcomes of a mad sad glad retrospective?

The ultimate goal of any sprint retrospective is to improve future sprints. The outcome of a mad sad glad retro, then, should be actionable items that can be applied in the very next sprint the Scrum team undertakes.

Successfully performing a mad sad glad retrospective requires an environment where team members feel safe to discuss their feelings openly and honestly. Although it may be difficult at points, talking through these issues can help build tighter teams and a stronger sense of camaraderie.

The Complete Guide to Scrum Ceremonies Daily Scrum Meetings

The Ultimate Guide to Sprint Retrospectives