Customer Traction

Reading Time Time to read: 6 minutes

How to run an effective retrospective

Alex Williams

Front-end Developer @ Forward Partners

A retrospective is essential for helping your team learn and improve as your product evolves. It is also a great opportunity to celebrate recent successes, and is indispensable in helping you identify frustrations within your team, resources they may be lacking, and blockers to your team’s progress.

Key takeaways

  • Set the context and the tone of the retrospective;
  • Write down your successes, what you learned, and your frustrations on a whiteboard;
  • Group these ideas by topic and assign actions to team members;
  • Don’t forget to follow-up with what’s been fixed the following week.

To run an effective retrospective you should: set the context and the tone, discuss ideas with every member of your team, group these ideas, and make a plan of how to follow-up.

Set the context

Retrospectives are normally undertaken at the end of each sprint. In many startups a sprint is a two week period of time where a product feature is designed, built and released. Longer retrospectives should also be undertaken at the end of every project. Retrospectives can also be done after each major product release. However, this is less common and can be replicated by having regular end-of-sprint retrospectives. At Forward Partners we use two-week sprints. The sprint ends on a Friday, whereby the afternoon is set aside for a retrospective and time for planning the next sprint. After a company reaches a significant milestone we also undertake a project retrospective. It is important to set the context for each type of retrospective. End-of-sprint retrospectives should focus only on the previous sprint (e.g. the last two weeks). It is primarily focused on what can we learn and improve from the last two weeks. This being said you should make time to celebrate successes within the team. If there was a particularly good design choice or user feedback session, highlight it here. Focusing on what we learned shares knowledge within the team. Focusing on what we can improve allows frustrations to be identified and fixed. With an end-of-project retrospective the team should talk about the general trends of the project and should look for lessons learned.


Set the tone (aka Following ‘the Prime Directive’)

Having identified the context for the retrospective, don’t forget to set the tone. While celebrating your successes and sharing what you have learned, often retrospectives are an opportunity for team members to express their frustrations. This can be with a process that’s failing them, or a person that is hindering the sprint. For a team member to feel secure in expressing their frustrations you need to set the tone of the conversation. The tone you want to strike is best described by Norm Kerth and is referred to as ‘the Prime Directive’:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

- Norm Kerth, Project Retrospectives: A Handbook for Team Review This catch-all sets the tone for the retrospective. Everyone is free to express their frustrations as long as they are based on this premise. From this position your team can have a frank discussion about the last sprint.


Optional Extra - Warm Ups

For small teams (which is typical of most startups) a warm up activity is not needed. Team members know why they’re here and they know each other. With larger teams, or new teams, it can be difficult to stimulate conversation and so a ‘warm up’ activity is a good place to start.  If you are looking for practical suggestions for great warm up activities then have a look at Fun Retrospectives.


The Retrospective

You’ve set the context, and the tone. Everyone knows each other and conversation is ready to flow. Now we move on to the main event. At Forward Partners our end-of-sprint retrospective start with dividing a whiteboard into four columns titled:

  1. Loved;
  2. Loathed;
  3. Learned; and
  4. Lacked.

You can choose a variation on these titles, however the idea is to have four columns that help you identify:

  1. contributions to the team that people loved (e.g. a great new design, or a successful user testing session);
  2. problem areas that the team loathed (e.g. slow internet prevented timely deployment);
  3. skills that people have learned (e.g. how to implement a new growth strategy); and
  4. key resources that were lacking, (e.g. photos for the new product page design).

With these columns on the whiteboard, invite your team members to write topics on post-its and stick them in the corresponding column. You’ll find that some people write a few, while others come very well prepared. A good facilitator should make sure that those with less to say are not drowned out. You can achieve this by waiting for everyone to stick their post-its on the whiteboard before moving around the room and asking each individual to read out, and comment on, their points. Allowing each team member to comment on their own topics will prevent less confident team members from feeling left out or being ignored. It is the core function of a retrospective that every team member needs to feel heard. This can work really well in a small team (less than 10) but with a larger team it can prolong the retrospective into a second hour. This is not to say that this is not valuable. Time spent in a retrospective is valuable for celebrating the team’s successes, sharing knowledge within the team and improving on how the team functions.


Filtering your ideas

Your whiteboard is now a collection of coloured squares, and team members have taken you through the reasoning behind their points. It is now time to filter these into clusters of similar topics. This is best achieved by asking for help from your team. In a large team you can ask for volunteers to help you sort the topics, however in a smaller team this can be done as a group. This is an essential part of the retrospective because it begins to move ideas about how the team can improve and more importantly any frustrations towards a state where they can be actioned. You will quite quickly find that there are several key areas that appear, with a few outliers.


Assigning actions

Without assigning actions a retrospective can become too focused on what we celebrate or conversely what problems exist within a team. Neither is ideal. A good retrospective needs to find a balance between what needs to be celebrated, what the team has learned and what the team needs to improve. The key to making your retrospectives productive is to take note of each cluster of issues, discuss with the team how it can be addressed and then assign a team member the task of following-up. For example, a team member could share that they learned a more effective way to interview users, and an action could be for that to be recorded in a place that is accessible for the whole team. This helps to give ownership to important issues and prevents the responsibility for following-up on all of the issues falling on the facilitator (or more often, the founder). It is important to record who is taking ownership of specific problems. This can be simple if you are using project management software such as Jira which will provide you with a template for collecting notes from a retrospective. However, it can also be done very simply and distributed over email. The key is that each team member knows what they are responsible for, so they can feedback on the issue during the following sprint’s retrospective.


Next Retro - Checking on what’s been done

Another sprint has come and gone, and before we set the context and the tone, and move to grab a handful of post-its we need to follow-up on what has been done from last sprint. Hopefully problems have been removed, blockers unblocked and frustrations resolved, but if a team member hasn’t been able to fix a problem this is a time to bring it up. From here it’s time to refocus on the current retrospective. Celebrate recent successes, share what you’ve learned and work out where you can improve going forward.

Useful Links & Resources

Alex Williams

Front-end Developer @ Forward Partners

Front-end developer for Forward Partners. Helping our companies build a scaleable and maintainable codebase.

Apply for Office Hours

We’re looking for great entrepreneurs with great ideas.

Apply here

Similar Guides