01 / UNDERSTAND
What is a retrospective?
A retrospective is a structured conversation about recent work and how the team could improve its way of working. It brings together events, different interpretations and possible changes. The aim is a concrete improvement that the team can try and review.
In Scrum, the Sprint Retrospective concerns quality and effectiveness. More broadly, teams can use retrospectives after projects, workshops or other periods of work. Reviewing the process is different from reviewing the product itself.
Why use Retrospective?
Teams can repeat a difficult pattern because nobody has time to examine it while delivering. A retrospective creates that pause. It also allows people to compare experiences: a process that feels efficient to one role may create waiting or rework for another.
When to use it
USE IT WHEN
A team has enough recent shared work to discuss concrete events.
Recurring friction needs a practical change rather than another complaint.
A completed project or workshop offers lessons for the next cycle.
When to choose another method
Use Design Critique to discuss the quality of a design proposal.
Use an appropriate incident or safeguarding process for urgent harm or serious misconduct.
Do not rely on a group workshop alone when people cannot safely disagree in that setting.
What you’ll need
Define the period and invite people who experienced the work. Bring a simple timeline, relevant work records and the previous improvement actions. Agree how notes will be used and shared. A facilitator should help separate events from blame and create ways to contribute without requiring immediate public disclosure.
What the method needs
Keep the elements that help answer your question and support a decision.
The work and timeframe being examined.
Concrete moments, outcomes and conditions.
How different roles experienced the same work.
Possible explanations, with uncertainty retained.
A specific change within the team’s influence.
A signal, owner and date for examining the change.
02 / PUT IT INTO PRACTICE
How to run a useful retrospective
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Set the purpose
Name the period, intended outcome and working agreements. Review the previous action.
Ask whether the last change was tried before selecting another.
02
Gather individual accounts
Allow quiet reflection before discussion. Ask for specific events and consequences.
Replace communication was bad with the moment information arrived too late.
03
Build a shared picture
Place events in sequence and compare accounts without forcing immediate consensus.
Notice whether late feedback followed a missing review opportunity.
04
Explore a consequential pattern
Choose a pattern the team can influence and consider alternative explanations.
A delay may reflect unclear ownership rather than lack of effort.
05
Choose a small experiment
Describe the change, who will try it and what would count as useful evidence.
Try an earlier review of uncertain decisions on the next piece of work.
06
Close with a review point
Record the agreement and schedule a check. Preserve unresolved issues that need another route.
A named owner tracks the experiment, rather than carrying all responsibility for improvement.
Example: feedback arriving after the build starts
Fictional team: designers and developers report repeated late changes. A timeline shows that important constraints are first discussed after a polished design is handed over. Designers describe interrupted work; developers describe decisions they had no earlier chance to influence.
The team proposes a short review of uncertain interactions before visual refinement. For the next cycle, it would record which assumptions are resolved early and which still cause rework. The experiment is a change to the timing and purpose of discussion, not simply another standing meeting.
At the next retrospective, the team would compare the effect with the time the review consumed. The scenario does not claim a measured productivity improvement.
03 / BELOW THE SURFACE
Below the surface: agreement can hide unequal costs
A proposed improvement may help the group while adding work to the same person each time.
PATTERN
What repeated under which conditions?
Start with events rather than character judgements.
COST
Who does the improvement work?
Include preparation and follow through.
LEARNING
When will we review the experiment?
Check effects and burden together.
An early review sounds collaborative, but somebody must prepare, attend and reconcile the feedback. If that work always falls to a person already handling coordination, the solution may reproduce the original imbalance. Ask who pays for the improvement in time and attention.
Include preparation and follow through in the experiment, then check whether responsibilities need to rotate or existing work needs to stop. A team cannot indefinitely add process without removing something.
This editorial check is not a demand for perfect equality in every task. It asks whether the proposed arrangement is explicit, feasible and open to revision. Silence during the meeting should not be treated as evidence that the cost is acceptable to everyone.
Retrospective companion worksheet
The worksheet combines an event timeline with a second page for one improvement experiment. Record competing explanations, responsibilities and a review signal. It is an original facilitation aid and can be adapted beyond Scrum.
Practical tips
Begin with the previous action and what happened.
Choose fewer changes than the group can easily discuss.
Common mistakes
Turning the session into a performance assessment of individuals.
Collecting complaints without a next action.
Adding a process without considering its workload.
What you’ll get
A limited improvement experiment that the team can actually try. The next retrospective should examine its effect and decide whether to keep, change or stop it.