First posted April 2020. Updated January 2023
In Agile software development, the Sprint Retrospective, or ‘retro’, is a meeting held at the end of each sprint. The project team comes together to reflect what happened during that period, and create a plan for improvements for the next iteration.
While these types of conversations are best had in person, with a big bare wall, a bunch of Post-it notes and some Sharpies, there are lots of great tools and tips for running remote retrospectives as well. Let’s dive in!
Step 1: Why run an Agile sprint retro in the first place?
Always begin with ‘why’. Knowing what you want to get out of an Agile sprint retro helps ensure you stay on track, and means you can measure their effectiveness against the goals you identify at the outset.
We believe that retros are most effective when they are done at regular intervals while the work is ongoing. They serve as checkpoints to create space for teams to stop, inspect, learn, and adapt.
Retrospectives serve to:
- Create a safe, dedicated space to have open, candid conversations
- Build trust
- Hold ourselves and one another accountable
- Celebrate everything we’re doing right
- Share our learnings
- Identify things that don’t make sense to us
- Take an honest look at what’s not going well
- Come up with creative, tangible solutions toward improvement
- Define controlled experiments
- Follow up on action items, experiments and their outcomes in the next iteration
Step 2: identify the sprint retro facilitator
Ideally, the person who facilitates a retro should be someone who is not also participating. (Sometimes this may not be possible.)
Let’s assume you are taking on the role of the facilitator. The important things for effective facilitation of this meeting include:
- The facilitator is neutral: they are not there to push an agenda, though they may (and should) add observations when appropriate.
- The facilitator actively creates a safe space: ensuring that everyone has a voice and that people are respectful of one another (not playing the ‘blame game’).
- The facilitator respects the time boxes: they move the conversation along if the group gets stuck on a topic.
Step 3: decide which resources you’ll use to facilitate the retro
A remote retro, i.e. with people working from home, usually includes at least two collaborative online tools:
- An app or service for video calls, like Zoom or Hangouts
- A digital document or board that supports live peer-editing
The most common tools we use here at Human Made:
- Google docs (my preferred method)
- Trello (we shared our template for everyone to use)
- Confluence (has a built-in template)
- Miro
Any online tool that lets multiple people collaborate simultaneously can serve this purpose. With Trello and Confluence, the prompts are divided into columns. On a Google doc you can create sections with bullet lists.
Step 4: help everyone prepare for the sprint retro
If your group includes people who have just started working from home, make sure to give them the opportunity to familiarise themselves with the tools you’re going to use for the sprint retro. Find a video they can watch in preparation, or take a few screenshots of how to use e.g. Trello cards, mute oneself and/or switch off one’s video on Zoom etc, to help reduce potential anxiety around the use of unfamiliar technology.
Step 5: identify the retro participants
The participants should only include the immediate delivery team. That is, the individuals who are directly collaborating on a daily, or regular basis. No stakeholders or outside team members should be present, without the express permission of every core team member.
Why? Again, this needs to be a safe place to talk about potentially difficult topics. Folks need to be able to express themselves without fear of judgement or repercussions.
However, sometimes it does make sense to bring in someone to facilitate the meeting, that way all team members can participate. This person should of course be someone that all team members are comfortable with, and someone capable of remaining neutral (more on facilitating below).
Step 6: decide on duration
A retro shouldn’t last longer than an hour, although for larger teams and for end-of-project retros it might make sense to extend this by an extra 30 minutes to ensure enough time for discussion.
Step 7: set the prime directive
Before kicking off, I always mention the following (and include it in written form on the tool being used):
We are having this discussion with the goal of continuous improvement in mind. Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what was known at the time, their skills and abilities, the resources available, and the situation at-hand.
You can refer back to this if the conversation ever starts turning into a blame game – retros aren’t about blaming people or passing the buck. They are about being accountable and learning from our inevitable errors.
I’ve also come to add the following:
If you find yourself struggling to find the right words to say something, that probably means that it’s really important. I encourage you to not worry about getting the phrasing just right. Get it out there first, then we will work through it together as a team.
This came after repeatedly watching people start to type and then erase their words. Finding just the right words is not always possible, and not wanting to offend anyone is a real fear. Make it easy for people to voice the hard stuff.
Step 8: use a repeatable formula
There are lots of different ways to frame a retro. The most common, and the one I use most frequently with teams, is:
- What went well?
- What went less well?
- What still puzzles me?
And sometimes I add a fourth:
- What did I learn?
An alternative to this is:
- Start doing
- Stop doing
- Keep doing
I find this second option lacks an emotional connection that helps foster team building, but this can be useful when you really want to focus on actionables.
For long term projects, I like to shake it up from time to time. Two alternative formats I’ve found very effective are The Wish, and The Sailboat.
Step 9: begin the brainstorm
After you’ve started the meeting and read out the acknowledgement, it’s time to get all the ideas out, using the collaborative board or document you’ve prepared. I find that 7 minutes is the right amount of time for this phase.
- Encourage everyone to contribute at least one item to each column/question.
- Invite them to mute their microphones and to work in silence.
- If you see the activity waning early, you of course don’t need to use the whole allotted time – stop early.
- Give folks a one-minute warning before the time is up, asking them to wrap it up.
- At the end, ask if anyone needs more time – it should absolutely be ok to spend another minute or two to make sure all of the important stuff gets out there.
Step 10: run the vote (optional)
This is an optional step: ideally, when the time intervals aren’t too lengthy or the team too big, the group can get through all of the items in the allotted time. However, if it’s clear that there are too many to get through, then you can take a few minutes and have members upvote the topics that they feel would be the most valuable use of time to discuss.
Grant each person 4 votes. They can be added as emojis, and tools like Trello have ‘Like’ features that can serve this purpose well. People can place one or more of their votes on individual items, as long as they don’t use more than the defined quantity each. Count the votes and sort topics in each question/column by those with the most votes.
Step 11: the discussion
I often like to start with ‘what went well’ as a bit of an ice-breaker. It’s great to look at everything the team is doing well, and this column/section often has the largest quantity of items.
That said, when there are a lot of items in the ‘went less well’ and ‘puzzles me’ columns, then I’ll save the ‘went wells’ until the end. The facilitator should read the room and decide what the best approach is on that particular day.
Step 12: notes, decisions, action items
The facilitator should guide the group toward defining action and decision-making, and capture that output of the discussion. This generally falls into three categories:
- Notes: general impressions that add value beyond what was captured in the brainstorm items. The development of those topics that add clarity, meaning and different perspectives.
- Decisions: has the group agreed to make any process changes? Document these under Decisions, and keep a log to refer back to. Process is specific to each group and it is natural for it to evolve.
- Action items: these are clear tasks to be completed and should be immediately assigned to one or more individuals. If your company uses ‘P2’ blogs internally, those have built-in checklists that can be used to track the completion of actionables. Trello could be a good place to track them as well. Make sure to check off items as they’re completed, and review previous Decisions and Action items in the next meeting.
Decisions and action items don’t often manifest on their own. It is also the role of the facilitator to move the discussion toward the learning, change, action or experiment. Give the discussion ample space to breathe, then move toward the idea of improvement.
And there you have it – you’re now empowered to run your own Agile sprint retros effectively!
If you use these tips to run a retrospective with your team while working from home, let us know how it goes via Twitter, or LinkedIn. We’d love to hear from you!
Still feel like you could use some support? Get in touch to see how we can help your teams aim higher.