Retrospectives, also known as "retros," are a crucial aspect of the software development process. These meetings either occur at the end of a sprint or a project and provide an opportunity for the team to reflect on what went well, what could have been improved, and what to differently next time. The main objective of retros is to encourage continuous improvement and to give team members the opportunity to share both concerns and praise.
Retros are flexible: different tools and formats make it easy to adapt retros so that they work well for your team’s preferences and projects. In this blog post, we list a few of our favorites.
What is a retro?
A retrospective is a regularly occurring or ad hoc meeting for a team to share feedback and discuss potential improvements to make. Retros can occur on a recurring or ad hoc basis. Many software teams hold them on a sprintly basis (typically every two weeks). Sometimes, teams hold them after certain milestones or the completion of a project. Larger teams and departments may even hold retros on a quarterly or annual basis to ask higher-level questions like “How are we doing? Where are we going? What might hold us back from achieving our goals?”
Retros vs. post-mortems
The term “retro” is sometimes used interchangeably with a “post-mortem” because post-mortems are sometimes done at the end of large projects or initiatives. However, in general, a post-mortem is typically performed after a major outage or incident. For example, a company might hold a post-mortem if its main application became unavailable for any period of time.
The term “post-mortem” also has a negative feel to it because it literally means “after death,” so many companies and teams prefer to hold post-mortems only when analyzing the root causes of a negative situation and how to avoid that situation from happening again in the future.
Retros, meanwhile, tend to be focused on reflection and continuous improvement. A post-mortem asks, “What went wrong, and how can we prevent it from happening again?” while a retro asks, “What are we doing well; what could we be doing better; and how do we level up our performance?”
Why hold retros?
Retros provide three key benefits to teams:
- Retros provide a space to review and reflect that may get lost when focusing solely on delivery and execution. Teams can then come up with solutions to problems that may not otherwise get addressed.
- Retros can create opportunities for team members to share praise and recognition.
- When done well and with care, retros can nurture team bonding and a sense of psychological safety.
Retros create space to reflect. Without retros, teams may become so focused on shipping new products and features that they develop and entrench anti-patterns. For example, maybe a product manager and the software engineers aren’t reviewing requirements together before beginning development, so the final product doesn’t meet the specifications laid out by the designer, leading to costly delays and rework. If someone brings up this tendency in retro, the whole team can brainstorm together a solution to avoid this. By taking time to hold a retro, teams give themselves an opportunity to ask questions about the team’s happiness and habits.
Retros also create a place where teammates can recognize a job well done and provide praise to teammates. If a software engineer quickly and efficiently quashed a high priority bug, someone else on the team can mention their good work—or if the product designer helped the product manager organize some user research, the PM can thank the designer.
Last but not least, when held in a psychologically safe space, retros can lead to team bonding and increased trust. Using retros to express concerns about team morale, company direction, or other conflicts can help foster a sense of belonging and closeness.
How to hold a retro
To have a successful retro, there’s usually some prep work and facilitation involved. One person might take on the role of facilitator or moderator. For regularly recurring sprint retros, team members might take turns playing the role of moderator so that the responsibility doesn’t always fall on one person. For one-off or project-based retros, teams sometimes recruit someone external to facilitate.
The facilitator’s role is primarily to ensure that
- all necessary materials and tools are prepped
- the right people are invited and can attend
- the conversation stays productive and on track
- the meeting starts and ends on time
To run a retro, facilitators usually need to take a few steps:
Before the meeting
- Select the right attendees and schedule a time: For a sprint retro, the attendees will be the team members. To encourage honesty, participation, and psychological safety, we recommend that the invite list be limited to the direct team and to exclude the managers of the engineering manager, product manager, and product designer. For project-based or team-based retros, we recommend including folks who were directly involved in the project. If key stakeholders or managers want to know the outcome of the retro (even if they weren’t directly involved), the facilitator can take notes and share them afterward. Just note that some discussion doesn’t need to be recorded: people should feel safe to share their thoughts and concerns freely.
- Decide on a tool and format: If you’re running a regularly recurring retro, chances are your team already has a process and tool they like to use. However, if you’re running an ad hoc retro or a sprint retro for the first time, you’ll need to decide on how you want to organize your retro board—whether you want to use a retro-specific tool like EasyRetro, a whiteboarding tool like Miro, or an organizational tool like Notion or Trello. (If your team is conducting a retro in-person, you can definitely use a white board, but using a cloud-based tool makes it easier to record and share any notes!)
Additionally, retros often use categories for people to add their thoughts. Some teams like Start - Stop - Continue (things to start doing, things to stop doing, and things to continue doing); others prefer 3 Ls (things folks liked, learned, and lacked during the sprint); while others have come up with their own bespoke formats! Check out the next section for some of our favorites.
- Share any materials or access to tools: If you’re using a tool like Notion or EasyRetro for your board, make sure all the attendees have access to the board. Also ensure that the columns and settings for your tool are configured properly so that the retro runs smoothly.
During the meeting
- Set expectations: Although retros are a place to share concerns or discuss what might not be working, retros aren’t for airing grievances, assigning blame, or engaging in unproductive complaining. Facilitators and moderators, especially for project-based retros, can spend a couple of minutes outlining the purpose of the retro and expectations for participants’ behavior.
- Ideate: Some teams prefer to have folks add their thoughts to the retro board before the meeting begins, while others leave space to add ideas during the meeting. Depending on your team’s culture and time restraints, it might be easier to give attendees five to ten minutes to write out their thoughts and add them to the board. (Note: some teams add their thoughts anonymously, while others add them with names attached. Each approach has pros and cons, so it’s up to what feels best to you and your team.)
- Review: Don’t skip this step! Read every card/thought/idea out loud so that everyone has a chance to hear and process what’s on the board. Asking folks to read silently makes it more likely that some cards are skimmed or skipped. It may be time consuming, depending on the number of cards, but it’s important to make sure each attendees’ thoughts are heard.
- Upvote: Often called dot voting, this approach gives each attendee a few votes (usually 3-5) that they can apply to ideas or cards. Depending on the tool you’re using, people can vote more than once for the same item. Once everyone has voted, you can prioritize discussing the highest-voted topics.
- Discuss and take notes: Discussing the top-voted items should have an important question in mind: “What concrete steps can we take to resolve this issue or make it better?” Again, the goal of retro is to reflect and realign, not to gripe. At the end of each discussion item, the group or team should have an idea of what can be done differently in the future (either in the next sprint or project) to avoid a similar situation. For example, if the team found that long cycle times for code review slowed engineers down, the action item might be to call out tickets needing review during stand up every day. The facilitator or moderator should record these action items.
- Assign action items with due dates: Each action item should have an assignee who is responsible for making sure the item is completed by a specific date. With the code review example, it may fall on the engineering manager to ensure that tickets in need of review are discussed at each standup—and the team should review at the next retro if that tactic worked at fixing the long cycle time problem. Reviewing the previous sprint’s action items and status is a key component of recurring retros.
- Share findings: Depending on your team’s comfort level and your company’s processes, you may share out the results of your retro in the spirit of continuous improvement and communicating what was learned. The intention of sharing findings is not to undermine psychological safety or make attendees feel like everything they say will be recorded and disseminated. Instead, whatever is shared to a larger group should be a succinct summary of what was discussed, decided, and learned.
Our favorite retro formats
If you’re not sure which retro format to use, we’ve outlined a few of our favorites. These formats’ categories are easy to understand and adapt for your specific purposes.
With any of these formats, feel free to add a section or category for praise and recognition. It never hurts to carve out a little bit of time to recognize a job well done.
Sprint retro formats
Our favorite sprint retro formats focus on continuous improvement and help you ask the questions: What good things can we continue doing; what new things can we try; and what things do we dislike that we can let go of?
We recommend adding a category specifically around questions: retros can be a good place to pose questions to the team when there isn’t time in other rituals like standup or sprint planning.
- Keep: Things that folks would like to keep doing
- Add: Things to include in future sprints
- Less: Things to do less often or get rid of/things folks dislike
- More: Things to do more of or more often
- Liked: What people enjoyed or appreciated during the sprint
- Learned: What people learned during the sprint (this could be a skill, something about the company, or even something about a teammate)
- Lacked: What people wished they had had, like more clarity on a project or more time to complete a task
- Start: Ideas for what we could begin doing that might help us move faster or more effectively
- Stop: Sources of negativity, unhappiness, lost productivity, or frustration
- Continue: Positive, productive, or helpful habits and activities that the team should keep doing or do more of
Project retro formats
Project retros are a little different from sprint retros because the project participants may not work together on a similar project for some time, or there isn’t a clear opportunity to apply lessons learned immediately in the next sprint. Instead, project retro formats allow you to focus on what happened over the course of the project and record takeaways that can apply to a larger team, department, or company.
The timeline format is a little different from a category-based retro. In a timeline retro, people write down events that occurred over the course of the project, place them on a timeline (usually from the conception of the project to its completion) while ranking how that event made them feel, from good to bad. The retro then discusses all the major events of the project and how it affected the project team.
Mad, sad, glad
Mad, sad, glad is similar to the timeline format but uses category columns rather than a linear format.
- Mad: Things during the project that were frustrating, got in the way, or slowed you down
- Sad: Things that drained your energy or caused unhappiness
- Glad: Things from the project that you enjoyed or made you happy
Department or team retro formats
Department or team retros create a chance to have a larger discussion of the state of the union. Where are we now? Where are we trying to go? What might get in our way? What can we do to help the team be successful?
The sailboat retro is fun in that you can draw out the boat, island, sails, anchors, and rocks to place cards where they belong within the illustration. It’s a great, evocative visual to help focus the conversation.
- Sailboat: The team (your crew)
- Island or shore: Where the team is trying to go/the team’s goals
- Wind or sails: What is helping the team move towards its goals
- Anchors: What is holding the team back or slowing it down
- Rocks: Risks or potential pitfalls to the team
Questions, comments, concerns
This is a great option for a departmental or org-wide retro if something big is changing: company direction or strategy, team reorganization, etc. This type of retro gives people the space to talk about what’s on their minds in a focused, organized manner.
- Questions: What do people want to know? What do they lack clarity around? What information would be helpful?
- Comments: What have folks noticed or observed? What are thoughts and opinions on what’s happening or might happen?
- Concerns: What are people worried about? What reassurance could be offered?
Facilitating retros is a great way to level up your management and leadership skills. To learn more about running and participating in retros, browse our mentors who can chat with you about team happiness, effective meetings, and more.