How to Create a Retrospective for Education & Training
A structured procedure for facilitating team retrospective sessions that reflect on the previous sprint or program phase, identify improvements, and commit to actionable changes.
Purpose
To create a regular opportunity for the team to inspect their processes, collaboration, and tools, and to agree on specific improvements that will make the next sprint or phase more effective.
Scope
Applies at the end of each sprint or program phase, covering the preparation, facilitation, and action tracking for the retrospective session.
Prerequisites
- The sprint or phase being reviewed has been completed
- All core team members are available to participate in the session
- Data from the completed sprint or phase is available including velocity, quality metrics, and notable events
Supports compliance with the ESOS framework, CRICOS requirements, ASQA standards, and state education department reporting.
Step-by-Step Procedure
Prepare the Retrospective
Select the retrospective format, gather relevant data from the completed sprint, and prepare the session materials.
- 1.1Choose a retrospective format that suits the team current needs such as start-stop-continue, sailboat, or four Ls
- 1.2Compile sprint metrics including completed versus planned items, velocity, defect counts, and any significant events
- 1.3Prepare the virtual or physical board with the chosen format structure
- Rotate the retrospective format periodically to keep sessions fresh and prevent fatigue
Set the Stage
Open the retrospective by establishing psychological safety, reviewing the ground rules, and checking in with the team.
- 2.1Remind the team that the retrospective is a blame-free zone focused on improving processes and outcomes
- 2.2Conduct a brief team check-in to gauge energy levels and engagement
- 2.3Review the status of action items from the previous retrospective
Gather Data and Observations
Facilitate the team in generating observations and feedback about the completed sprint using the chosen format.
- 3.1Allow individual reflection time for team members to write their observations on virtual or physical sticky notes
- 3.2Have each person share their observations with the group
- 3.3Group similar observations into themes for focused discussion
Discuss and Prioritise Themes
Facilitate a structured discussion on the most important themes, exploring root causes and potential improvements.
- 4.1Vote or otherwise prioritise the themes to determine which ones the team will discuss in depth
- 4.2Explore the root causes of the top themes through facilitated discussion
- 4.3Brainstorm potential improvement actions for each discussed theme
- Use dot voting to quickly prioritise themes and ensure the team voice guides the discussion
Define Improvement Actions
Convert the discussion outcomes into specific, actionable improvement items with owners and target dates.
- 5.1Select the top two to three improvement actions that the team commits to trying in the next sprint
- 5.2Assign an owner for each improvement action
- 5.3Define how the team will measure whether each improvement action has had the desired effect
Close the Retrospective
Summarise the agreed improvement actions, gather brief feedback on the retrospective itself, and formally close the session.
- 6.1Read back the improvement actions and confirm team agreement
- 6.2Conduct a quick round of feedback on the retrospective format and facilitation
- 6.3Thank the team and confirm that improvement actions will be tracked in the sprint backlog or action register
Quality Checkpoints
Common Mistakes to Avoid
Expected Outcomes
Percentage of retrospective improvement actions that are completed by the next retrospective session
Trend in team satisfaction scores collected during retrospective check-ins, indicating whether the team experience is improving over time
Frequently Asked Questions
How long should a retrospective take?
For a two-week sprint, allow sixty to ninety minutes. Shorter sprints may require less time. The key is to have enough time for meaningful discussion without the session dragging. Adjust based on team size and the complexity of topics to discuss.
What if the team keeps raising the same issues every retrospective?
Recurring issues indicate that root causes are not being addressed. Dedicate a focused session to deep-dive into the root cause using techniques like the five whys. If the issue is outside the team control, escalate it formally to management with the documented impact.
Should the course owner or program manager attend the retrospective?
This depends on team dynamics. The course owner presence can be valuable for process improvements that involve the backlog or priorities. However, if their presence inhibits candid discussion, the scrum master should facilitate a separate feedback channel.
Want this customised for YOUR business?
We'll tailor every step to your exact operations, tools, and team structure.