Facilitating Sprint Retrospectives

A good Scrum Master helps the team identify improvements. Great Scrum Masters encourage their teams to be ADAPTIVE – George watts

As Agile organisations, teams and team members, we must constantly question what could be better to continually improve. Agile retrospectives are an opportunity to inspect, adapt and improve our way of working.  This article outlines tips on how to make your retrospectives as productive as possible.

Typical scenario

According to the Scrum Guide – The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The purpose of the Sprint Retrospective is to:

Inspect how the last Sprint went with regards to people, relationships, process, and tools;

Identify and order the major items that went well and potential improvements; and,

Create a plan for implementing improvements to the way the Scrum Team does its work.

It should always happen after the sprint review but before the next sprint planning. That’s because, if you haven’t inspected the increment and how you’re collaborating with stakeholders, then you haven’t fully inspected the sprint. This can lead to adaptations that aren’t appropriate for your situation. As far as duration, The Scrum Guide states that a Sprint Retrospective time box is a maximum of three hours for a one-month Sprint. Adjust that time box accordingly based on your sprint length.

Improvement items are fed back into Sprint backlog

As a Scrum Master, you should ask following questions more often than not as often these become the basis of the Sprint retrospective discussions.

  • Is our quality getting better?
  • Do we feel like a team?
  • Are we living the Scrum values?
  • What’s slowing us down, both technically and organizationally?
  • How are our relationships with people outside the Scrum team?

Ways to facilitate Sprint Retrospective:

1. Preparation for the Sprint Retrospective:

  • Keep a fixed time slot for the sprint retrospective meetings. Send an invite 3 days in advance to all the Scrum team members. As by nature of this meeting we don’t expect other stakeholders to be part of retrospective sessions.
  • You may prefer to choose a theme for the retro in advance. Make sure you pick different themes so that retrospectives don’t get boring and monotonous. We can pick from the following themes:
    • Working, Not working, Puzzling
    • Start, Stop, Continue
    • Good, Problematic, Significant
    • What went well, what went wrong, what needs to change
    • Mad, Sad, Glad
    • Liked, Learnt, Locked, Longed for 
Themes to conduct Sprint Retrospectives
  • It’s wise to collect data in advance for the upcoming retrospective meeting, as it gives Scrum Master some time to plan for the actual meeting by focusing on relevant details only. Following metrics can be handy during a retrospective meeting:
    • Team morale/happiness index – In my team, we conduct a team happiness survey post every Sprint review meeting
    • Team velocity – is a measure of points for all fully completed/accepted user stories.
    • Story point completion rate – Story points picked vs burnt
    • Peer feedback
    • Cumulative flow diagram – to track the progress of a Scrum team during a certain period
Team Commitment Reliability Trend
  • It is wise to send another reminder to the team members just to make sure no one misses the meeting and come prepared. You may wish to send the links of the Sprint metrics and team working agreement along with the invitation.

2. Actual Meeting: 

When it comes to the actual meeting, a friendly environment is very important. Since Sprint retrospectives are an opportunity to inspect and adapt hence the involvement of every team member is prime important. A facilitator can take care of following points while running a Sprint Retrospective meeting:

  • Ice breaker – Let me give you my example, to make everyone comfortable, we normally start the proceedings with a game, poll or quiz. If the team is relatively new then I would recommend this technique to everyone as It is important that everyone feels safe and ready to voice his/her opinion. There can be instances when team members feel intimidated especially in the presence of a Product Owner.
  • Set the context – Once you gauge the weather and mood of the team members, it’s time to come to the point. 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. It should be focused on people, processes and technology in general.
  • Begin with Previous Retrospective Action Items: If you’re not reviewing past action items, then you’re not monitoring the progress on the improvements brought forth in previous sprint retrospectives. Look for the previous retro actions prioritized and picked up in the last sprint, keep five minutes aside to review old retro actions.
  • Discussion on the current Sprint – With data/metrics already extracted, a facilitator can start the discussion based on the chosen theme for the retrospective. To facilitate a healthy discussion, keep the following points in mind:
    • There should be a balance among various categories (ex. stop doing, start doing and continue doing) of the theme and it shouldn’t be skewed in favour of one. In case all team members are voicing their opinion around a particular category then Scrum Master needs to intervene and a give direction to the overall discussion.
    • Make sure everyone participates.
    • Keep a track of time. If you find that your team tends to linger on a particular issue preventing you from covering all the topics you want to discuss in the retrospective, you may want to time-box the discussion.
    • Use techniques like 5 WHYs, Fishbone to find a root cause of a particular problem.
    • Ensure there is no blame game among team members.
    • In today’s virtual remote work scenario, we can make use of online tools. Tooling and communication technology matters – poor tooling negatively impacts the participant experience. For instance, we use a tool called ‘PointingPoker’ for our retrospective meetings and the team loves it. It gives the team a nice interface with an option to remain anonymous. We can also export the final data/actions from the tool to team Confluence space.
  • Voting – After enough ideas have been generated and discussed, have team members vote for the most important item or items. One can also pick the topmost idea from every category. Tools like PointingPoker, Mentimeter or Reetro.io give us features where team members can vote online.
An example/result of online voting
  • Outcomes/actions – Scrum Master needs to make sure that all top voted actions, improvement items are documented and action points should be assigned to an accountable person(s) who will be responsible to resolve it by the decided due date.

    Actions should be:

     Small but SMART

     Clear and understandable

     Formulated so that the benefit is clear

  • Closing – The goal of this last phase is to sum up the results of our Retrospective and generally leave a good feeling behind for the participants of the meeting. One may close the retrospective with an appreciation for the hard work everyone did both during the iteration and the retrospective.

3. Post the Retrospective:

Once the meeting is over its not all done. There are still steps/actions that Scrum Master needs to be aware of. Let’s have a look at them one by one:

  • Documentation – It’s wise to keep a record of what was discussed during the retrospective meeting. Before Covid-19, we used to take a picture of the team board (with sticky notes) and keep it safe in the team Confluence space for any future reference. These days one can make use of online tools (Mural, Reetro, Retrospected, PointingPoker, Fun Retro) which give us almost the same look and feel.
  • Product Backlog update – Create a JIRA issue with an issue type “Retro”, so that one could make out that it’s a retrospective action/story. The newly created story should be identifiable among other product backlog items. Scrum guide says we should make every effort to pick at least one retrospective story or an improvement item in the forthcoming coming Sprint.
Create JIRA issues for the retrospective actions
  • Follow-up – Once the Retro story is picked up in the coming sprint, the assignee must give an update during the daily standup on the progress of the same.


Conducting a retrospective meeting is by far one of the most valuable processes when applying Agile and has tremendous power to inspire change for the team members involved. The retrospective is a tricky meeting to learn, but an easy one to master. Facilitation is an art when done right, sprint retrospectives can be a fun exercise the team looks forward to at the end of every sprint. Are you going to try some of the suggested strategies? Do you already measure your retrospectives? What challenges do you face?

Keep Improving 🙂

%d bloggers like this: