Making Sprint Retrospectives Really Effective (Part 1 of 4)

The Agile Scrum Framework is based on empirical process control and requires transparency of the process and work product, and ability to inspect so the team can adapt to help it achieve their goals.  There are several feedback loops built into the agile framework:  Continuous integration that requires multiple builds each day, Daily Scrum, Sprint Retrospective and Release Retrospective.  I presented the details of Daily Scrum in my multi-part blog recently.  In this multi-part series, I will present the details of how to make Sprint Retrospectives effective in order to get the most value from them.

Agile scrum framework delivers working software sprint by sprint; it also requires a Scrum team to improve its own agile process sprint by sprint.   The ScrumMaster of a Scrum team should facilitate the Sprint Retrospective session after each sprint.  A Sprint Retrospective is attended by the entire Scrum team (including its Product Owner), and typically takes two hours.  It should be held after the Sprint Review session in which working software at the sprint end is demonstrated to stakeholders.

The key objectives of a Sprint Retrospective are illustrated in the Effective Sprint Retrospective table shown below.  The table also shows the time needed to cover each of the five areas (designated as A through E), adding up to a total of two hours of time for an effective Sprint Retrospective session.

As indicated in the table, in a Sprint Retrospective session, it is important for a Scrum team to cover 5 areas:

  1. Reaching consensus on the Top 3 factors that worked well and the team wants to sustain them
  2. Reaching consensus on the Top 3 most problematic areas where the team wants to take specific actions to rectify the problems
  3. Understanding key statistics of the sprint just completed, and understanding the Top 3 major impediments or impediment patterns and their causes
  4. Developing a specific, measurable, achievable, realistic and time-bound action plan (hence called a SMART action plan), and
  5. Capturing the results and actions from areas A through D above in the agile tool being used, such as VersionOne, for proper tracking and closure of those actions in subsequent sprints.

With all these areas well covered in a Sprint Retrospective session, a Scrum team will be properly positioned to execute the SMART action plan in subsequent sprints to get full benefits from their Sprint Retrospective.  Without taking time-bound actions to execute a SMART action plan, it will remain a SMART plan on paper only (i.e., good in intentions, but not effective in producing the intended results or benefits).

In future parts of this blog series, I will present the nuts-and-bolts details of each of the 5 areas (A through E) shown in the Sprint Retrospective table, how to reach team consensus for the Top 3 factors that worked well, the Top 3 most problematic factors, how to present and discuss key statistics, and Top 3 impediments.

At the end of Part 4, I will make available a single file version (as a PDF document) of this 4-part blog series.

Part 2

This entry was posted in Agile Adoption, Agile Development, Agile Management, Agile Teams, Continuous Integration, Iterative Development, Kanban, Lean Software Development, Scrum Methodology. Bookmark the permalink.

5 Responses to Making Sprint Retrospectives Really Effective (Part 1 of 4)

  1. Pingback: Perspectives on Testing » The Seapine View

  2. Pingback: Making Sprint Retrospectives Really Effective (Part 3 of 4) | The Agile Management Blog

  3. Pingback: Making Release Retrospectives Strategic and Effective | The Agile Management Blog

  4. Pingback: Making Sprint Retrospectives Really Effective (Part 4 of 4) | The Agile Management Blog

  5. Pingback: Making Sprint Retrospectives Really Effective (Part 2 of 4) | The Agile Management Blog

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>