The Agile Retrospective

The retrospective meeting is the primary time at which new improvements are considered and prior improvements are assessed. On Scrum projects, the sprint retrospective is held at the end of the sprint, after the sprint review and prior to sprint planning for the next sprint.

The purpose of the retrospective is to inspect how the sprint went, generate improvement ideas, evaluate improvement ideas that have been implemented from prior retrospectives, and create a plan for implementing improvements in the next sprint. The Scrum Master facilitates the meeting, and the whole Scrum team participates.

The general flow of the meeting follows this sequence:

1. Set the stage. Suggest an improvement mindset; remind everyone to focus on fixing the system. One organization begins each retrospective with a joke, which sets a tone of decriminalizing errors and psychological safety.

2. Gather input; create a shared pool of information.

3. Generate insights; look for patterns; look for root causes; review the big picture.

4. Decide what to do; identify experiments to be conducted by the team; create an action plan.

5. Close the retrospective, including reviewing how the retrospective itself could be improved.

The focus of the retrospective can be on any areas that could improve performing during the next sprint, including:

• Processes and practices

• Communication

• Environment

• Work products

• Tools

The retrospective is time-boxed. A typical length for a 2-week sprint is 75 minutes.

Teams vary in their perspective on whether outside participants should be allowed to observe or participate in retrospectives. Management can always review the improvement plans that emerge from the retrospective, but I believe that maximizing candor within the retrospective itself is more valuable than allowing outside observers.

Allow time for changes to take effect

Current Scrum practice is to ensure that each retrospective results in at least one change being made in the next sprint. The effect of that change is reviewed at a future retrospective, and it is either retained or discontinued. Changes can go into the product backlog and be scheduled as future sprint deliverables.

The desire to keep a team from becoming complacent is sensible; however, I think the practice goes too far. It should be balanced against the need to measure the effects of each change. Too many changes introduced too quickly will obscure the effect on velocity.

Allow time for the environment to stabilize around any changes so that you can understand the effect of each change. Changes sometimes introduce an initial productivity drop before improving productivity, so allow for that.

Review of story point assignments in retrospectives

Story point assignments are not changed after they have been assigned, but they can be reviewed during retrospectives. If the team agrees that a story’s as-built size was within one Fibonacci number of its assignment (e.g., it was assigned a 3 but turned out to be more like a 5), the assignment is considered to be good enough. If the assignment was off by more than one, count it as a miss, and track how many stories missed.

The number of misses can be used as an indicator of whether the team is doing sufficient backlog refinement prior to assigning story points, whether it is decomposing stories sufficiently, whether it is discussing stories thoroughly enough during sprint planning, and so on.