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:
- What is going well
- What areas could be improved
- 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
- Generate the Insights using Brainstorming
- Decide What To Do as a Agile Team
- Close the Retrospective hosted by the Scrum Master or PO
- Agile Sprint Pre-Mortem (Rule Setting, Failure Analysis)
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
Round robin where people give 2 sentences on what they want to get out of retro
Get people give their opinion on each pair of words ie. Conversation vs Argument, Understanding vs Defending
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:
The team creates a timeline of the iteration highlighting any milestones, issues occurred during the iteration.
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
Team discusses what went well during the iteration.
Team uses a histogram to demonstrate satisfaction for particular parts of the iteration.
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:
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
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.
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:
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
The team members express appreciation to each other.
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