Retro
Table of Contents
Introduction
What should a retro encompass?
Is a Retro Meeting Neccessary?
Planning a Retro Meeting
Key Takeaways
Resources
Introduction
A Retro is a meeting reserved for the end of a sprint, and goes about reviewing the work completion, overall team engagement, bringing up successes/issues that occurred during the sprint. The purpose of reviewing this as a team is to gauge the general work ethic of the team, as well as provide a space to bring up issues that would otherwise fall to the wayside during other meetings. Ultimately, by running a retro, it provides an opportunity to re-evaluate what happened during the sprint, and to facility higher-level problem solving and address the potential issues that occurred during the sprint.
What should a retro encompass?
A Retro typically encompasses three primary features that help build towards a proactive meeting. As a product manager or person running this sprint, try to answer these questions when applicable.
- Sprint Overview
- How many tasks were completed during the sprint? Their total points? (if applicable)
- Sprint Impression
- How did the team feel about this sprint?
- If they can describe the sprint in one word, what would it be?
- What went well? What went wrong?
- What sprint goals were achieved?
- What roadblocks occurred?
- Were there any interpersonal conflicts?
- Who was unavailable during the sprint?
Is a Retro Meeting Necessary?
Retro Meetings tend to get overlooked due teams tending to merge Sprint Review meetings together with Retro Meetings to save time. This isn’t a bad thing, but neglecting to put the time and effort to compile and summarize the overall team impressions, successes, and failures are. In short, you can try to condense the meeting, but make sure you provide the space to bring up/address any issues.
If you or your team is able to properly find a consistent schedule to review the sprint and keep some form of documentation, and your team is confident they can problem solve these issues during the sprint, perhaps you may forgo a meeting, and have a living document instead. However, you should err away from this solution if you think your team does not communicate rapidly and consistently over the course of a sprint.
Finding time to review successes, concerns, and failures gives the team a chance to be aware of potential issues as a group, and gives the team an opportunity to problem-solve in a group environment, giving everyone a chance to speak their mind.
Planning a Retro Meeting
Planning a Retro Meeting is quite similar to hosting any other standup or planning meeting. If you are a remote team, using tools like Google Docs or Sketch.io to collaboratively work together in a virtual environment helps bridge the gap between an in-person meeting and a virtual one.
If you are hosting an in-person meeting, try to incorporate visual aids whenever you can, retro meetings primarily work well when the data you collect is in front of your team members.
Before the Retro Meeting
When planning a retro meeting, try to keep the retro near the end of the completed sprint or the start of the next sprint. This timing allows people to best remember what has happened during the sprint, and allow everyone to consider what to repeat and not to repeat during the next one. You may also set up a feedback form over the course of the sprint to allow less talkative members a chance to place some issues that could help shape the context of the retro. This also allows team members to anonymously bring up issues that they would otherwise be too uncomfortable bringing up.
Make sure to collect data about your previous sprint(s) as well. Any data about task completion and absences during the previous sprint. The more data you have, the better you will understand the median task completion rate of your team and better gauge when a sprint was effective or ineffective.
Try and set up a retro board to allow ideas to be organised and represented in a modular structure. It can be physical or digital, but it should be in place during the meeting so that team members can have a visual aid to look towards when summarizing the good and bad that happened during the sprint. Feel free to use one of the templates as an idea on how to set up your board.
As a bonus, try to have an ice breaker set up so that people can start off with a lighthearted discussion. The best way to induce people to speak their minds is to bring up a topic everyone is interested in. Maybe have a silly question that everyone can answer, like have them compare the sprint to a random object, person, or time period.
During the Retro Meeting
During the retro meeting, try to get your team members talking. It doesn’t have to be at the very start, but try to get them warmed up to speak. A retro is a team effort, and requires all members to be willing to have some degree of input on the topic. Use an ice-breaker, or try and have the team do a light activity, like a single round of Oictionary. Try to play to your team’s strengths and have them enjoy the process.
Once the team is warmed up, start to introduce the data points you collected. Present to them the number of tasks completed, and ask them for a progress report for the goals your team created for themselves during the sprint.
It is important during the sprint to provide visual aids and concrete numbers to help members get an overall feel for what happened during the sprint. Get people to summarize what they see, and try to get them to summarize the overall tasks they feel were done. Though it may feel unhelpful, it forces your team to think about their progress and tests them on whether they are properly staying up to date with the project and aligned with the goals they promised themselves.
Once tasks and project goals were discussed, open up the meeting for discussions. This should take up the bulk of your meeting. Ask the team what went wrong during the sprint? What went right? If you have comments and concerns that were brought up before the meeting, introduce them to the team and ask if any solutions can help resolve them. Always look to get context about any issues, however, as making assumptions can easily lead to miscommunication and misunderstandings.
Remember that interpersonal conflicts are a delicate subject. In the context of a retro meeting, a good rule of thumb is to keep the conflict to a separate, more private meeting if the subject matter is sensitive, or should not involve all members of the team. Be sure to cut off discussions if they seem to be devolving into full-blown arguments. For example, if someone is not completing their work, and the other group members are bringing this up, it is a good idea to leave the topic outside the retro, and have a team lead talk to them to get a better sense of the situation.
If you have any issues or concerns brought up from previous retros, now is the time to ask the team whether any if anyone has a potential solution that could help alleviate those issues.
Don’t forget to celebrate any successes that occur, no matter how small. It’s important for the team to understand what was done that was successful, so that those actions can become reproducible!
Issue Example
For example, say that PRs tend to take a long while to be reviewed and completed, ask the team if there were any concrete examples of PRs that were up for a long time. Ask them the context behind that PR; Why was is up for so long? Was there someone responsible for reviewing it? Were there issues with that PR? Did team members know that there was a PR?
Have the team come up with quick ideas to solve this problem? Is there a communication problem that needs to be addressed? Is there a problem with the way PRs are being reviewed? Are there not enough people taking time to review the PRs?
The important thing is to look for solutions that work best for your team. There is never a solution that works for every team. For this example, sometimes people need to be randomly assigned to a PR, other times, people need to promise to carve out time to address a PR. Sometimes, it’s just an etiquette review to help people figure out the right and wrong way to go about reviewing a PR. Have your team discuss what might be causing an issue.
Make sure that you allow time for problems to be addressed, not a single problem. It is the person leading the retro’s responsibility to table any discussions that should be addressed in a separate meeting. Though retros are meant to do so, sometimes problems are large enough to warrant their own separate meeting.
Wrapping up the meeting
Make sure that you give the team a chance to discuss any problems and to have them aware of them. Record any problems or issues, and their potential solutions. They should be brought up again during the next retro to see if any effort was made to address them. It is a good idea to keep this data in a living document, so that team has access to this information.
Key Takeaways
- Retros are a group effort! Everyone should be aware of what happened during the sprint and be willing to problem-solve!
- Try to host meetings for your retros within a few days after your previous sprint
- Gather information and important data points, like task completion and absences
- Get your team members to summarize what happened over the sprint
- Log any issues and successful ideas that hindered/aided task completion. Be sure to note down things to consider for the next sprint and have them on hand for the next retro.