Chapter 53. Have Sprint Retrospectives and Structure Them

Steve Berczuk

“Inspect and adapt” is pervasive in the Scrum framework; all events in Scrum serve the process of inspection and adaptation. Two of these events mark specific feedback points: the Sprint Review, during which the team “inspects” the product work in order to adapt the plan (Product Backlog), and the Sprint Retrospective, where the team inspects their process and adapts that in the next Sprint. Of all the Scrum events, Sprint Retrospectives are often given the least thought and are the least appreciated, often skipped, compressed, or organized in a way that may not provide the best feedback. They are quickly dismissed as overhead, although, ironically, if any event makes the best use of people’s time, it is the Sprint Retrospective, if it’s well organized.

I’ve been to many retrospectives that were short and unstructured, a combination that almost always ensures that they will not yield useful results. A valuable retrospective is one that captures the challenges and successes a team has and yields actions a team can perform to improve the process. Doing this requires an environment where everyone on the team feels open to participation and where the participants filter topics so that the more important ones get talked about, instead of the first ones mentioned.

Effective retrospectives have a structure and a facilitator. I like the five-part framework described in the book Agile Retrospectives (Pragmatic Bookshelf, 2006) by Esther Derby and Diana Larsen. The five parts are to set the stage, gather data, generate insights, decide what to do, and close. This framework provides a clear structure that contributes to creating an environment where people feel comfortable to actively engage and where the discussion leads to actionable items that lead to solutions of real problems.

Other approaches can also work, but effective Sprint Retrospectives always need three key elements: a way to enable engagement and safety, a way to distill and prioritize ideas, and concrete action items. I also like to end with “appreciations” so that the team understands how everyone adds value.

Opening with rituals that encourage participation and emphasize a focus on improvement rather than blame creates safety for people to raise even the most difficult challenges. Following a structured technique to gather concerns, group related ones, and decide on what to discuss helps ensure that the group addresses the utmost important issues that need addressing, rather than just having a collegial chat. And concrete action items that are doable are the best way to ensure that the team (and management) sees value in the time spent on the Sprint Retrospective.

Managers and technologists often think that capturing feedback and developing plans for change for a process is easy, especially compared to other work like delivery. Developing trust that the retrospective will produce meaningful, actionable change is hard. A good retrospective is harder than simply asking, “What’s up?”, letting people vent, and quickly moving on to the next Sprint. Having some structure helps the team focus and be productive. Building a good retrospective habit takes time. You need to commit to having a retrospective at the end of each Sprint—for a few Sprints—to give the team (and management) a chance to see that they can be valuable, which allows the retrospective to be regarded not just as acceptable, but as highly required.