5 Steps to Holding Effective Sprint Retrospectives
The retrospective is a critical part of the agile process, providing an outlet for teams to discuss how they can improve. A sprint retrospective comes at the end of each sprint and offers the team an opportunity to assess their processes.
What went well? What didn’t go so well? What does the team need to do to improve next time? Agile is all about learning and iterating. Every time you complete a sprint, there are lessons to be learned. Agile continually takes what a team learns — the good, the bad, and the bland — and turns those experiences into actionable improvements.
This post will dig into sprint retrospectives, including the benefits, how they fit within the Scrum process, how to run an effective sprint retrospective meeting, and common mistakes to avoid.
The purpose of the sprint retrospective
The sprint retrospective is a dedicated time for team discussion. The time is allotted at the end of each sprint so that all team members can examine what went well and what needs to change. It’s all part of the greater agile methodology of continually improving your processes as you learn more. There’s no one set way of doing things, and there’s always room to become more efficient and effective.
A sprint retrospective:
- Encourages a continuous improvement mindset
- Creates a safe space for sharing positive and constructive feedback
- Gives everyone on the team an opportunity to express thoughts, ideas, and experiences
- Provides feedback in real-time after each sprint
- Brings the team together around common goals
- Exposes any issues from the previous sprint that are holding the team back
- Informs leadership of success and potential roadblocks
- Helps product owners make decisions for the next sprint planning
- Sets the team on a positive path for moving into the next sprint
How the sprint retrospective fits within the Scrum process
The type of retrospective you hold depends on the type of sprint or agile methodology your team practices. One of the most common methodologies in software development is the Scrum framework.
A Scrum team has three types of roles:
- Product Owner
- Scrum Master
- Development team
At the beginning of each Scrum, the product owner decides which items from the overall product backlog are moved to the sprint backlog to be completed over the upcoming 2-4 week sprint. The exact sprint timeframe is set in advance.
The Scrum is made up of four distinct ceremonies or events:
- Sprint planning
- Daily Scrum or stand-ups
- Sprint review
- Sprint retrospective
After planning is complete and the team knows which backlog items they are going to tackle for the current sprint, the work begins. The team checks in throughout the sprint via a daily scrum or stand-up meeting. This quick but essential check-in allows the Scrum team to discuss their progress and address any potential roadblocks on a daily basis.
The sprint review meeting takes place at the end of the sprint; it’s an opportunity for Scrum team members to showcase the work accomplished during the sprint. This could be an internal presentation or a more formal demo to stakeholders.
Last comes the incredibly important Scrum retrospective. During this time, the team can discuss what went well and what could be improved so the upcoming sprint can run more efficiently. Anything that’s learned along the way or discovered in the retrospective is brought into the next sprint planning session. This Scrum process repeats until there are no more product backlog items or the product is complete.
How to run an effective sprint retrospective meeting
The retrospective is a critical part of the agile process that should be treated with care and respect. Go in with a plan. Winging it might get you by, but everyone will get more out of the process if the person or people leading the retrospective is prepared.
Use our strategies below to run effective retrospectives that everyone looks forward to.
1. Ensure everyone’s voice is heard
The loudest voices in a sprint retrospective often get the most attention and speaking time, but they don’t necessarily have better insights than anyone else. Each person involved in the sprint process should be given an opportunity to speak.
If you find a few people are dominating the conversation or that some people never contribute, switch up your strategy to include everyone. Go around the room one by one with a question that each person needs to answer, such as “What do you think went well in this sprint?” or “What was your biggest challenge?”
2. Start, stop, continue
The 'Start, Stop, Continue' retrospective format can be expressed in many forms, but the general practice is the same. At the end of a sprint, you decide what you want to start doing, what you want to stop doing, and what you want to continue doing as you move into your next sprint. It’s a simple format that covers both what went well and what didn’t go so well.
Other versions of this exercise include the Rose Bud Thorn exercise, where participants share something positive, a budding opportunity, and a negative to improve upon. There’s also the Anchors and Sails exercise, where participants share what put wind in their sails (went well) and what anchored them down.
3. Establish specific action items
The retrospective is a waste of time if you don’t leave with specific action items. What is your team going to do about the issues brought up in the meeting? Ensure you keep track of the issues and the positive feedback people provide so that you can turn them into actionable tasks or goals before the meeting is complete.
You can’t implement absolutely every change that is brought up, but the discussion should give you a place to start. Work with the team to figure out what changes will provide the most impact. You can use an impact effort matrix or similar agile tools to make informed choices.
4. Retrospective the retrospective
Every now and again, take the time to review your retrospective. Ask for feedback from all team members on how the process could improve. What would make the experience easier on the team? What would they like to see implemented? What hasn’t been working during your recurring retros?
Wow, that’s getting a little meta, but it’s an important step. You need to continually assess your retrospective as well to make sure you’re getting the most out of the experience.
One thing to watch for: When people are bored, they engage less, which means it’s important to switch things up. You don’t want your retrospective process to run stagnant or lose its effectiveness.
5. Review action items at the next sprint retrospective
Make sure the hard work of your retrospective pays off. At the beginning of the next retrospective, take a small bit of time to review your previous action items. What goals and action items did you leave the last retrospective with? Did you accomplish what you set out to do, or do you still need to work at it?
Common retrospective mistakes to avoid
Avoid these common mistakes when running sprint retrospective meetings:
❌ Allowing a few people to dominate the conversation
❌ Not empowering softer voices
❌ Jumping to conclusions without a thorough discussion
❌ Asking the same questions over and over without mixing things up
❌ Forgetting about or not implementing the action items of the previous retrospective
❌ Skipping a retrospective due to lack of time or resources
❌ Forgetting about stakeholder and customer needs
❌ Failing to improve upon your retrospective process
Put your retrospective ideas into action with Easy Agile TeamRhythm
Sprint retrospectives help the entire team learn from each experience and improve. Doing them effectively means evaluating the retrospective itself, empowering voices, and listening to them.
We’re passionate about putting the needs of the customer first and foremost. Easy Agile builds products specifically designed for Jira users to help agile teams work more efficiently and effectively.
Easy Agile TeamRhythm supports the work of your agile team from planning right through to retrospective, encouraging continuous improvement so you're always getting better at what you do, and delivering better for your customers.
Related Articles
- Agile Best Practice
How to Lead Agile Retrospectives for Constant Improvement
Agile retrospectives offer opportunities for introspection. As with many things in life, the end is almost as important as the beginning. That’s why it’s important to improve what went wrong throughout the iteration and repeat what went well.
The retrospective meeting should be held at regular intervals to analyze team processes and outcomes. Reflecting on the last sprint should help guide the next one.
Sprint retrospectives are also informal but structured. Informality is a typical characteristic of the retrospective meeting, which motivates problem-solving.
In this article, we’ll review what an agile retrospective is, how to lead it successfully, and how to use the retrospective format.
What is an agile retrospective?
An agile retrospective is also known as the sprint or sailboat retrospective.
The Scrum Guide provides a clear definition of the agile retrospective. The Guide says the agile team can use the sprint retrospective as an opportunity to gather rapid feedback for continuous improvement. Continuous improvement takes place through ongoing teamwork and work analysis.
During the meeting, the team discusses what went well and what didn’t. They should identify the good, that they will aim to repeat as well as the areas to adjust, so the next sprint can go more smoothly.
Here’s how the 12 principles of the Agile Manifesto describes retrospectives: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
How to implement a sprint retrospective format
You can either implement the agile retrospective after each sprint, quarter, or the entire project. However, you should have a retrospective at regular intervals to continue iteration and improvements.
Use a retrospective format for each meeting. Creating a retrospective board is a great place to start, it sets the scene for the team involved and they know exactly what is expected.
We've added retrospective boards to Easy Agile TeamRhythm to help you and your team through more of the agile cycle, from planning through to review.
Here’s how to plan the sprint retrospective:
1. Preparation
Like a standup meeting, your preparation time for the retrospective should take about 15 minutes. The retro is like a lean coffee meeting where the agenda is relatively unstructured but democratic. Everyone gets to contribute.
Ideally, you want to have a retrospective board where team members can capture feedback as it arises. Be sure to remind team members to add their thoughts to the board prior to the meeting.
The retrospective board helps guide the retro process through tasks where the team fell short or excelled with action items. It also helps to identify areas of improvement and the actions the group must apply to effect change.
If in-person team members don’t use software to facilitate their agile retrospective, they can use another technique. This technique usually involves a whiteboard, Post-Its, and markers to guide brainstorming throughout the meeting.
Whichever methodology (Scrum or Kanban) the scrum master uses, a visual representation helps facilitate the best possible outcomes for future workflows.
Hot tip 🔥
It is best to rope in a neutral facilitator or agile coach to guide this process. This technique should help encourage team members to participate and share without feeling pressured.
2. Use the retrospective template to guide your agenda format
The retrospective board helps direct the agenda for the meeting format. Whether you choose start, stop, continue, glad, sad, mad, or our team's personal favourite - high notes, low notes and keeping the beat. Make sure you customise it to suit your teams needs.
Typically, the process follows six steps:
2.1 Set the stage
Refresh your memory about themes and stories in the last sprint if necessary. Set a timer and give the team a little extra time to add any last minute thoughts or items that may be missing
At the start of the retrospective, the Scrum master should introduce the product owner, team members, and other relevant stakeholders.
Welcome everyone and let them know that their participation is valuable. Inform team members that honesty is critical in producing positive outcomes. Ensure new teams know that questions are welcome, and that sharing experiences is vital to a successful sprint retrospective.
Throw in an icebreaker to set the tone of the meeting. A brief game of “two truths and one lie” can quickly promote a relaxed atmosphere if you have enough time.
Let the team know the amount of time it should take to complete each section of the sprint review. To keep everyone on track, the timer can come in handy again here.
2.2 Celebrate the wins
Congratulate team members who excelled. Discuss posting success stories on LinkedIn or elsewhere before moving on with the sprint review. Interact with items made on the retro board, react with an emoji or leave a comment.
2.3 Gather data
Data gathering includes collecting information from team members about sprint retrospective problems. The purpose is for the team to uncover the root cause of the problems.
Team members begin this process by sharing sprint experiences. Whether the experience was good, bad, or ugly—share it. It’s always a good idea to capture how everyone is feeling, take a mood survey to understand the overall team feeling.
Share the processes you used and which milestones you accomplished. If team members applied new technologies, share how those went. If they used new tools, let everyone know the pros and cons of each tool. Whatever the experience, let everyone know what worked well and what was a disappointment.
The Scrum master can facilitate this phase by using the “five whys” methodology. The “five whys” essentially refers to asking why a problem occurred, five times. Repeating the question multiple times supports deep thinking to get to the root cause of the problem.
2.4 Brainstorm solutions
Once the team members identify the shortcomings of the previous sprint, they can brainstorm solutions.
The team meeting should now revolve around associations between problems and solutions. Linking problems and solutions involves understanding. Once the team understands their mistakes, they can brainstorm several solutions to fix each problem area with better action items.
Throw in as many ideas as possible to have several solutions for consideration. Once the team has alignment on the action item, be sure to capture this so the appropriate next steps can be taken.
The retrospective board in TeamRhythm sits alongside your work in Jira, so that retrospective items can be added as the sprint or version progresses. Action items from the retrospective can be turned into Jira issues so that items worth actioning aren’t lost at the end of the discussion.
The Scrum master should also ensure that the team has the authority to follow through with relevant solutions at this stage. If they don’t have the authority to solve problems, the Scrum master must bump the issue up to a higher level.
2.5 Select viable solutions
Not all solutions from the brainstorming phase will be viable — ask the Scrum team, including the product owner, to choose three promising solutions for each problem. You can use different techniques to narrow this process, and ask team members to vote. You might want to try a dot vote, or up vote by giving the solution a thumbs up.
The simple vote requires everyone to select the solution that resonates best with them in the follow-up activity. In the dot vote, meeting participants find the best three solutions by placing a dot on three of the ideas they believe hold the most value.
Lastly, the multiple vote system means that the scrum master gives everyone points. The scrum team must then give these points to one or more of the best ideas.
2.6 End the meeting
End the meeting on a positive note before continuing to the next sprint. Try to leave with:
- A detailed synopsis of the previous sprint
- A detailed sprint planning exercise for the next sprint meeting
- Clear action items and next steps
- Collaborate as a team to determine whether this outcome is effective or needs improvements for the next iteration
3. Sprint retrospective meeting outcomes
Software development teams can use the S.M.A.R.T. criteria to analyze their solutions. Getting the product owner's inputs is a valuable part of the retrospective meetings as they diversify priorities and perceptions
The agile coach or Scrum master takes the S.M.A.R.T. solutions and translates these into item actions. The Scrum master should ask team members to take responsibility for activities to promote ownership and encourage behavioral change.
Once the product owner agrees, each activity should then become part of the backlog.
How to achieve successful retrospectives from in-depth introspection
An in-depth introspection promotes continuous improvement and productivity. Following a retrospective template helps achieve these goals, while supporting integrated teamwork. The product owner also benefits from your team efforts with each sprint retrospective, which is a primary objective.
Gain team alignment with team retrospectives
Easy Agile TeamRhythm supports agile retrospectives, helping you and your team gain a shared understanding of the work, and how you work best together. Designed for Jira users, our goal is to help agile teams work together effectively.
- Workflow
Sprint Retrospective Templates to Help Run Better Sprints
Agile retrospectives are a time to reflect on the sprint before. During this time, the Scrum team decides on the agile retrospective template to use during retrospective meetings. A sprint retrospective template provides a structure for retrospective meetings. These retrospective templates guide agile teams in analyzing their previous sprint.
What is an agile retrospective?
Teams use agile retrospective meetings to improve the next sprint. As the team members move through the product life cycle, they gain new learning after each sprint retrospective, which they apply to the next sprint.
The focus of the sprint retrospective meeting
Sprint retrospective meetings ask four questions, as listed below. The agile team places these four questions in the four quadrants of their retrospective template. (Note: Team members can use a whiteboard or sticky notes to set up their meetings. Or they can use Jira software to facilitate remote team meetings in real-time.)
Co-located agile teams can also use whiteboards and sticky notes to do an agile retro. But for remote teams, agile retrospective template software allows all team members to participate in sprint meetings.
Here are the four question areas for discussion:
- What went as planned?
- Where could the team have made improvements?
- What should team members do in the next sprint?
- What confuses the team?
1. What went as planned?
The agile retrospective requires in-depth analysis. Team members can chat about what they enjoyed, which methodologies worked for them, and what agile ideas are worth taking into the next sprint.
Typical questions that agile teams ask in this first stage include:
- What were team members happy with?
- What actions delivered positive results?
- What processes or actions should the agile team continue with?
- Should anyone receive a special thanks for their contribution?
2. How could the team have improved?
Stakeholders examine where they went wrong and try to find the root cause of the issues. Brainstorming involves what they could have tried previously, where improvements are needed, and what processes or actions they can test in the next sprint.
Here are some ways to make this question more concrete:
- What has the team previously not tried that might work?
- What is one new thing that we could attempt?
- What new tactics or actions can we test next?
3. What should team members do in the next sprint?
In this part of the template, the team explores new ideas for how to improve their follow-up approach. New ideas can be risky, so the Scrum team should carefully consider opportunities for improvement. The idea in this questioning phase is to clarify problem areas, where value was not produced, and what was puzzling in the previous sprint.
In this round, the team should discuss:
- What didn’t work?
- What did the team do that did not produce value?
- Which areas specifically require improvements?
- What did not go as anticipated?
- What issues in the previous sprint are confusing?
4. What still confuses the team?
In this section, the team should focus on areas that weren’t as effective or did not go as anticipated and what areas need improving. Other relevant areas include where the agile team didn’t deliver value, focus areas that require development, and what was confusing about the sprint.
Here, it’s important to talk about:
- What questions still remain unanswered?
- What outcomes still require further investigation?
- Is the team following processes that don’t deliver clear value?
Through a process of iteration, the Scrum team brainstorm to come up with real-time solutions to take over to the next sprint. Using retrospective ideas, the team populates the four quadrants of the retro template, producing a visual representation of their post-mortem.
Scrum teams can apply the four questions above in other retrospective templates or customize a template to conduct their post-mortems.
Retrospective template options
Team members can choose from retrospective templates to customize their sprint meetings.
Sprint planning can benefit from any of the agile retrospective templates below:
- The start, stop, continue template
- The four Ls retrospective template
- A starfish retrospective
- Sailboat retrospective
- Glad, sad, mad
- Mad, sad, glad
1. Start, stop, continue
In the “start” part of this retro, the agile team looks at the actions they’ll take in the next sprint. “Stop” refers to looking at the recently completed sprint to examine what didn’t work and the actions that the team should no longer take. “Continue” means identifying what worked in the current sprint and should be taken over to the next cycle.
2. Four Ls
Agile teams use this retro template to understand what they “Loved, Learned, Loathed, and Longed for” at the end of the sprint iteration. The team calls out what they appreciate, what the sprint taught them, what went wrong, and what they would’ve wanted more of (coffee, team members, time, etc.).
3. Starfish
Instead of using a retro that focuses on what worked and what didn’t, the starfish highlights degrees of efficiency in deliverables. Teamwork involves rating action items as levels of effectiveness to determine what methodologies they should keep, discard, and apply in the next round.
4. Sailboat
Scrum teams use the sailboat retro to determine their trajectory in unknown waters. Applying the sailboat retro means knowing what approaches inhibit progress, what new approaches will reap desirable outcomes, and establishing a direction for sprint planning.
5. Mad, sad, glad
The mad, sad, glad sprint retrospective is a technique that concentrates on the emotional status of teams. Scrum teams ask each other questions to create positive emotional support. These questions are also aimed at morale-boosting to create a positive atmosphere that supports teamwork and continuous improvement.
The agile retro can follow any template they choose or select one and customize it for their specific needs. Whatever they do, teamwork is vital to the success of continuous improvement.
Decide on your retro template today
Now that you understand how the sprint retrospective template works, you can customize yours for joint teamwork.
Instead of focusing on longed-for outcomes and functionalities, Easy Agile can help your Scrum team move from sad to glad.
Team retrospectives right inside Jira
Looking to improve how your team is working together? Easy Agile TeamRhythm helps you turn insights into action with team retrospectives, to improve how you’re working and make your next release better than the last.
- Product
Overcome common retrospective challenges with Easy Agile TeamRhythm
Retrospectives help create an environment where team members can freely share their wins and challenges. By encouraging this feedback, you get critical insights into what can be improved in the next iteration. But while it sounds straightforward in theory, many teams struggle to make agile retrospectives work in practice.
So if we know team retrospectives can be a great way to drive continuous improvement and deliver value – why do so many teams struggle to get it right?
The slippery slope to becoming a tick box exercise
According to Easy Agile Product Marketing Manager Tenille Hoppo, the struggle with retrospectives often lies behind two key challenges. "If you’re having the same discussions week after week, and the team can’t see anything changing, then people can become fatigued, disengaged, and bored," said Tenille. "Over time, retrospectives become less respected and less effective as a process, and eventually become nothing more than a tick box exercise".
"Then there’s the challenge around capturing actions in real-time," said Tenille. "We’ve all been guilty of having great ideas while working on something, but by the time the next retrospective comes around, the idea is gone".
The challenges around keeping retrospectives fresh, productive, and integrated with the work in Jira are behind the development of Easy Agile TeamRhythm, an app designed to overcome these common issues and help teams deliver value to their customers more quickly.
Integrating user story maps and retrospectives
"We believed if we could integrate the retrospective process right alongside the work in Jira, teams would be better able to deal with the issues blocking their progress and work more effectively," said Tenille. "So, we mapped out the groundwork as part of an Inception Week project, and soon after that, Easy Agile TeamRhythm was born".
Easy Agile TeamRhythm replaces our first app, Easy Agile User Story Maps, and integrates team user story maps with team retrospective boards. The user story maps are used for planning and managing work (including sprint planning and backlog refinement), while retrospective boards help teams do that work better. "It made sense to build on the sprint planning and backlog refinement capabilities of Easy Agile User Story Maps and introduce retrospective boards to capture and collate ideas for improvement," said Tenille. "With retrospectives colocated where work is managed in Jira, you can turn action items into Jira issues and schedule work, ensuring retrospectives are effective and valuable".
Elevating retrospectives with Easy Agile TeamRhythm
Easy Agile TeamRhythm supports teams from planning through to release and retrospectives. It covers user story mapping, sprint planning, version planning, backlog refinement, and team retrospectives.
By featuring a team retrospective board integrated alongside your Jira boards, agile teams can use the app to:
Capture feedback in real-time
Team members can capture feedback quickly and easily as they do their work. As a result, feedback and ideas don’t get lost and, instead, are there waiting for you when you run the next retrospective.
Combat fatigue with templates
You can access different templates to help change the format of retrospectives, frame things differently, and keep team members interested. This can also help teams see things from different angles and come up with new ideas.
Current templates include:
- Foundation
A highly customizable template based on the Start, Stop, & Continue model. The team looks at looks at the actions they want to introduce, those that aren't working, and what can continue into the next cycle. - Get Rhythm
A music-themed template using the 4 L’s retrospective format, to understand what is “Loved, Learned, Loathed, and Longed for”. The team calls out what they appreciate, what the sprint taught them, what went wrong, and what they would’ve wanted more of. - Space Mission
A stellar-themed template based on the Sailboat retrospective format, examining the approaches that inhibit progress, or reap desirable outcomes, and establish a direction for planning the next iteration. - Rose Blossom
A rose-themed template based on the Starfish model, that involves rating the efficacy of action items to determine the methodologies they should keep, discard, and apply in the next round.
Improve the next iteration by applying insights
The ‘Actions’ column is where you turn feedback into tangible actions and create in-built accountability. In just two clicks, you can turn an action item into a Jira issue that is automatically added to your backlog. You can then assign an owner and schedule it into an upcoming sprint or release.
“We’ve improved our communication and team alignment, which has helped give us faster results”.
Casey Flynn, Adidas
Make your next release better
"Agile isn’t about wringing every ounce of work you can get from your team, and it’s also not about wasting time in unproductive meetings that don’t drive an outcome," said Tenille. "With Easy Agile TeamRhythm, we provide the framework and functionality to help share learnings, plan solutions, and take action. And as teams focus on incremental improvements, they can start working better together, feel happier in their role, and deliver better outcomes".
TRY EASY AGILE TEAMRHYTHM FREE FOR 30 DAYS
Like to hear more?
Tenille presented on this topic in a webinar with Atlassian Solution Partner Almarise. Watch the full presentation below.
- Foundation