How to run a team retrospective that leads to action

A team retrospective examines a completed period of work and identifies something to change next. A useful outcome is an improvement to try, with an owner and a time to review what happened. A list of complaints or a promise to “communicate better” does not yet specify that action.

Define the period and purpose of the meeting

The Scrum Guide describes the Sprint Retrospective as planning improvements to quality and effectiveness, examining people, interactions, processes and tools. What follows is an editorial scenario for an ordinary work team, rather than a replacement for Scrum’s rules.

For an illustrative example, consider the preparation of four internal newsletters. The team wants to understand why approval repeatedly started late. Limit the discussion to those issues rather than trying to address every difficulty in the department.

Explain who will participate, how much time is available and where agreements will be recorded. Clarify which notes may be shared beyond the meeting. Do not promise anonymity if the format or records allow someone to identify a contributor.

Collect observations before proposing solutions

Give participants a chance to write their observations independently first. Then compare them with the available history: when a draft was ready, when a response arrived and which requirements changed. Mark missing information separately.

“The editors always drag things out” does not explain an event. A more useful observation is “For the second issue, the request for review was sent the evening before publication”. You can use that statement to reconstruct the sequence of work.

Collect what helped as well. One issue may have proceeded differently because the reviewer was known in advance or material arrived earlier. This suggests conditions to investigate; it does not establish a cause from a single successful example.

Choose one difficulty to investigate

Group similar observations while checking the differences. A late start to a review and a long wait for a reply can look like the same delay but require different actions. Do not combine them simply to shorten the list.

Choose a difficulty on which the team can take a next step. Voting can select a discussion topic; it cannot establish the cause. If several explanations remain, use a fishbone diagram of possible causes and decide how to obtain missing information.

In the newsletter example, ask whether a reviewer was agreed before the draft was completed, whether the deadline was known and whether the document could be opened. The answers may reveal different constraints. An assessment of a colleague’s personality does not replace those questions.

Specify a small change to try

The Atlassian retrospective guide recommends turning discussion into actions with owners and deadlines. A concrete trial for our example might look like this:

An owner helps carry out the agreement; they do not assume responsibility for every possible source of delay. Identify the participation and access required from others. If a decision belongs to another department, define a specific request the team can make.

Review the outcome as well as the meeting notes

After the next issue, check whether the trial actually happened. If a reviewer could not be agreed, investigate that first. An action that was not carried out tells you little about the usefulness of the proposed arrangement.

If the change was tried, compare observations with expectations. Decide whether to keep it, adjust it or try something else. Consider differences between newsletter issues; one successful attempt does not demonstrate that the difficulty is permanently resolved.

Keep a short record of the period, observation, selected action, owner and next review. Prepare the conversation using the retrospective question collection. For a detailed examination of one completed episode, use the guide to reviewing an attempt and its outcome.