ARTICLE
Retrospective Meeting Agenda: Choose One Improvement to Test
Tapquence Editorial
·
3 min read
Editorial week of
Prepare a useful conversation
01
Purpose
What should the meeting produce?
02
Input
What must participants prepare?
03
Outcome
Which decision or next step is needed?
KEY TAKEAWAY
A retrospective should lead to a testable improvement and a review, not a long list of unowned intentions.
A retrospective meeting agenda helps a team learn from a period of work and choose a small improvement to test. It is different from a status meeting: the goal is to examine how the work happened, not simply report what was delivered.
Prepare a structure that gives people time to think, makes observations concrete and ends with an experiment the team can review later.
1. Define the period and purpose
State what the retrospective covers: a sprint, project phase or particular collaboration. Ask participants to bring examples rather than broad judgements. “The handover missed the acceptance criteria” is easier to discuss than “communication was bad”.
Agree how notes will be used. A candid discussion does not automatically need a full recording. If you propose recording, explain the purpose and agree the approach before starting.
RETROSPECTIVE AGENDA
Adapt the timebox
Scope and purpose:
1. Gather observations independently
2. Group related examples
3. Explore the most useful theme
4. Choose one change to test
5. Confirm owner and review point
What notes will be shared?
When will we inspect the experiment?
2. Gather examples before choosing solutions
Give participants a short opportunity to write their observations before the group discusses them. This helps avoid having the first confident speaker define the whole agenda.
Group related examples and ask what made the outcome more or less likely. Separate an observation from an interpretation. A missing document is observable; a claim about somebody’s motivation may not be.
Make the discussion specific
Broad judgement
Concrete observation
Handover was poor.
The receiver did not have the agreed acceptance criteria.
Reviews are slow.
Two reviews waited three days for a decision owner.
We changed everything.
The priority changed twice without updating the shared plan.
3. Choose one useful experiment
Select a change small enough to try during the next period. Describe what will be different and what evidence would suggest it helped. Avoid leaving with ten vague improvements that nobody owns.
RETROSPECTIVE EXPERIMENT
Fictional example
Observation
Two handovers omitted acceptance criteria.
Change
Add a criteria link to each handover note.
Owner
Sam will prepare the shared prompt.
Review
At the next retrospective, inspect whether receivers had the needed information.
The experiment is a proposal the team accepts to test. It is not proof that the underlying problem has already been solved.
4. Keep a proportionate record
Preserve the chosen theme, the experiment and the review point. Keep personal or sensitive context out of general project notes unless it is necessary and appropriate to share.
Where an agreed recording helps, Audio Notetaker supplies audio and transcript for checking wording. Use the Notetaker guide for setup. The transcript should support the learning conversation, not replace the team’s judgement about what to record as its outcome.
5. Return to the experiment
Begin the next retrospective by asking what happened when the change was tried. Keep it, adjust it or stop it based on what the team observed. Record the decision so an unsuccessful experiment does not silently become permanent process.
Prepare the video-call environment with Meeting Mode if helpful. A quiet, tested setup leaves attention for listening to different accounts of the work and agreeing one practical change.
