Skip to main content

Running a successful sprint retrospective can seem intimidating at first, but the process doesn't have to be difficult or time-consuming.

With a few simple steps, you can ensure that your retros are productive and you can put the team in a position to learn from past successes and failures. 

What Is A Sprint Retrospective?

The sprint retrospective is a meeting that occurs at the end of each sprint. The Scrum team looks back at the sprint and discusses what went well and what could be improved in the next sprint. The retro is one of the five ceremonies within the Scrum framework.

The retrospective should be a safe space for people to share their honest feedback. It all boils down to continuous improvement—it's all about driving positive change in the project and the team.

They shouldn't be confused with project retrospectives, which are slightly different.

What Is The Purpose of The Sprint Retrospective?

The purpose of the sprint retrospective is to come to a consensus on an improvement plan and put together action items to implement in upcoming sprints.

During the sprint retrospective, the team might identify areas that they can improve upon, such as making the daily Scrum (aka stand up) more useful, improving communication, or finding a more efficient way to capture each other's feedback.

You, as the Scrum master or project manager, will capture these areas of improvement and write up a plan for how they can be achieved. These insights from the previous sprint must be taken into account as you're doing sprint planning for the next sprint.

What is a Sprint Retrospective Meeting?

The sprint retrospective meeting is the sprint retrospective. You should prepare in advance, as should the entire team (I cover this in more detail below), but the meeting is where the retrospective itself happens.

When Is The Meeting Held?

The meeting is held at the end of a sprint, after the sprint review. It might be tempting to combine the retrospective with the sprint review meeting, but try to avoid this.

The sprint retrospective is typically timeboxed according to the length of your sprint. It should be no more than 3 hours for a 1 month sprint, and less for shorter sprints.

Who Attends The Meeting?

Those involved in the sprint retrospective meeting include: 

  • The sprint team: typically developers, designers, and engineers
  • Sprint facilitator: typically a Scrum master or product owner
  • Observers: who bring an external perspective
  • Participants or stakeholders: who have knowledge relevant to the discussion

How To Run a Successful Sprint Retrospective

The best way to make sure you're maximizing the value of your sprint retrospective is to prepare beforehand. 

  1. Set aside time before the retrospective begins to gather feedback and allow participants to brainstorm discussion topics. Send an anonymous survey out before or make time at the beginning of the retrospective. Keep in mind that teams usually prefer anonymity.
  2. Give each participant an opportunity to review data, such as a burndown chart, prior to the meeting. This can be used as a conversation starter during the sprint retrospective.
  3. Start with the right attitude going into the meeting. It's important to approach it with an open mind and bring teamwork in your discussion.
  4. During the discussion, remember to remain neutral. If you can't, then it’s best to ask someone outside the team to play the role, so that the person in question can participate.
  5. Guide the team towards finding the root of the problem, rather than focusing on frustration around the problem. To do this, ask generic questions to find out what caused the issue and discuss solutions. Avoid destructive criticism and guide the discussion towards constructive criticism.
  6. Be comfortable with silence. Most teams are comprised of both introverts and extroverts. Introverted team members may need time to collect their thoughts, and silence gives them an opportunity to think. Since silence can be uncomfortable, people will generally chime in to fill it.
  7. After the discussion, work with the team to identify common patterns and themes in the feedback. Which pain points stick out the most? What did you spend the most time discussing?
  8. Set action items based on the discussion and on the common themes that you identified. Prioritize these action items or deliverables and clarify who is in charge of actioning them. You can use Scrum software or other agile tools to keep track of them and follow-up as needed.
Sign up for the DPM newsletter to get expert insights, tips, and other helpful content that will help you get projects across the finish line on time and under budget.

Sign up for the DPM newsletter to get expert insights, tips, and other helpful content that will help you get projects across the finish line on time and under budget.

  • Hidden
  • By submitting this form, you agree to receive our newsletter and occasional emails related to The Digital Project Manager. You can unsubscribe at any time. For more details, please review our Privacy Policy. We're protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
  • This field is for validation purposes and should be left unchanged.

Why Should You Run A Sprint Retrospective?

