25 Sprint Retrospective Examples for Scrum Masters

After each release/iteration, the Scrum Master or Team Leader should hold a sprint retrospective which can also be called an intraspective. We have drafted list of sprint retrospective examples to keep the retros fresh and creative. This will help to improve methods and teamwork by reviewing the past iteration/release. There are 3 core questions that should be answered in every retrospective:

  1. What is going well
  2. What areas could be improved
  3. What should be we be doing differently

Generally, a retrospective is time-boxed to 2 hours and is based on brainstorming solutions and commit to a solution and discuss again, if success adds to the process. Retrospectives can be highly effective as they happen during development process providing immediate feedback on how the process is performing. If used correctly retrospectives can result in:

  • Improved productivity
  • Improved capability
  • Improved quality
  • Improved capacity

Esther Derby and Diana Larsen defined a 5 step process for holding retrospectives.

Set the Stage for the Agile Team

Setting the stage is all about setting the tone of the meeting and getting the team on board. Retrospectives work best when there is a lot of engagement and genuine feedback from the team. It is recommended to get people talking early by introducing themselves and their role but if the team members don’t change very often this might be seen as overkill.

Next, the Scrum Master/Team Leader sets an agenda and rules for the meeting. To increase comfort level of team members to participate in the meeting the team can play the following games

Check In

Round robin where people give 2 sentences on what they want to get out of retro

Focus On/Off

Get people give their opinion on each pair of words ie. Conversation vs Argument, Understanding vs Defending

ESVP

The team anonymously identify their attitude towards retrospectives as one of the following:

  • Explorers: eager to discover new ideas
  • Shoppers: look for useful info and happy go home with 1 idea
  • Vacationers: not interested in retro but happy to be away from work
  • Prisoners: feel like being forced to attend

The total scores are kept and the individual votes disposed of. Then the team is asked how they feel about the results.

Working Agreements: small groups and create agreements, create master list

Gather the Data by Engaging All Team Members

Next step is gathering feedback from team members on what happened during iteration. The goal is to determine a common vision of the iteration. The agile team leader is responsible for team engagement and can use the following team based facilitation techniques to get more interaction between team members:

Timeline

The team creates a timeline of the iteration highlighting any milestones, issues occurred during the iteration.

Triple Nickles

5 groups are given 5 minutes on 5 ideas 5 times

Colour Coded Dots

Team uses sticky dots to show emotions where emotions ran high/low during the iteration.

Mad, Sad, Glad

Team uses coloured cards to describe emotional reactions during iteration

Locate Strengths

Team discusses what went well during the iteration.

Satisfaction Histogram

Team uses a histogram to demonstrate satisfaction for particular parts of the iteration.

Team Radar

Team assesses performance against previous process improvement goals

Like to Like

Team recalls experiences during iteration and compares reactions to events.

Generate the Insights using Brainstorming

Once the data on the iteration has been gathered it needs to be evaluated.  The data can be evaluated using the following brainstorming techniques:

Five Why

The team works in pairs where they look at an issue and try find a solution by asking “Why?” numerous times to any reason for the issue helping determine the root cause.

Fishbone Diagram Analysis

Fishbone-diagram-template
Fishbone diagram template using Miro

Also called Ishikawa diagram it is a technique used to identify root cause demonstrated in the diagram to the left. The team draws out the diagram, each branch is one area and then within that branch are possible reasons for that branch. The diagram should have all possible causes and which area the issue came from.

Prioritise with Dots

Team uses dots to vote on what they feel is important to them.

Identify Themes

The team identifies recurring patterns in the data gathered.

Decide What To Do as a Agile Team

After the data has been evaluated and the team have the insights into the issues they must decide how to rectify them.

The technique called “circle of questions” can be used to give individuals opportunities to provide solutions where a person picks an issue and the next person proposes a solution. It is very important that any goals created to rectify an issue are SMART goals (Specific, Measurable, Attainable, Relevant & Timely).

This will help ensure the goals are achievable within the next iteration and can be reviewed after. To sort the issues the team can use an action wheel where each item is categorised simply by choosing Keep/Drop/Add or Start/More/Less.

Close the Retrospective hosted by the Scrum Master or PO

The final stage of the retrospective is formally closing it. There 4 tasks identified to close the retrospective is:

Plus/Delta

What they want to do more of and want to change

Helped, Hindered, Hypothesis

Feedback on retrospective itself giving everyone an opportunity to give their feedback.

Return on invested Time

Team grade meeting 1-5

Appreciations

The team members express appreciation to each other.

>> For more information check out this PDF extract of Esther & Dianna book 

Agile Sprint Pre-Mortem (Rule Setting, Failure Analysis)

The premortem is a facilitated agile team exercise that aims to identify the possible failures on a project before they happen. This helps the team to think long-term and visualise future change’s they might experience.

The Product Owner needs to approve any mitigation or avoidance actions before they can be added to the backlog. The steps to conducting a post-mortem meeting are below.

Imagine the Failure

  • The team brainstorms possible issues that could arise.
  • The facilitator can suggest scenarios.

Generate Reasons for the Failure

  • The team members work independently to create a list of possible reasons for each failure.
  • Example reasons would be funding removed, stakeholders not answering questioning.

Consolidate the list

  • Each person reads out one item from their list in turns and writes on the whiteboard, which prevents long monologues and encourages engagement.
  • The team works together to prioritise the list based on their opinions.

Revisit the plan

  • The Product Owner is provided with the list and has to approve the recommended actions. The Product Owner will only add what they feel is the top priority.
  • Approved actions are turned into user stories and added to backlog

Scroll to Top