Stephen Turner
Akash Kumar
Jordan Lee
Taylor Scott
How to run a retrospective that leads to a useful change
A retrospective is a meeting where a team looks at how it worked and picks improvements to try. Leave with one specific change, someone to drive it and a date to check what happened.
What is a retrospective for?
A retrospective looks at how the work happened: handoffs, communication, tools, expectations and decisions. Hold one after a project phase or any real stretch of shared work. Use it to keep what helped as well as fix what didn't.
In Scrum, the Sprint Retrospective is a defined event for improving quality and effectiveness. It ends the Sprint and lasts at most three hours for a one-month Sprint, usually less for shorter ones. The agenda below is a suggestion, not a required Scrum format.
Start with things people can look at
Choose the period you're reviewing and send a short invite explaining why. Bring a few concrete examples: a late handoff, a checklist that helped, a decision that had to be revisited. Ask everyone to add their own, including what went well.
Describe events, not verdicts. “The reviewer got three requests on delivery day” is easier to explore than “review is always slow.” Some incidents need a private conversation instead. Don't promise anonymity when the details make someone identifiable.
- Review the last experiment before choosing a new one.
- Give people time to write before they speak.
- Discuss work and its effects, not people's intentions.
A 45-minute agenda you can adapt
This suits a small team with a clear period to review. Adjust the timing to your group. Keep the notes on screen and let people correct how their points were summarized.
| Time | Activity | Useful output |
|---|---|---|
| 0–5 minutes | Review the previous change and set the focus | A shared starting point |
| 5–15 minutes | Write observations, then compare them | Examples of helpful practices and friction |
| 15–25 minutes | Explore one recurring pattern | A plausible explanation and remaining questions |
| 25–40 minutes | Choose a small experiment | A specific change and an owner |
| 40–45 minutes | Confirm follow-through | A review point and a record everyone can find |
Turn a recurring complaint into an experiment
Say a design team's reviews keep arriving too late. “Communicate better” gives nobody anything to do. Instead, try this: before booking a review, post the request with the decision needed, a link to the draft and the latest useful reply time.
For the next two review cycles, Sam checks that each request has those three things. At the next retrospective, the team asks whether reviewers had enough context. They also check whether missing information still held things up.
Keep the change small enough to try. If the team can't control the dependency, find out who can and what evidence they need. Assigning someone to “fix another department” sets them up to fail.
Make room for different explanations
Two people can see the same workflow differently. A designer sees a slow reply. The reviewer sees a request that arrived before a key detail was ready.
Write down both before choosing an explanation. You may need another example before changing the process.
Vote on what to discuss only if it helps. A popular complaint isn't automatically the cause, and a quiet minority may hold key evidence. If a change affects someone outside the room, involve them before calling it agreed.
Check what changed, then decide what to keep
Record the problem, experiment, owner and review date where the team tracks work. At the check, first ask whether the experiment actually happened. If it didn't, find out why and adjust the plan.
If it did, look at real examples. Did the new request answer reviewers' usual questions? Was it too much effort to keep up? Keep, change or drop it based on what you learned.
Atlassian's retrospective play agrees. Turn insights into action items, give each an owner and a deadline, and keep the focus on improvement, not blame.