Here are a few of the many benefits of sprint retrospectives:

  • It creates a safe, blameless space for team members to share their valuable feedback
  • It allows the team to document wins and areas of opportunity
  • It provides an actionable list of next steps and identifies who’s owning which item
  • It identifies small, incremental changes that can lead to larger waves of improvement
  • It allows teams to iterate on their process to amplify results
  • It allows opinions to be heard
  • It helps the software development team mature
  • It makes each sprint better than the last

3 Different Retrospective Methods

There are several interactive strategies for gathering feedback at a retrospective meeting. Here are some ideas to get you started:

Sailboat Method

sailboat method illustration with lists of feedback beneath wind anchors and iceberg
Here's how you and your team might use the sailboat method to capture feedback.

The sailboat method is aimed at visual learners. A member of the team is asked to draw a sailboat, wind, an anchor, an iceberg, and (optionally) an island.

The team adds their feedback to the relevant areas on the picture:

  • The wind represents what items, people, or workflows moved the team forward.
  • The anchor signifies what weighed the team down.
  • The iceberg represents unexpected items that derailed the team during the sprint.
  • The island represents the sprint goals.

Affinity Mapping

affinity map with feedback grouped under the categories of requirement issues scrum ceremony issues and team/culture issues
In affinity maps, the categories will define themselves as you group similar feedback together.

Affinity mapping is an efficient method for obtaining feedback from a larger group in a short amount of time. First, ask the team to write down their feedback on sticky notes (real or virtual). Once all feedback is received, you can start to recognize patterns and group similar items.

Label each group and ask the team to discuss high-level label topics. This method is great for organizing a significant amount of feedback into specific categories for general discussion.

The Four Ls

the 4 L method with feedback organized under liked learned longed for and lacked
The Four Ls method is popular as it's relatively simple.

The Four Ls method is a simple way to gather feedback that consists of the team providing insight into what they liked, lacked, learned, and longed for. 

  • Liked items: anything appreciated in the sprint or that made the sprint successful.
  • Lacked items: things that potentially could have brought the team closer to success.
  • Learned items: any lessons learned in the sprint that would be beneficial to remember for future sprints or any process changes that could provide higher success patterns.
  • Longed for items: things the team desires for success or morale.

What Are Some Issues You Might Run Into? (And How Do You Combat Them?)

As with any ritual, there may be varying levels of emotional baggage that you or your team bring to the table, based on previous experiences. Here are some things you might run into during a retrospective and how to combat said speedbumps:


If the same questions are asked sprint after sprint, team members can become less engaged in the answers and stop offering constructive suggestions to improve the process.

Combat apathetic participation by mixing things up! Test different exercises and questions. There is no “one size fits all” when it comes to retrospectives—you should iterate on the way you run them. Check out for more inspiration.


At the end of the day, we are people—and people have emotions. Retrospectives should invite constructive feedback on what could go better in future sprints, but they should never support hostility, negativity, and finger-pointing.

It’s vital to be nonjudgmental and unbiased facilitators during the retrospective meeting. People should feel safe sharing their feedback. Be sure to set expectations when you kick off the Scrum retrospective, mediate along the way when necessary, and promote a positive conversation.

A Lack Of Conversation

You might have an agile retrospective where it feels like questions are met with blank stares. Instead of pulling teeth to get the conversation going, come up with a more engaging opening to the meeting.

Encourage your team to write their suggestions and thoughts down throughout the course of a sprint. This will give them something to look at during the retrospective instead of feeling like they need to pull anything out of thin air. You can also consider keeping a log of these yourself.

Pushback From Leadership

Sometimes, action items identified in the retrospective impact members outside of the Scrum team. Whoever owns that item should work with leadership on the suggestion and agree on a way to make the requested change. However, leadership might be resistant to the proposed course of action.

If that is the case, keep at it. Find your champions within the organization who will go to bat for the production team and the improvements that stem beyond them. A truly agile organization that values positive change should eventually be willing to implementing improvements that benefit them. 

Feedback & Learnings From Real Agile Teams

