According to the 2020 Scrum Guide, “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.” Scrum Teams must take the Retrospective seriously to achieve these outcomes. Let’s look at four tips for getting the most from your Sprint Retrospective and several agenda ideas that you can use to keep this event fresh.
Tip 1: Don’t Skip the Retrospective
It may seem like an obvious tip, but many teams decide to SKIP the retrospective! Don’t do it(!), because the Retrospective is an invaluable opportunity to continuously improve the way the Scrum Team works together. As a Scrum Master, the Retrospective is the most valuable event because it allows your team members to coach themselves in ways to continuously improve their adoption of Scrum, which makes the team more self-reliant.
Scrum Teams using the Retrospective as designed will make a series of smaller improvements, which, taken together, can add up to significant improvements over time. These teams are continuously improving how they work, thereby increasing their ability to deliver value to the organization.
Teams that skip the retrospective miss the chance to remove obstacles in their path and hamper the ability of the team members to learn how to identify and remove their own impediments. By contrast, teams that use the Retrospective as designed have higher morale because they can control how they work together. Teams that choose to skip the Retrospective miss out on a lot and aren’t practicing Scrum.
Tip 2: Understand the purpose of the Retrospective
Teams need to understand its purpose to get the most out of the Retrospective (or any other Scrum event). The table below provides a brief overview of the purpose behind each Scrum event.
By understanding the purpose of each event, Scrum Teams can structure them to achieve that purpose within their time boxes. The Professional Scrum Facilitation Skills training helps Scrum Masters and their team members turn unproductive meetings into effective events using facilitation techniques tailored to achieve the purpose of each event within its timebox.
Tip 3: Act on the ideas coming out of the event
When teams are not finding value from the Retrospective, often it’s because the event has turned into a venting session instead of a tool to identify and create a plan to improve how the team works together. The Retrospective will only be valuable if you identify improvements and then ACT to make them a reality.
Here’s a strategy for tuning up your Sprint Retrospective. Structure the agenda so that at the end of the Retrospective, the team has identified ONE improvement to how they work together or their Definition of Done. Then, create a plan for making that improvement. Although it’s not required, some teams find it helpful to add that plan for improvement to their Sprint Backlog for the next Sprint. Whatever you do, record the commitment to improve in a place accessible to the team. The team should track their progress to ensure they are taking action on the Retrospective commitment.
If, as the Scrum Master, you don’t entirely agree with the team’s Retrospective commitment, do what you can to support the team in their agreed-upon action. Otherwise, the team will be less likely to engage in future Retrospective events.
Tip 4: Keep it fresh with various agenda formats
It can be boring to use the same stale agenda Sprint after Sprint. Changing up event formats can enhance discussion, provide training and improve processes.
Below are a few ideas to freshen up your Retrospective event. You can use each of these on a shared electronic whiteboard on various platforms (e.g., Mural, Miro, Teams and Webex). Alternatively, you can draw on a physical whiteboard for an in-person discussion.
Liberating Structure - Heard, Seen, Respected
The purpose of the Sprint Retrospective is to plan ways to improve quality and effectiveness. Part of being an effective team is living the Scrum values. One powerful way to reinforce the Scrum values at the Retrospective is to use a modified version of the “Heard, Seen Respected” Liberating Structure, created by Keith McCandless and Henri Lipmanowicz. A full description of this activity is available on the Liberating Structures website here. A brief summary with a modification at the end is provided below.
Why use this liberating structure at the Retrospective? Scrum Teams work best when they use the five Scrum values to build trust among team members and their stakeholders. This Retrospective reinforces the value of Respect by asking team members to first discuss situations where they felt that they were not disrespected, and then asking the team as a whole to brainstorm ways that they can ensure that all members of the Scrum team and their stakeholders are respected.
Here’s how it works: First, ask the members of the Scrum team to pair up. Then, in their groups, ask them to each share a story with their partner about a time when they did not feel heard, seen, or respected. Make it safe for participants by advising them not to pick the most painful story that comes to mind! Be sure to advise the pairs to discuss which parts of each of their stories that they are comfortable with being shared with the rest of the group. Next, combine the pairs into larger groups (e.g., groups of four) and ask them to discuss what happened and what themes were uncovered. Finally, in a larger group, ask the team to talk about what they have learned.
Once this exercise is complete, ask the team to brainstorm ways that they - as a team - can ensure that all team members are respected. The team should then select one idea and take action on it as soon as possible.
Empiricism
Scrum is founded upon the concept of empiricism, which is making decisions based on what is known. The three pillars of empiricism are transparency, inspection and adaptation. Transparency means we all know what’s going on. Inspection means that those closest to the work inspect it frequently and adaptation means that it is ok to change direction when needed.
The Scrum artifacts, events and accountabilities can help improve the team’s adoption of these three pillars. Whenever the Scrum Team makes a change, they should ask themselves:
- How will this impact transparency?
- Will this affect our ability to inspect our work and ourselves?
- Will we still be able to adapt?
If the change improves the team’s adoption of these three pillars, it’s worthwhile. If not, the team might opt to abandon it.
Scrum Teams function best when they use the concepts underpinning empiricism to ensure that their events, artifacts and accountabilities are effective. This Retrospective agenda is an opportunity for the team to discuss each of the pillars of empiricism and then brainstorm how the team can better reflect them.
Here’s how it works: For this activity, get the team to discuss what each of the pillars of empiricism means. Next, brainstorm ways that the team can better embody the three pillars of empiricism. Finally, vote on just one action the team can take to improve the adoption of empiricism, which they should undertake as soon as possible.
Discuss Refinement at the Sprint Retrospective
While the act of refining is not an “official” event in Scrum, the process is essential. Refinement is the act of adding detail, order, or size to items in the Product Backlog. A well-refined Product Backlog helps teams deliver value to the organization and can improve Sprint Planning because the team can choose from appropriately sized and ordered items that will meet the Sprint Goal.
The way each team carries out refinement is up to them. Some teams have a weekly meeting where the Product Owner (or their representative) identifies the highest-ordered Product Backlog items (PBIs) and discusses those with the Scrum team for the purpose of adding detail, size and order to each Product Backlog item. As part of this meeting, the Product Owner and the team discuss ways to size each PBI so that the team can complete it within the Sprint.
Other teams use refinement to brainstorm new PBIs. Alternatively, some teams use refinement to discuss the roadmap or plan upcoming releases. Some teams assign business analysts to work with the Product Owner to document and refine PBIs. Refinement does not even have to be a meeting. It can be the act of individual Developers reviewing the Product Backlog to prepare for the next Sprint Planning event.
Teams who are newer to Scrum tend to struggle with refinement. They either do not have enough defined PBIs, or the items are too large to deliver in a Sprint. The Sprint Retrospective is the time to discuss these struggles.
Scrum Teams work best when they have the right amount of detail in the Product Backlog. That right amount differs for each team. This Retrospective agenda is an opportunity for the team to discuss how much information they need in the Product Backlog and to brainstorm ways to improve their refinement process.
Here’s how it works: The Scrum Team should first discuss what’s going well with refinement today. Are the right people involved? Is the discussion collaborative? Next, the team should discuss what’s not going well. Are we not getting the level of detail that we need? Are team members attending refinement meetings, or are they running so long that folks are skipping them? Third, brainstorm ways to improve your approach to refinement. Finally, vote on one improvement idea and create a plan for acting on it as soon as possible.
Conclusion
The purpose of the Sprint Retrospective is to improve how the Scrum Team works with people processes and their Definition of Done. It’s the Scrum Master’s most important event — don’t skip it! For more ways to keep your Retrospective event fresh, check out our article Ideas for Scrum’s Sprint Retrospective Event. To learn more about facilitation techniques, signup for Rebel Scrum’s Professional Scrum Facilitation Skills course. To learn more about the Scrum framework, signup for Rebel Scrum’s Applying Professional Scrum course.