Agile retrospectives offer opportunities for introspection. These meetings should be held at regular intervals to analyze development 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 retro 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. This definition is the ideal start to holding your lean coffee meeting.
The Guide says the agile team can use the sprint retrospective as an opportunity for continuous improvement. Continuous improvement takes place through ongoing teamwork and work analysis. During a retrospective, the team discusses what went well and what didn’t 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 behavior accordingly.”
Unlike the sailing philosophy of Captain Sparrow in Pirates of the Caribbean, the sailboat retrospective is characterized by sprint planning. As serious as the process is, the team members are encouraged to treat this process with humor.
How to implement a sprint retrospective format
Use a retrospective format for each sailboat meeting.
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.
Here’s how to plan the sprint retrospective:
Like a standup meeting, your preparation time for the scrum retrospective should take about 15 minutes. Remote team preparations can create a Confluence page to guide the team meeting.
You can use the Confluence page to post a collaboration document on software development boards like Jira. This document 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.
The retro is like a lean coffee meeting where the agenda is relatively unstructured but democratic. Everyone gets to contribute.
However, 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 sprint retrospective template helps direct the agenda for the meeting format. Whether you choose the start, stop, continue, sailboat, glad, sad, mad, or other template, the process typically follows six steps:
2.1 Set the stage
Refresh your memory about themes and stories in the last sprint if necessary.
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.
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.
2.3 Gather data
Data gathering includes collecting information from development 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. Gather data about action items and the outcomes. Record the decisions made about action items.
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 software development team understands their mistakes, they can brainstorm several solutions to fix each problem area with better action items.
Coming up with sprint retrospective ideas at this stage is vital for a successful post-mortem. Throw in as many ideas as possible to have several solutions for consideration.
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 three convenient retrospective techniques to narrow this process, including the simple vote, the dot vote, or the multiple vote system.
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 format
- Setting an exact date for the next sprint review
- 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.
At Easy Agile, we always place the customers' needs first. Our products, designed for Jira users, help agile teams work together effectively. Easy Agile User Story Maps can help your team clearly visualize the customer journey together. Try it free for 30 days.