A retrospective aims to change how work is done
A retrospective reviews a past period to improve the process. Its useful outcome is a clear experiment or decision, as well as a list of impressions.
An illustrative team publishes a series of materials. Texts are ready on time, but images are approved on the final evening. It is easy to say “we need better communication” at the retrospective and repeat the same story a month later. To make the conversation useful, examine specific observations and choose a change the team can test.
This is not a review of personal qualities or a public employee appraisal. If people expect punishment for inconvenient facts, a formally correct outline will not make discussion open. Start with a clear purpose and an agreement about how comments will be used.
- Blame
“The editor always slows everything down.” A generalisation that is hard to act on.
- Observation
“In three pieces, image criteria appeared after the first version.” There is a specific process to examine.
A short retrospective outline
| Step | What we do | Output |
|---|---|---|
| Set the frame | Name the period and discussion goal | Shared frame |
| Facts | Collect events and observations | A clear picture without premature conclusions |
| Analysis | Choose a significant recurring problem | An explanation that can be tested |
| Decision | Choose one change | An experiment and owner |
| Follow-up | Set a review point | Agreement to revisit the result |
Do not try to discuss every note in equal detail. If the period was busy, choose the issue with the strongest effect on work. Keep the rest for a separate conversation or further observation.
Give people time to think independently first so the first loud explanation does not determine the whole discussion. Then clarify the notes: the same word, “approval”, may hide different events.
From a symptom to a testable hypothesis
In the image example, the authors did not know what the editor considered a suitable illustration. A short visual brief before drawing might reduce repeated rework. This is a hypothesis, rather than an established cause of every delay.
- Fact
Illustration criteria were clarified after the finished version.
- Hypothesis
An early example and a stated image purpose will help avoid some rework.
- Experiment
Agree the visual concept before production for the next two pieces.
Define useful observations: how often the concept changed after the finished image, where delays arose and whether the early conversation helped. Do not promise a speed-up percentage in advance. The problem may lie elsewhere, such as an unavailable approver.
How to avoid a recurring ritual with no progress
At the start of the next retrospective, revisit the previous decision. Was the experiment carried out? What did you observe? What changes now? Starting a fresh wish list every time prevents the team from building experience.
- Choose one concrete change.
- Name someone to organise the check.
- Define the observation period or conditions.
- Preserve the original observation and expected effect as a hypothesis.
- Based on results, keep, change or discard the decision.
Abandoning an unsuccessful experiment is also a result if you understand why. Continuing an inconvenient process merely because you once agreed to try it is much worse.
Case review: materials repeatedly return for revisions
An illustrative editorial team notices three consecutive pieces returned for major rework after finished design. At the retrospective, first gather observations: when the reader's question was agreed, who saw the outline and which comments arrived late. “The authors are careless” judges people rather than explaining the process.
It emerges that the editor checked only finished copy, while the designer started before that review. Hypothesis: briefly agreeing the outline and example before writing will reduce late rework. The team chooses a two-piece experiment: the author brings the question, structure and one key example; the editor responds before the full draft begins.
Decide beforehand what to observe: did the main idea change after design, how many additional rounds of revision were needed, and did a new queue for editorial review appear? The experiment has an owner and discussion date. “Be more attentive” cannot be checked in the same way as a concrete sequence change.
At the next meeting, results may be mixed: fewer late revisions but long waits for outline responses. This is no reason to declare success at any cost. The team adjusts review timing or approval method. Preserve observations as well as the final judgement.
How to have a difficult conversation without blame
Begin with the boundary: discuss work you can change, using specific episodes. Let participants write observations independently first so the first speaker does not determine the whole discussion. Then group similar problems and choose one affecting the outcome.
When someone blames another person, ask for the event and consequences: what happened, what information was available and what was missing? Do not force public disclosure of sensitive circumstances. A conflict needing a separate conversation should not be settled by voting at a shared retrospective.
End with one or two feasible changes rather than twenty wishes. Each needs an action, owner, deadline and a criterion for deciding whether to keep or change it. Start the next meeting by checking previous agreements; otherwise, the retrospective generates forgotten promises.
Set a review date for the team experiment
Start with one task: “Agree the visual concept before preparing the illustration”. In the description, record the expected output: the reader's question, image purpose and agreed directional example are recorded for the next two pieces. You do not have to transfer the entire article into the service: keep what you will need while doing the work.
Schedule the action before drawing begins, and a separate review after two pieces are published. This gives the experiment a start and a point to discuss results.
- Create a task with a concrete action in its title.
- Add readiness conditions and the necessary context to the description.
- Choose a day and check that the work fits alongside other commitments.
Sinqly registration is free. You can also complete the article's example in an ordinary document; the service helps you return to your chosen actions.
When another conversation format is needed
An urgent operational problem should not always wait for a retrospective. Personal conflict or sensitive feedback should not automatically enter a group discussion. Choose a format suited to the situation and team agreements.
If facts are scarce, the meeting can end with a decision to collect observations rather than change the process. For example, spend a week noting which handover causes waiting. This is more useful than a confident explanation based on one vivid episode.
A retrospective ends with follow-up. Participants should understand what they will try differently and when they will learn whether it helped.
More questions to clarify
How does a retrospective differ from a report?
A report describes results and work status. A retrospective explores how work is done and chooses improvements. They may use the same facts but have different outputs.
Must it happen after every sprint?
In Scrum, it is a defined event. In other settings, choose a rhythm suited to the work; do not call an arbitrary meeting compliance with Scrum.
What if nobody suggests improvements?
Check discussion safety and available facts. Start with one specific episode or agree to collect observations, rather than demand ideas for quantity's sake.
Was this helpful?
Rate the article and tell us what was missing. Your feedback goes to the Sinqly team and will not be published on the site.
Sources and notes
- Atlassian Team Playbook: retrospective
- Scrum Guide: Sprint Retrospective
- The suggested process reflects editorial practice; it does not promise identical results for everyone.
Daily team meetings: coordinate the work without reporting for its own sake
When a team needs a short daily check-in, how it differs from a status report and how to discuss obstacles. Includes a conversation example and an asynchronous alternative.
Scrum explained: accountabilities, events and artifacts in one example
How Scrum works: team accountabilities, events, artifacts and short inspection cycles. An illustrative product example, without presenting one approach as suitable for every team.
Sprint planning: set a goal, choose the work and inspect the result
Formulate a Sprint Goal, select work the team can complete and inspect the result. An illustrative booking improvement and common planning mistakes.