Improving Sprint Retrospectives

Eduardo Serra
CESAR Update
Published in
3 min readSep 3, 2018

--

Photo by rawpixel on Unsplash

At the end of the sprint, teams reflect their process in order to improve the way they work. Unfortunately, some of them conduct this ceremony using the basic Glad, Sad, Mad retrospective technique. Used alone, this technique has some downsides:

  • In Glad step, people usually use some generic examples to talk about good things which happened in the sprint;
  • In Sad and Mad steps, team members avoid to use specific situations which may “point” to someone on the team, worrying conflicts;
  • The actions resulted from the discussions (when created) are too broad and/or they have “team” as owner.

When teams use the same format constantly, the benefits of any technique decrease and the ceremony become boring or useless.

After being challenged to propose new ways to conduct these events, I studied how agile teams run retrospectives, and how they define and track actions from the topics raised. I’ll talk about some of those I use more frequently, but I vary when necessary.

In the beginning, I start the meeting proposing an agenda and asking the team to define a goal for the event. This helps to drive the discussions during retrospectives. I also like to review the working agreements defined by the team, checking if they want to modify any of them.

Next step is gathering data to upcoming discusses. Glad, Sad, Mad and Timeline are great techniques to collect events and situations that happened during the iteration. The first one is good because you also group events (good, bad, impacts), and the second one helps to stimulate memories of events/situations.

Once we have these data written, it time to analyze them. Patterns and Shift technique is good for this, grouping events by similarity and stimulating more deep discussions about a specific group of events which had more impact in the team (in a good or bad way). Other options are Five Whys and Fishbone, which helps to identify root causes of a specific situation.

We review what happened during the sprint, had deep discusses some of the events, and tried to find root causes… and now? Call to Action!!! One of the most powerful techniques I use is SMART Goals, which helps teams to develop Specific, Measurable, Attainable, Relevant and Timely actions/experiments in the upcoming sprint. We invite team members to get ownership of a single action/experiment, working on it as a task of the sprint, and review the results in the next retrospective. The value of work on those actions in the following sprint is to avoid to face same situations over time and also giving a meaning for a ceremony.

Closing the retrospective, as a momentum of retrospective feedback, it is good to ask team members how the session was, and which improvements should be done to increase the session effectiveness. Using a technique from Management 3.0, the Happiness Door is a good way to receive good feedback from any presentation or session, including sprint retrospectives. The idea is to use a scale from 1 to 5 (there are other examples, using pictures for instance) that represents how the team members feel how effective was the session. For those who mark as 1, it is expected a brief explanation about what was expected that it was not achieved. Even for those who choose the other numbers, it is good to receive their feedbacks. Those feedbacks are written in stick notes and clue them in the selected number. This technique is similar to Return on Time Invested (ROTI), but in this case, the facilitator will collect this feedback after the meeting.

Using Futurespectives

Photo on UX Planet

You can also use retrospectives to remind team members of the project/product vision and goals, aligning expectations and energize the team. The Hero’s Journey is an excellent technique to achieve this goal. Focus on what are the desired outcomes at the end of the project, team members analyze what are their strengths and some possible challenges ahead which they may need to track, and the end of the story is usually linked with the product vision.

--

--