The Ultimate Guide to Agile Retrospectives [2023]

So, you’ve come to the end of your sprint. Your team planned and prioritized the most important tasks for the sprint and executed them as best as possible. It’s just about time to reset, begin planning again, and jump into the next sprint — BUT STOP — there’s another critical step the team needs to take before they can effectively move forward into another round of planning. A retrospective meeting needs to happen so the team can gain critical insights into how the last sprint went.

What went well? What didn’t go well? What do you need to improve upon for next time?

We built this guide based on years of agile training and software development experience. Our ultimate guide to retrospectives has everything you need to run effective retrospective meetings, including the benefits of retrospectives, how to run them well, and extra resources.

An intro to the agile approach

But first, a review of agile. If you’re already familiar, feel free to skip ahead to the next section on retrospectives.

One of our favorite ways to differentiate the agile methodology from traditional, waterfall project management is to compare the approaches to jazz vs. classical music.

In classical music, a conductor brings a piece of music to an orchestra. The conductor guides the group through the piece, dictating exactly what happens where and when based on their own previously decided ideas. It’s a lot like traditional project management. A project manager creates a plan, brings it to their team, and tells them how to carry it out. Each step plays out as it was designed to, under the careful observation of the project leader.

Now, consider jazz music. Jazz is collaborative, with each bandmate feeding off of each other in a flexible environment. The band doesn’t go in completely blind. Everyone is working off of a piece of music — but it’s not strictly adhered to, allowing for new directions to be discovered in the moment. The band, just like an agile team, works together to create music flexibly and iteratively, with each iteration a little different — and hopefully even better — than the last.

💡 Learn more: Agile 101: A Beginner's Guide to Agile Methodology

Traditional project management isn’t flexible. Instead, team members must work in a sequential order that’s dictated by the original plan and project manager. Think of an assembly line. The same steps are followed from project to project. The linear structure means that if one piece of a project stalls, the entire project stalls.

Agile, on the other hand, is non-linear. It focuses on collaboration between team members, flexibility, and delivering consistent value to stakeholders throughout the development process. Each new iteration yields actionable insights about what’s working and what isn’t. This multidimensional way of working eliminates the bottlenecks and dependencies that are common with traditional project management.

What is a retrospective?

Retrospectives are a staple of many agile processes. They can be a critical moment for teams to come together and provide feedback about how processes can improve. Retrospectives keep the agile process — well — agile and encourage continuous improvement. No matter how well the last sprint went, there is always something that can be improved upon for the next iteration.

Agile retrospectives help agile teams gather data and feedback from those involved in the Scrum process. In Scrum, a retrospective is held at the end of every sprint, which is generally every two weeks. The retrospective is a chance for all team members to share what went well, what didn’t, and what could be improved upon for next time. The insights are taken into account in the next planning session to ensure teams learn from their mistakes, successes, and each other.

How retrospectives fit within the Scrum process

Retrospectives are conducted in a variety of agile methodologies, but for the purposes of our Retrospectives Guide, we’re going to discuss retrospectives within the Scrum process. It’s one of four critical meetings used in Scrum, coming at the conclusion of each sprint. So, how are retrospective meetings utilized in Scrum?

Scrum artifacts

Artifacts are the pieces of work the team completes over the course of the sprint. The product backlog is a compilation of tasks that the team believes need to get done in order to complete a product or iteration of a product. The product backlog is large and not very refined.

Items from the product backlog get moved into the sprint backlog when it’s time for them to be completed. The sprint backlog represents everything the team hopes to accomplish over one sprint, which generally lasts for two weeks. The sprint backlog is more refined — it focuses on the current state of the product, stakeholder feedback, and customer needs.

Scrum roles

There are three Scrum roles, and each has different duties within the Scrum framework. The product owner prioritizes the work that needs to be completed over the course of each sprint. They refine and prioritize backlog items, moving the necessary product backlog items into the sprint backlog.

The next role is the Scrum Master, who guides the team during the two week sprint, ensuring the Scrum framework is adhered to. This person is an expert in all things Scrum and can act as a facilitator during daily stand-ups and other important meetings. The Scrum Master tends to play a key role in leading retrospectives.

Lastly comes the development team. They make up the bulk of the team and complete the work set out in the sprint backlog. The development team participates in planning, attends daily stand-up meetings, and delivers work to the client and stakeholders.

Stakeholders and customers, while not directly on the Scrum team, play important roles in the Scrum process. Stakeholder and customer needs must always be at the forefront of development decisions. Stakeholders should be brought in early and often to provide critical feedback as a product is being developed.

Scrum ceremonies

