There are lots of ways to do retrospectives, but as a team new to Agile or Scrum, or for first-time ScrumMasters, the below approach is simple, straightforward, and based on theory and experience. In our accelerator program, we typically use the following as the starting point and then let the teams explore and evolve the retro from there.
Recall that the primary objectives of a retrospective are to:
- Inspect and adapt how you’re working as a team (process, behavior, tools, etc.),
- Surface issues or topics that need to be discussed,
- Celebrate things that went well, and, most importantly,
- Learn as a team.
The Scrum Master in her/his role as a facilitator leads the retrospective, including format, activities, and pacing.
Setup
- Scheduling: The retrospective should be held at the end of a sprint. Scrum recommends blocking 1 hour per week of sprinting. We recommend new teams start with one-week sprints and one-hour retrospectives, though your local conditions may vary. One week sprints allow you to learn how to do retrospectives quickly and keeps the content of the retro to a more manageable amount. The ScrumMaster should estimate and schedule an appropriate time based on the team. Keeping a consistent time and length expectation, especially new teams and new facilitators is key — indicating that the retro is “optional” or “as needed” may lead to an easy excuse to not adopt this foundational Agile practice. Set yourself (and your team) up to be Agile by learning the discipline before adapting it.
- Team preparation: At the beginning of the retro, your team will have a little time to remember what happened in the sprint, so encourage your team to bring their calendars/notes/lists to remind them of what happened in the sprint.
- Room Setup: The ScrumMaster should equip the room with:
- Visual artifacts – your Kanban board and team Working Agreement
- Post-it notes for participants in the appropriate colors – we recommend the “super sticky” ones – trust us
- A pad of large, wall-size post-its
- Sharpies for all team members
- Do something human, like have neutral, positive music playing, share snacks, or bring in toys to help energize the room
- Wall Sheet Setup: At the top of the sheet, write:
- The name of the company/team
- The current date
- Draw the four boxes you’ll use for the retro, which typically looks like this:
During the Retro
Ideally, all team members are present with the ability to see the wall sheet. Any remote members should be able to see it too, and hopefully, remote members can be seen on a screen by the team members present in the room. Ensure all tech (video and voice) is working BEFORE the retro starts, and get your remote members all cued in with volume beforehand.
Start on time.
Welcome & Orient
Say hi. Be friendly. As a ScrumMaster, your team is looking to you for leadership not only in the process itself but with energy too. Welcome your fellow team members and orient them – share how long the retro will go, and remind them of the purpose. Give a brief preview of what’s ahead. Remember that a certain degree of vulnerability may be needed, and so adjust your energy to help create a positive, open, inquisitive, and trusted space. If this is your first time or your team’s first time, keep a learning attitude. You will get plenty of practice and adapt as you go.
Remember What Happened
Spend fewer than 2 minutes allowing participants to remember what happened during the sprint. Encourage them to look back at their calendars, notes, and the “Done” items on the Kanban board. Taking time to simply see what happened is often a gift to busy people who might not recognize the sheer quantity of work they have done individually and collectively, and can allow for better conversation later. Nicole likes to use
The Focused Conversation Method – based on Observation, Reflection, Interpretation, and Decision – and generally, offers her teams this time to “gather data” in a neutral way. Assist remote members by having them do the same at home and perhaps pair with a person in the room, depending on your setup. Consider either playing music during this time or keeping the room silent, so everyone is participating.
Visualizing What Went Well
- Start by choosing a post-it color for the “What went well” items
- Pass out these post-its and ensure all team members have and are using sharpies – they’re much easier to read at a distance
- Tell the group:
- “For the next 3 minutes, reflect on the last sprint and write down things that went well, things that should be celebrated, or things we learned. Just do one item per post-it, and we will collect them and discuss them.”
- Set a timer for three minutes (or so).
- The ScrumMaster is welcome to write her or his own items too.
- When time is up, ask if anyone needs more time (if you’d like, we generally recommend keeping the time box, but if you think profound or important items are being written, a small extension will be worth it.)
- Choose a person to start with. Ask them to share their “What Went Well” items, one at a time, while they hand the note to you. These should be brief – there is time later to analyze.
- Place the what went well items on the wall sheet in the top left box.
- Try to cluster them if they are similar in topic or related to each other – stacking will work well too.
- If the item is unclear, e.g. “meetings” or “support tickets,” or you think it needs further discussion, feel free to probe with:
- “Do you have an example?”
- “Tell me more about that.”
- Then move on to the next person.
- Sometimes, others will say “I had that, too,” and often we will grab those identical post-its from everyone and stack them, to see that, say, five people thought a particular thing went well.
- Use your best judgment to keep the group on track. If someone is dominating the conversation or derailing the process, bring it back. If you are a new facilitator, remember that re-focusing the conversation is a gift to the whole team and that your skills here will improve with practice.
- As the ScrumMaster, one thing you need to do is help the group get some perspective. Often, you’ll have a large list of really amazing accomplishments at this point, so feel free to point this out. For example, you might say, “That was a really challenging week, with some new things we’ve never done before, and this retro clearly shows we made some major strides this week!”. From time to time, high-fives or clapping or whatever, or a thank you to a key team member can be appropriate. Use this time to give the group perspective on their work.
Visualizing What Needs Improvement
Once you’ve gone around the room for things that went well, repeat the same process for things that need improvement.
Use a different color of post-its for this, to keep them distinct.
Most people find it easier to call out things that went well, than things that didn’t. As a ScrumMaster, your leadership, facilitation, and space-making skills will grow from these exchanges. Embrace this time as a real opportunity for your team to build trust and enjoy true learning.
Start the same way:
- Hand out the “needs improvement” post-it color
- Announce, as before: “For the next three minutes, reflect on the last sprint and write down things that need improvement, challenges we faced, or anything else the team needs to discuss in order to be better in the future. Write them down, one per post-it, and we will collect them and discuss them.”
Set the timer, but choose a different person to start with once you’re ready to collect the post-its. You’re more likely to get a vague, hand-wavy issue raised that you’ll need to probe more deeply into, so don’t hesitate to probe for more details.
Avoid letting the team talk about solutions. If necessary, redirect them back to identifying the things that need improvement. For example, “Steve, that’s a potential solution, which we will talk about next. Feel free to jot it down, but right now we’re focused on making sure we can see all of the challenges we’re facing.”
Once you’ve collected all of the post-its for this section, we usually recommend ending this with two things:
- Ask “are there any issues that didn’t get raised here? Is there an elephant in the room we aren’t talking about, that we should?” Then, remain silent for an uncomfortable 20-30 seconds. Give the team a chance to ponder, and perhaps muster up the courage to say something no one wants to say. If you know of an issue, wait to let the team raise it first. As a last resort, if no one brings up an issue that you know needs to be addressed, put it out there directly. This is where the Scrum value of “courage” is most evident.
- Put the issues in perspective. If there’s a major crisis going on, feel free to point it out in a constructive way. For example: “This was a challenging sprint. We hit a major roadblock that was unanticipated. That’s part of the world we live in, part of the job we’ve got. We’re smart people, so now we need to figure out how to resolve it.” Or, if there were few issues, feel free to compare to the “what went well” and celebrate that things went as planned.
- Keep in mind that a sprint in which something goes wrong doesn’t make it a “bad” sprint. Most likely, it’s a learning opportunity for the team that will make it better in the future. This kind of learning from failure needs to become normal, so the language you use here really matters! Keep it constructive, and focused on being better in the future!
Action Items
In most sprints, you’ll wind up with a bunch of things that went well, and some that didn’t. Now comes the hard part: Choosing what to present to the Product Owner as a critical priority that should be considered for the very next sprint, identifying priorities that can wait until some later time, and committing as a team to experiments.
This section is usually different from the previous two because they’re often responses to things that went well or didn’t.
Start by saying: “Let’s walk through the things that went well, and see if there are any action items we want to take in the future.” Feel free to call out the obvious ones, but if necessary, read them back to the group, one at a time. Usually, it’s fairly self-explanatory.
If there are action items generated, write them on the third color of post-its. Note that you’re not looking for consensus yet, just to generate plausible actions that make sense.
Repeat this for the things that didn’t go well.
Most of the time, the group coalesces quickly around solutions, especially if they’re simple challenges. Sometimes there will be multiple action items for a problem that are alternative/competing options, and often there is some kind of experiment that can be tried to learn the best way forward. If it’s a complex decision that can’t be made quickly in the retro, put them together as a single action item as something that needs to be decided.
Now, you need to go through the action items list and determine which ones the group thinks are critical priorities that should be considered for the very next sprint. To be clear, if these action items impact the sprint backlog, prioritization remains entirely the PO’s decision. This is a chance for the team to advocate that something is considered – a negotiation that may continue over into sprint planning.
These items should be moved to the bottom left of the wall sheet. Presumably, the PO is present in the room and can make the call on the fly, or let the team know she/he will think about it and decide before the next sprint starts.
Occasionally a team has a behavior or process change that emerges from the retro. These may be things that don’t directly impact a backlog nor capacity, from “Notice amount of Work In Process as individuals,” to “Use a different color on the Kanban board,” to “Turn on feature X in our tool Y.” The team may come up with agreements, such as “In the open office space, headphones on means ‘Don’t approach’ and headphones off means ‘I can chat.”
These items can be handy to add to a team’s Working Agreement.
In Eric’s experience with retros, the majority of the action items are things that can be deferred. In that case, the post-its are moved to the bottom right side of the wall sheet. The ScrumMaster transfers them afterward to the backlog, in coordination with the PO. Nicole has recently been seeing some of her teams take retro items for immediate action into Sprint Planning and iterating quickly. Keep an eye on these items and ensure the team is incorporating changes with intention.
Roll up the wall sheet, and keep it, so you can revisit it later if you need to. Take a picture of it, if you’d like, and store it somewhere that the whole team can access (a Slack channel, or a shared network drive).
Wrap Up
The ScrumMaster often has one more thing they need to do at the retro: Assess the team’s spirit. If it’s been a challenging sprint, don’t hesitate to point out something like “Team, that a rough one, no doubt, but we have a solid plan to make at least a dent in this problem. We’ve got this!” Use your best judgment as to how to read the room, but use this as a chance to bring home that the entire point of a retro is to let the team acknowledge and address issues on their own, as a team, and that’s part of what makes Agile special. There’s no need for anyone outside the team to push for improvement, the team chooses to be better next time on its own!
