How to Run an Agile Retrospective Step by Step

Introduction

As project managers keep pushing forward in their careers, it becomes crucial to learn from the experiences, to build on those things that work correctly, and especially to accumulate mistakes avoiding repeating the same problems all the time.

The foremost tool for dealing with repetitive problems in projects is conducting a sprint retrospective. Retro is an opportunity for scrum teams to inspect themselves and to create a plan on how to improve team-work. In practice, teams get together, sum up good and bad things from the last sprint and then vote for the pertinent issues they are going to take care of at the next sprint. And later, at the upcoming Retro, nobody can recall what they actually agreed to. This repeats over and over, and that is why people avoid participating in such events, it’s utterly frustrating.

Such an approach has led me to come up with the instruction that fights every retrospective like that. I will go briefly over the generals of each stage, but for deep insights, please follow the link of each method to read the full description.

Before I start, please keep in mind the following statements:

At the end of the meeting, you should have at least one improvement, which you take as a task for the next sprint.
The maximum duration for the one-month sprint retrospective is up to 3 hours, for the two-weeks sprint retrospective is up to 2 hours.
Do not forget that each of Retro needs to inspect the results of the previous Retro. I usually go over the list of the agreed last time actions and asking “Did we complete this?” one by one.

I’m going to be looking at two-weeks sprint retrospective (up to 2 hours). At my current job iterations last just one week, but we run the reto right after a release, usually it happens every 2 weeks.

Step #1. Create an atmosphere (up to 10 minutes)

It is important to create a good mood to engage all the team members to work. If everyone is involved at the beginning of the meeting chances that all team going to join the discussion increase dramatically. There are plenty of methods for this step. I picked up the most relevant, avoiding those that can be perceived as weird. Because usually, programmers are not willing to try funny things such as “describe strengths you performed during the last sprint by saying what kind of hero you were.”

Thermometer. Are you satisfied with the last sprint? Rate from 1 to 10.
One word. Drawing on the same metaphor, which is associated with the last sprint.
Emotions. Draw a table with three columns: “People,” “Technology,” “Processes,” and three rows: “Good,” “Bad,” “Normal.” This will help in understanding the mood of the team.
ESVP. Ask Explorer, Shopper, Vacationer, or Prisoner to understand the expectations.

Step #2. Gather Data (up to 30 minutes)

Collect data about the last sprint. It shouldn’t be any opinion or assumption, just hard facts. I’d recommend gathering some data before a meeting, such as a sprint goal and the amount of planned and delivered story points. You can mention any other important data, which has been measured (e.g. several unresolved bugs, incidents, etc.). Keep in mind there are data you shouldn’t mention, for example, how many story points were delivered by each team member, it would put the lowest scored person in an uncomfortable situation. Here are different methods for gathering data; basically, all of them work properly, but some of them are much better in different circumstances:

+ /Δ. What was good and what could be done better. A right start for teams who are trying retrospective for the first time.
Mad, Glad, Sad. Split events into three columns, use sticky notes.
Start, Stop, Continue. Split events into three columns, use sticky notes. A good choice if a sprint went well, and there is nothing to complain to.
Timeline of a sprint. Draw a chart and use sticky notes to build a complete picture that everyone knows what was going on in the sprint.
Team radar. Not an ordinary way to express the following parameters: Scrum, Definition of Done, Stakeholder Management, Mandate, Return on Investment, Quality of the Product Backlog, and Collaboration. The exact topics can change per retrospective.

Step #3. Generate insights (up to 30 minutes)

The main goal of this step is to dive deeper into one problem from the previous step and to find the root cause of it. At first, you need to decide which subject you want to select. If the problem is not obvious and the team members cannot agree, pick up several options by yourself, and make them vote. Take a closer look at the most popular methods for this step:

Step #4. Decide What to Do (Up to 40 minutes)

During this step, you need to come up with an action plan on how to deal with identified during the previous step problems and potential solutions. Now you need to decide what to do differently during the next iteration. Keep in mind to follow these statements:

Be specific. An action item should look like this: “Improve team communication by scheduling standups at 10:00 each morning from Monday till Friday.”
Planning and prioritizing of the action items should be done during sprint planning, not during the retrospective.
An action item should be small and shouldn’t last more than a day.
If you pick up too many actions, it’s likely the team wouldn’t be able to complete them all or forget about some of them.
Make all actions visible for all team members. Use sticky notes and a board that everyone can see it.
Use rating points or screening matrix, if it’s too complicated to choose action items.

Step #5. Close the retrospective (up to 10 minutes)

Now you need to summarize the results of the current retrospective and make the team feels like they achieved something useful. Here are steps for the closing:

Talk over the action plan
Perform a short retrospective or use Helped, Hindered, Hypothesis method to finalize the Retro.
Thank everyone.
Let them go.

Okay, that’s it. I hope you found these insights useful. Stay tuned and check my other articles.