The Scrum ceremonies are the events that take place within the Scrum framework. First comes sprint planning to set the stage, then daily Scrums or standup meetings, followed by a sprint review and a sprint retrospective.

The sprint planning meeting is when everything gets set up for the next sprint. Sprint planning meetings are opportunities to prioritize backlog items and get the entire team aligned on their goals for the upcoming two weeks. Without planning, the team won’t have clear goals, and they won’t know what tasks to tackle next.

The daily stand-up, sometimes called a daily Scrum, occurs every day of the sprint. The entire team participates in this daily meeting that updates everyone involved in the sprint. During the meeting, team members update each other on what they accomplished over the past 24 hours and what they hope to accomplish over the next 24 hours. This time also serves as an opportunity to discuss any issues that occurred or potential roadblocks that could prevent work from moving forward smoothly.

The sprint review meeting happens at the end of the sprint and is an opportunity to discuss the success of the sprint based on what tasks are considered “Done.” The sprint review can also bring stakeholders into the Scrum process to ensure everyone still aligns on where the product is going and what should happen next. Stakeholders provide invaluable insights that ensure the team stays on track to meet customer needs.

The last ceremony in the Scrum framework is the shining star in our guide. The sprint retrospective meeting arrives at the end of every sprint. It’s a critical meeting that helps the team improve from one sprint to the next. It allows team members to share what went well, what didn’t go so well, and what could be improved upon for next time.

We’ll dissect the elements of a good sprint retrospective throughout the rest of this guide.

💡 Learn more about the differences between these four meetings in our article: Agile Ceremonies: Your Guide to the Four Stages.

The incredible benefits of retrospectives

Retrospectives put the iterative in agile. They provide a focused time for teams to learn from the past and each other so they can constantly improve the development process. Retrospective benefits are vast, and they trickle down into all areas of development. The insights from a retrospective can improve productivity, team dynamics, team trust, customer value, and the overall Scrum process.

Retrospective benefits include:

Documenting feedback in real-time after each sprint
Exposing issues from the previous sprint that are holding the product or team back
Aligning the team around the most important issues
Giving everyone involved an opportunity to express ideas, thoughts, and experiences
Informing leadership of potential roadblocks
Bringing the team together around common goals and action items
Establishing a safe space for sharing positive and constructive feedback
Encouraging a continuous improvement mindset
Helping product owners make decisions for the next sprint
Setting the team on a positive path for the next sprint

6 Effective retrospective techniques

Now that you know why retrospectives are so important to the agile process, it’s time to dig into how to run them effectively. Use our 7 retrospective techniques for a smooth meeting that keeps everyone engaged and always results in quality insights.

1. Choose a time that works for everyone and stick to it

It’s important that every member of the Scrum team participates in the retrospective. This means holding it when everyone is available, whether that’s in-person or virtually.

Get feedback from your team about the best time to set this meeting. It should take place right after the sprint ends but before the planning meeting for the next sprint. This can be a tight window, which is why it helps to schedule this meeting at the same time every two weeks.

Consistent meeting times help ensure the meeting actually happens and that an optimal number of team members can attend.

2. Find new and creative ways to acquire feedback

The Start, Stop, Continue format can take many forms, but the general process is the same. The team discusses what they want to start doing, what they want to stop doing, and what they want to continue doing in the next sprint. It’s a simple framework that addresses both what went well with the previous sprint and what could be improved for next time.

This is a tried and true method, but it’s also important to change up your format and ask different questions to keep the team engaged.

You are trying to acquire similar information each time (what to start, stop, and continue), but the way you gather that information can change and evolve. Add variety to your Scrum retrospective and mix things up every once in a while to keep everyone engaged.

Find new ways of asking similar questions, and bring in new ice-breakers that help the team feel comfortable discussing the past two weeks with honesty and clarity.

Other versions of “Start, Stop, Continue” include the Rose, Bud, Thorn exercise, where team members discuss something positive about the experience, a “budding” opportunity that can be expanded on for next time, and something negative about the experience that should be improved upon. Another alternative is the Anchors and Sails exercise. What about the last sprint weighed or anchored the team down, and what positives put wind in their sails, so to speak?

Boring retrospectives will make team members dread the meeting and will lower participation significantly. If participants aren’t engaged, they won’t contribute as openly, and they won't take ownership over the process.

Mixing things up is also a good way to uncover insights the team hasn’t considered before. New questions will spark new ideas, issues, and solutions that otherwise would not have been discovered.

3. Ensure all voices are heard

All voices need to be heard in the retrospective. It’s the responsibility of the meeting facilitators to make sure everyone has a chance to speak during the meeting and that loud or dominant personalities don't overtake the conversation. They have to be heard too, but not at the expense of more introverted team members.