As I set out to write this article, I reached out to several team members in the organization to chat about their experiences with sprint retrospectives. I was curious to find out what different roles—UX designer, developer, and project manager (DPM)—thought about this Scrum ceremony.

If you’re just getting started with retrospectives or looking to mix things up, talking directly with team members can be a good place to start. I asked them three simple questions:

1. If Run Well, What Can A Sprint Retrospective Provide You?

  • Takeaways on how to improve my personal process and/or role, as well as an opportunity to voice potential team-wide process improvements, have conversations around how to be better as a team, and how to better engage with our clients in the future (Design)
  • Help the team identify areas for improvement and provide a platform to talk about values or results the whole team can work on going forward (Development)
  • Insight and collaborative feedback into what is going well within the team, what isn’t and what can be improved. The best-case scenario is when the team is guided to create and experiment with solutions to challenges on their own (DPM)

2. If Run Poorly, What Can Happen?

  • It can turn into a complaining or bashing session. Another negative is if things are brought up that never end up changing or getting implemented (Design)
  • It could result in a missed opportunity for the team to grow as a whole (Development)
  • The status quo is kept. While this may be tempting to let pass for the short term, it can have a disastrous long-term effect of changing the culture within the team (DPM)

3. Do You Have A Favorite Question Or Activity That’s Been Asked In A Sprint Retrospective?

  • This is a bit elementary, but an effective strategy is to ask the question and then go around a circle where everyone must answer. It gets everyone talking. I’ve been in retrospectives where 2-3 people dominate the conversation, and others don’t say much. Everyone always has an opinion on how the experience went, and it seems people sometimes need a little nudging to speak up, or an opportunity to speak up. Going around in a circle was effective for that reason. Everyone had an answer. (Design)
  • I heard about a really cool practice from the Scrum team at Spotify where the agile coach would help the team decide on one thing they could do that everyone thought would make the team and or product better. In one example, they all agreed that every code check-in had to include at least some testing. (Development)
  • Ask the simple question, “Does everyone agree with what was just said?” (DPM)

6 Quick Tips To Elevate Your Next Sprint Retrospective

1. Keep It Simple

A simple way to make your next sprint retrospective effective is to ask the team what they’d like to start, stop, and continue doing. Regardless of what the team decides, make sure everyone is participating. Document the suggestions you’re hearing, and vote to determine what happens.

2. Incorporate Novelty

Incorporate games into your sprint retrospectives. One of my favorites is the LEGO Retrospective. Team members are encouraged to use LEGO blocks to build a structure that represents the last sprint, and one that represents what needs to happen to improve the next one. This abstracts things a little bit and generates some surprisingly productive (and creative) conversations.

3. Stay Focused

Using the Lean CoffeeTM approach, retrospective agendas can be built using Kanban boards that are democratically generated. This might be good for a group who can’t seem to stay on topic or who tends to spend too much time on a particular discussion point. Be sure to use different colored sticky notes and markers and identify a volunteer to document outcomes.

4. Make It Action-Oriented

Make sure you’re assigning anything actionable to someone on the team. They don’t all need to fall on the project manager. Even if your discussion is constructive and helpful, the ripples will not be felt unless the change is implemented across the team. Keep a list visible for everyone to see, and make sure that expectations and deadlines are set.

5. Bring In Outside Perspective

An outside perspective can be a huge turning point! Consider bringing in an agile coach to help with retrospective facilitation. This may come at a premium (and isn't necessary unless there are significant struggles), so you can try inviting another teammate to the conversation. Those unrelated to the project can help shed light on the situation and act as a neutral third-party. 

6. Keep It Fresh

Use a new retrospective format or icebreaker from time to time to foster participation and give the team something to look forward to. The team might also lose traction or the desire to participate if no movement is made on action items from previous retrospectives. Keeping a list of these items and tracking them through completion (potentially using agile project management software) will allow the team to recognize the value in retrospectives.

Find more sprint retrospective ideas, tips, and tricks here.

What's Next?

Have your own tips and tricks for running effective retros? Want ideas from other project managers running retros right now? Join the conversation in Slack with 100's of other digital project managers with DPM Membership!