Successful Sprint Retrospectives: Tips and Tools

A sprint retrospective is a brief collaborative exercise that teams can do at the end of each sprint—typically as part of the sprint review meeting. Its purpose is to reflect on what happened during the sprint with the goal of improving the team, but there are other benefits, like building team chemistry, sharing knowledge, promoting a sense of team ownership, and having fun.

This post covers what’s involved in a sprint retrospective, touching on some “dos and don’ts” and sharing a few software tools that can make them easier—especially for remote teams.

What’s in a retrospective?

Sprint retrospectives start with a brainstorming session, where each team member is asked to brainstorm some ideas and put them into three to five categories. The simplest and most common breakdown of categories falls into these three areas:

• Start: Things we (as a team) should start doing. Example: Let’s get a CI server set up to run out tests automatically after every push.
• Stop: Things we should stop doing. Example: Let’s stop using untranslated strings in our user interface.
• Continue: Things that have gone well that we should continue doing. Example: Let’s keep pairing on stories!

Team members will take a few minutes to think of ideas for each category and write them down on sticky notes. The notes are put up on a whiteboard in the correct category. After all the notes are up, the meeting’s leader should group similar ideas (it’s common for team members to have similar insights) and organize a vote. Each team member gets a certain number of votes, which they can use to pick the sticky notes they most strongly support.

After voting, the notes with the most votes are collected, and the team has a brief, open discussion about each of them. This is an opportunity for people to reflect on the previous weeks, share knowledge, come up with ideas for improvement, and just vent or joke about what happened. Ultimately, the discussion should result in some action items for process or technical improvements that can be implemented in the next sprint.

For example, at a recent retrospective, the team identified a lack of role clarity as the source of ongoing tension between a developer and the team’s lead architect. The architect was making PR review comments that sounded like optional suggestions to the developer, when he really wanted the code to be written a certain way. As part of the retrospective, we recognized that the team’s lead architect has the final say, and he may need to step in and dictate a direction. We agreed as a team that, in these circumstances, he would use a #required hash tag (sparingly!).

Planning a Successful Retrospective

Things to Do

1. Cultivate full participation. Everyone needs to have a voice. Using a web-based software tool to anonymize the brainstormed comments can make this easier.
2. Create actionable items at the end (even if it’s just affirmation of the “Continue” category of items).
3. Track and review the previous round’s actionable items during each retrospective.
4. Appoint a leader to keep the meeting on track and take notes. The leader is also responsible for saving materials/action items that come out of the meeting. Again, software tools can help with this.
5. Have fun! A few jokey brainstorming ideas add levity and reinforce team in-jokes and camaraderie.

Things to Avoid

1. Blame and recriminations over what went wrong. It’s essential to discuss the bad with the good, but all team members need to feel safe in the conversation. It is not okay to focus blame on individuals. To get a good, honest result out of the meeting, team members must be treated kindly and with respect.
2. Distractions that take focus away from the task at hand. Respect people’s time. Some jokes and project discussion outside the realm of the retrospective are acceptable, but the leader of the meeting needs to get the team back on track if they deviate too far from the agenda.
3. Retrospectives that last over an hour. You’re doing it wrong.

Helpful Software Tools

While the most common tools for running a sprint retrospective are probably a whiteboard and some sticky notes, there aren’t practical when some members of the team are working remotely. Also, there can be benefits to anonymizing the feedback. Here are some tools I have used during recent sprint retrospectives:

GroupMap is the tool I’ve used most for sprint retrospectives, though it supports many other types of collaborative meetings. It has an intuitive UI, support for saving and tracking previous meeting results, and many built-in “demo maps” (pre-designed ways to organize meetings). The demo maps include the common retrospective activities. Once a meeting is started, maps can be organized into distinct steps, as in the above screenshot. GroupMap is a paid service, but it has a free trial tier.

Retrium is another highly polished sprint retrospective tool. It has a clean UI and is focused entirely on sprint retrospectives. As you might expect, Retrium also has the most common retrospective workflows built-in. One intriguing feature of Retrium is its ability to create and track what they call “action plans” that come out of the meetings. That alone may be worth the price of admission.

PinItTo.me is a free, virtual, infinite corkboard. It doesn’t have the bells and whistles of GroupMap or Retrium, but you can save past boards. One way I’ve seen it used is to pin notes corresponding to the brainstorming categories in different regions of the corkboard, then allow team members to add their own notes. The trouble with this more free-form approach is that it requires extra effort from the meeting leader to organize cards in the virtual space—but you can’t beat the price.

Those are some tools I’ve used in the past, but a quick Google search will uncover dozens of others. I’d love to hear what has worked best for you!