If you notice some members of your team do not participate, start asking them direct questions. If this only makes them retreat further into their shell, take them aside at the end of the meeting for a one-on-one conversation. How can you make the meeting environment more comfortable for them? What will best enable them to collaborate effectively? Ensure this is framed in the right way so it doesn't sound like they're in trouble but rather like you value and appreciate their input.

4. Establish a comfortable environment

Ensure the retrospective feels safe and comfortable for everyone involved by instilling trust, collaboration, and open dialogue. Each team member should feel like their voice is important. It should be a place of positivity, not a chance for team members to dunk on one another. It’s up to the facilitator to ensure everyone is comfortable.

There should be room for everyone to speak. The whole team should feel like they can express their thoughts and opinions about what happened over the course of the sprint. If people feel uncomfortable or think their voice won't be appreciated or heard, they will hold back and not actually express their honest feedback.

This is detrimental to the process, as it can leave recurring issues to fester and worsen over the course of future sprints. It is in everyone’s best interest to be open and honest and to hear everyone out. The goal of a retrospective is to solve issues, prevent roadblocks, and improve the team’s processes. If team members are silent or dishonest about how they feel things are going, nothing will be solved.

Comfort plays a big role in how honest everyone will be. Ensure everyone is respectful and that speaking time is shared across the team. Take time building trust and allowing the team to get to know each other. A team that trusts one another can work together and build each other up — and you’ll be able to manage issues before they begin to hinder productivity, team wellness, or the Scrum process.

5. Document everything and create clear action items

If you don’t document it, it didn’t happen. Don’t rely on memory alone after the retrospective. Document the feedback team members provide, and ensure any important ideas or issues are brought to the next planning meeting.

Turn important insights into action items to make sure ideas are not lost. Ensure action items are specific and clear and that the whole team understands what “done” actually means for each task. Once an action item is created, make sure there is follow-up, ideally at the beginning of the next retrospective. Determine who is responsible for the action item and how important it is in the grand scheme of your product backlog.

6. Review your action items at the next retrospective

So, you’ve collected your and your team’s insights and made those insights into action items. The final step is addressing those action items during the next retrospective. Were they resolved, or did the same issues keep occurring?

It’s best practice to review your previous retrospective action items at the beginning of the next retro. Did the team make progress on the task? What else needs to happen? Do you need to follow up again at the next retrospective meeting?

What happens next?

The retrospective may be the last meeting of the sprint, but it doesn't end there. Take those insights into the next sprint.

After the retrospective, the product owner reevaluates the product backlog and chooses what will go into the sprint backlog for the next round of work. They should consider past mistakes, successes, stakeholder feedback, and retrospective insights as they make decisions.

The sprint planning meeting comes after the retrospective and will help the team regroup and align on what they need to accomplish next. With each sprint, you will gain more information about the product, your customers, how the team works together, and your overall process. These lessons are taken into account to make improvements from sprint to sprint and product to product.

For better sprints, read our sprint planning guide, which includes everything you need to run efficient and effective planning meetings. ➡️ The Ultimate Agile Sprint Planning Guide.

Turn an action item into a Jira issue in just a few clicks, then schedule the work to ensure your ideas aren’t lost at the end of the retrospective.

Use Easy Agile TeamRhythm

LEARN MORE

Retrospective mistakes to avoid

Collecting feedback may sound simple, but there are many ways a retrospective can go wrong — from overpowering team members to asking repetitive questions to failing to capture insights effectively. Read our list of common retrospective mistakes to make sure your team doesn’t drop the ball.

❌ Skipping or delaying the retrospective

Due to a lack of time or resources, teams may consider skipping the retrospective. This is a costly mistake.

Do not, under any circumstances, skip a sprint retrospective. This is a critical time when the team has a chance to improve their processes. Skipping a retrospective enables the status quo and encourages complacency. The agile process is about continuous improvement — without the retrospective, you lose a critical opportunity to learn about the strengths and weaknesses of your team and its processes.

Delaying the retrospective can also be detrimental to your progress as a Scrum team. It’s important that you gather insights right after the sprint ends — while the ideas and issues are still fresh.

Delaying the retro could result in team members forgetting how the process actually went, leading to bland feedback that lacks the kind of detail that can create positive changes. And if delayed too long, something else could come up that takes priority over the retrospective, meaning the meeting may never occur at all.

❌ Always asking the same questions

The Scrum process is repetitive by nature, but that doesn’t mean your retrospectives should be boring or unbearably dry. Sticking to the status quo is a huge mistake in retrospectives.

