Retrospectives play a crucial role in continuous improvement. But how do you feel about yours? Have they resulted in any improvement? Do you know where to begin? There are many retro templates and techniques available for creating a good retrospective culture in your organization. The purpose of this post is to teach you everything you need to know about retrospectives and how to perform them.
Retrospectives 101
What is a sprint retrospective?
Retrospectives are a chance for your team to analyze the past to better prepare for the future. If you’re not continuously improving, you’re not Agile. As the Manifesto for Agile Software Development states:
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Retrospectives, or retros, offer a chance to uncover what works well for a team, and what doesn’t. Retrospectives check the pulse of a team. Teams can take time out of their everyday tasks and reflect on the big picture, identifying potential stumbling blocks before they turn into problems. Retros give all team members a chance to speak up and produce a set of possible actions to improve.
Typically, retrospectives seek to answer three questions:
What is working well for you?
What isn't working properly?
Should we change anything?
As you can see, retrospectives are an important tool for team members to identify challenges and gather information about what happened during the sprint. Using what they have learned, the teams can then develop new ways to work on projects and avoid relying on default thinking patterns.
The Prime Directive or The one thing you need to remember
In many retrospectives, facilitators will open their meetings by reading the Retrospective Prime Directive. The objective is to ensure that the team has a positive mentality heading into the event retrospective. Reaffirming the value of retrospectives in agile workflows, and showing teams how to approach them properly.
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
With the retrospective, team members reflect on a sprint, or period of work, which has just ended. After achieving a milestone, creating a design or product, and moving to the next phase, you're ready to proceed. A retrospective serves as an intermediary step for your team to reflect on what went right and what went wrong. Afterward, you'll know what to improve and what to keep.
Even though it's supposed to be a positive and constructive exercise, it can easily slip into a negative and criticizing one. This is why the prime directive instructs teams to focus on positive aspects. As opposed to believing missed opportunities result from inaction, consider your team's limitations, and remember that some goals are simply unattainable. Make a plan that is reasonable and morale-enhancing rather than pushing your team to work harder.
Who should take part in a retrospective?
The scrum guide states that all members of the Scrum team should be invited.
"The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint."
Who exactly is on the scrum team? According to the guide there are three personas:
Product owner - This role is responsible for maintaining the product backlog, which contains all the tasks associated with delivering the final product.
Development team - This is the team that actually works on the project during a Sprint.
Scrum master - A professional who understands and applies Scrum processes and workflows. They ensure that everyone is on the same page when it comes to Scrum theory, practices, and rules.
It seems to us that we can widen this a bit. The retrospective should be attended by all members of the team, with a facilitator leading the discussion. The facilitator can be a scrum master, a product owner, or it can rotate among team members. We encourage you to include designers, marketers, and anyone else who contributed to the current sprint or iteration.
Retrospective facilitator? Is it really necessary?
Retrospectives belong to the category of meetings called "participatory group learning." Any time you ask a group of individuals to analyze together, pose a problem together, or come to a decision together, you are in a participatory learning environment.
Why do “participatory group learning” activities require a facilitator? Here's what would happen if there was no facilitator: those who are the most outgoing or senior will likely speak up first. The rest of the group will be biased - whether consciously or not. As the next speaker speaks, he or she will expand on or challenge the first idea. It doesn't matter how you look at it, the conversation is now focused on what was shared initially.
Perhaps the first idea should be discussed. This is an assumption that might not always be true. Facilitation can fill that void.
It is the facilitator's responsibility to create an environment that ensures you have a constructive conversation that focuses on the right topic at the right time, rather than wishing you did.
The participant must be encouraged to participate fully, the group must be enabled to understand each other and come to solutions from different perspectives, and the team needs to assume ownership of the meeting's outcomes.
How to conduct a well-facilitated retrospective meeting?
Retros don't always go smoothly and it can be hard to plan everything and organize a framework if you don't have everything planned. You will learn how to conduct your sprint retrospective with GoRetro by following a few simple steps.
To begin with, you should invite each stakeholder (development team, product owner, scrum master) to the retrospective, and you should assign a facilitator to lead it. Facilitators can be team members or external individuals with whom the team feels comfortable sharing details.
You can start by creating a board on GoRetro, and if you'd like to simplify things, you can select the 'what went well' template format.
Step 1 - Put things in perspective (remember the prime directive)
Focus the team on the retrospective and create a respectful and safe environment.
Step 2 - Re-examine the minutes of the previous retrospective meeting
You should begin the retrospective by reviewing whether all actions from the previous retrospective have been completed. If not, why hasn't it been done? Time this for five minutes.
Step 3 - Do a brainstorm
Ask your participants to brainstorm individually and write down their thoughts on the "Went well" and "To improve" columns. It should be about something that happened during the last sprint that stakeholders thought was worth sharing. This step can be controlled by a facilitator giving people 10 minutes to write. Once 10 minutes are up, everyone should stop writing.
Step 4 - Join similar cards
The facilitator should read cards one by one and ask people whether they believe the card should be merged with another one on the board. The facilitator can merge them if all participants agree.
Step 5 - Demonstrate democracy by voting
The facilitator should assign about 5 minutes for the people to vote on the cards they want to discuss.
Step 6 - Follow up and action items
When everyone has voted on the cards, you can sort the columns by votes and select the top cards for discussion. This is the most crucial aspect of the process.
Ultimately, it is the role of the retrospective facilitator to keep the discussion open but not lose focus by falling into unnecessary (time-consuming) discussions, ensuring that all stakeholders are heard, and maintaining high levels of communication in the discussion. Prior to the discussion, the facilitator should outline what the expected outcome is.
Afterwards, the team can discuss how the problems can be resolved and what constructive things can be done to resolve them. Read more about action items in the next section.
This is the simplest retrospective format and while it's not perfect, it works. GoRetro provides a wide range of retrospective templates and ideas for more advanced uses!
Action items
In the aftermath of a retrospective, there is a sense of satisfaction that the team's feedback has been captured, that they have been engaged and that they have come up with some good ideas. Each was captured, written down and voted on, and actions have been decided on. However, how can you ensure actions are taken on the items captured in the retrospective?
Generally, action items can be separated into two categories based on the expected delivery timeframe:
Reminders/ongoing items, which should always be kept in mind by the team. These include action items related to interactions with other teams and activities. In successive retrospectives, you can determine whether or not the team still needs to be reminded of this action item. These action items can be kept open for quite some time until the team decides they have been conquered and no further reminders are necessary.
Direct/specific action items represent actions that the team or a team member should carry out once, which makes everyone's life easier. It can be a report, a discussion with another team, or setting up an automated process that will benefit everyone. In the next retrospective, the team can assess whether this specific action item achieved the team's desired outcome and decide whether to consider it complete. Every time we talk about a direct action item, the three W's are always considered: What, When, and Who:
Who? Essentially, this is the individual who will be handling the task. This action item will state clearly who is responsible for completing this task.
What? This is a very important component of the action item. Due to the fact that it is the description that tells the person what he or she needs to do to complete the task. In addition to being clear, the Why also needs to be short and to the point so that no ambiguities remain.
When? This is the timeframe in within the task should be completed. In some cases, it is referred to as a deadline.
It is recommended to stick with smaller action items that can be completed within a logical time frame like a month, so that the team remains motivated and enthusiastic. Assured small wins are a more robust tactic for continuous improvement than aiming high right away.
SMART goals
Now, let’s revisit the original definition of the retrospective according to scrum.org:
“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”
The first two components (inspect and create activities) are activities, and the third one (improvements) is a result. Despite having fruitful conversations and creating action items to achieve the desired results, few teams implement systems to guarantee that they actually deliver on these promises.
A retrospective is only as effective as the action items set, and how they are followed up on. However, there is an issue with the concept of "improvement:" it is subjective and vague, and most importantly, it does not enforce accountability. There must be a better way to accomplish these goals. This is where the SMART goals framework comes in. SMART stands for Specific, Measurable, Achievable, Realistic, and Time-sensitive. You can read more about SMART goals here.
Using data in retrospective
It is common for teams to conduct a retrospective in the same way every week. That’s great if it works for you. Nevertheless, continuous improvement can easily become stale and can often stall. In most cases, retros are based on individual opinions. New formats/templates are presented in a variety of books and websites, but most of them are based on opinions and subjective approaches.
You can build a transparent and adaptive team culture by integrating data-driven approaches into your retros. In addition, data-driven retros promote a culture of ownership, accountability, and self-directed learning so that your team will grow in all aspects of their agile practice and process.
When data is gathered, it gives the team a chance to develop a shared understanding of what happened, which allows for a more meaningful discussion about how to improve. So what data do you need to present at your next retrospective? In what ways can you effectively utilize them?
What type of data you should provide
Objective data
An objective data set is any piece of information that is measurable and verifiable. Objective data comes in many forms. Some examples include:
Sprint goal
Burndown chart
Velocity and throughput (number of tasks finished per day)
Completed tasks (number of tasks, story points, time estimates, etc.)
Completed tasks as a percent of number of tasks started
Number of new support/production issues requests
A task's average cycle time during a sprint
Remember, not all of this data needs to be brought to every retrospective (though you can certainly do so). Bring the data you believe is the most relevant, given what's going on.
Subjective data
Objective data includes facts and figures, whereas subjective data includes opinions, feelings, and emotions. Rather than presenting the facts, subjective data can reveal what your team thinks is important about them.
You can gather subjective data by asking the following questions:
Was there a moment during the sprint when you felt motivated? Demotivated?
During the iteration, what was your favorite moment? Your least favorite?
How satisfied were you with your new practice (perhaps you implemented a new development tool or code review protocol)?
Collect the happiness score of each team member.
Retrospective with remote teams
The remote work trend is here to stay. In the face of these challenges, how can we overcome them and help teams work together to foster unity and encourage team participation, no matter where members are physically located?
How to run a remote retrospective?
A remote sprint retrospective is exactly what it sounds like: a remote variation of a retrospective meeting via video. The goal of these virtual meetings is to reflect on what the team has done so far and determine how they can be improved upon for the next sprint.
A remote retrospective can be run by:
Monitoring attendance and engagement: A remote retrospective is only successful if the entire team participates. Running a remote retrospective effectively means ensuring everyone is present and engaged.
Reviewing work completed: The majority of the remote retrospective session should be spent in discussion. In order to remind everyone what was accomplished in the past sprint, the meeting should begin with a quick review of the previous sprint.
Discussion: This should take up most of the meeting. As long as everyone participates and the goals are met, it can be very open-ended.
Actionable goals: This is the primary goal of a remote retrospective. The team should come up with actionable ideas for the next iteration based on the previous iteration. In order to improve the next sprint, the team should come up with measurable actions to be implemented.
When everyone is engaged and participating, remote retrospectives are easy to run. The main objective is to review the past iteration and determine what can be improved for the next one. Find out more about remote retrospective in our dedicated blog post.
Ready to have a data driven sprint retrospective?
No matter where you are working from, keeping retrospectives engaging, productive, and organized can be a challenge. We make it simple for you to plan, facilitate and track Sprint Retrospectives with our digital platform. Grab your free account today.
Contact Us
Thank you! Your message has been sent!
Oops! Something went wrong while submitting the form.
.png)
.png)
.png)
.png)
.png)
.png)