When you repeat the same meeting every two weeks, you need to add variety in order to keep the team engaged. As soon as you lose team attention, engagement will drop, and the quality of the feedback you receive will too.

When running a retrospective, check in with yourself and the team to make sure engagement and interest stay high. If you are losing people’s attention and find engagement is dropping, change your format or the types of questions to keep everyone awake, attentive, and on their toes. Switching up who facilitates the meeting is another way to add variety into the mix.

❌ Allowing some of the group to dominate the conversation

Every voice on the team needs to be heard, but sometimes it’s the loudest ones that come through, well, the loudest. 📢 Effective retrospectives require multiple perspectives to deliver fresh insights.

Don’t let a select few voices dominate the conversation. A domineering team member will use all of the meeting’s time and limit the insights you can gather. If every voice isn’t heard, problems with the process could persist throughout multiple future sprints, severely impacting the effectiveness of your team. Plus, those who aren’t as loud will feel less involved and undervalued.

❌ Failing to empower softer voices

Along with discouraging domineering behavior, you need to amplify the softer voices.

Some people will be less likely to engage, or they may be too shy or afraid to express their opinions in a group setting. Watch out for this. If you notice it, find ways to make those underheard voices heard. It could mean asking them questions directly during the meeting, or it could mean taking a shy team member aside after the meeting to collect insights one-on-one.

If they find the group or your process intimidating, make the necessary adjustments to ensure everyone feels comfortable expressing their thoughts about the sprint. A retrospective is a collaborative process. Do what you can to engage and empower every member of the team.

❌ Jumping to conclusions without discussion

A single statement from one team member isn’t the end of the conversation. When team members bring up issues or ideas, they need to be discussed as a team. Do others feel the same way? Is it critical that this idea be implemented immediately, or can it be put on the back burner for now? How does a particular insight impact the product or customer needs specifically?

Don't jump to conclusions without having a meaningful discussion. You can gather information from your team quickly without throwing off your set meeting timeline. Don’t let any one topic throw you off course, but ensure you aren’t overlooking anything. If the team agrees an idea has merit, turn it into an action item that can be followed up on at the next retrospective meeting.

❌ Not implementing insights into the next sprint

Unfortunately, this is quite common. A team holds a retrospective meeting and does almost everything right only to fail to thoroughly record their team’s insights and put them into practice.

The whole point of the retrospective is to help your team improve. If you don’t properly document the feedback you receive from the team and don’t put those insights into action, you’re not getting the most from your retrospectives.

Turn feedback and discussion topics into clear action items you can follow up on later. Take important action items and insights into your sprint planning meeting and check in at your next retrospective. Were you able to make progress on the previous retrospective’s action items? What roadblocks did you hit? Do the action items require any further attention or follow-up?

❌ Not improving your retrospective process

Even a retrospective could use a retrospective! 🤯

Every now and again, take time to review your retrospective process. Ask your team to provide feedback on how they think the meetings are going. What do they like, what do they not like, and how do they think the retrospective meetings could improve?

You can improve on each aspect of your agile process. Go straight to the source to gather the opinions of those involved in the meeting. Do team members feel heard? Have issues been addressed to their satisfaction? Have the meetings grown stagnant?

When it comes to improving your retrospectives, your team has the data. Do not hesitate to ask.

Just because retrospectives come last in the Scrum process doesn’t mean they aren’t important. Don’t lose steam as you cross the finish line. Hold a retrospective at the end of every two-week sprint. Ensure each sprint retrospective includes insights from each team member and that insights are documented and transformed into clear action items.

📚 Additional resources

We have a wealth of free resources on the Easy Agile blog, and we continue to add to it every week. We recommend checking out our other guides as well as our top-performing agile content.

Thanks for reading our ultimate retrospectives guide! 👏 If you have any questions about this guide, our other content, or Easy Agile products, reach out to our team. We love talking to teams and individuals about agile and how to work better together. We’ll continue to update this guide as we gain more retrospective insights, techniques, tools, and best practices.

Using Easy Agile to improve your Agile process

If your sprint retrospective isn’t effective, your next sprint will suffer from the same issues. It is imperative that Scrum teams gather at the end of each sprint to discuss what went well, what didn’t go so well, and what can be improved on for next time. Otherwise, you invite complacency and stagnation into your Scrum process — the antithesis of agile.

Improve your Retrospectives with Easy Agile TeamRhythm. The Retrospective features in TeamRhythm help your team stay on the path of continuous improvement. Watch the highlights tour to see how Easy Agile TeamRhythm makes sprint planning, managing your backlog, and team retrospectives easier. Visit Atlassian Marketplace to start your free, 30-day trial today.

21 min read