Conduct Sprint Retrospective

(Activity) for Tier: Sprint

PURPOSE

The Sprint retrospective is an opportunity for the team to inspect itself and create a plan for improvements generally enacted during the next Sprint. The retrospective should be scheduled to occur after and can include reflection of the Sprint Review activity. Sprint retrospectives inspect how well the previous sprint went with regards to people, relationships, process, and tools. The Scrum Master facilitates identifying opportunities for improvement and creates an opportunity plan to implement those improvements.

WHEN

At the end of a sprint following Conduct Sprint Review activity.

ENTRY CRITERIA

  • The team completed or aborted a sprint.

SUB-ACTIVITIES

  1. Review Past Retrospective

    • Welcome the team and appreciate them for investing the time in the retrospective.
    • Record attendance.
    • Review the opportunities from the last retrospective to ensure follow through occurred or impediments are addressed.
  2. Check Safety

    • Facilitate a safety check by allowing the team to anonymously quantify how safe they feel. Keep the scale small so not to overthink minor variances. Teams should understand and use the same scale. Consider the following:

      • 5 – No Problem, I’ll talk about anything
      • 4 – I’ll talk about almost anything; a few things might be hard
      • 3 – I’ll talk about some things, but others will be hard to say
      • 2 – I’m not going to say much, I’ll let others bring up issues
      • 1 – I’ll smile, claim everything is great and agree with managers

    Note

    A safety check must be non-attributable. Consider using online anonymous tools prior to the meeting for non-collocated teams.

    • Make the safety check result visible to the whole team. Acknowledge the result and decide the next steps. Don’t force an analysis of the safety issues within the retrospective. The Scrum Master can follow up with the team to decide how safety issues should be handled.
  3. Gather Data

    • List out any facts or observations discovered in the following steps. Limit the list to items the team thinks is worthy of discussion.

    • Review Facts

      • Review the sprint burn down chart to looking for symptoms that can be analyzed. For instance, flat spots tend to indicate impediments (or weekends).
      • Review the work planned for the Sprint and discuss what made it and what didn’t.
      • Review Noncompliance and/or metrics data to determine improvement opportunity discussions.
      • Discuss any additional metrics desired.
    • Collect Observations

      • Each person shares zero to two observations about the sprint. They may report things that went well, things that may need improvement, or just general observations to stir additional conversation. The team may allow for more items as time permits. Consider starting with what happened and deferring why it happened.

      Example: User Story 12345 was handed to test too late in the Sprint to complete testing.

      • Consider adorning a significance qualifier on each of the observations so the team understands how important the item is. For instance, the team may want to qualify the impact of an item as: Little, Moderate, or Very.
  4. Generate Insights

    • Rank and Select Observations

      • Query each person to endorse one or two items on the list of facts and observations. The facilitator should discourage comments and judgments on endorsements.
      • Rank the list by quantity of endorsements considering any significance qualifiers used.

    Note

    The Scrum Master should not attempt to solve the team’s problems alone but instead encourage the team to improve its process and practices to make it more effective and enjoyable.

  5. Decide What to Do

    • Conduct root cause analysis on the top one or two ranked items in order to ensure a solution addresses the cause rather than the symptoms. Use the Five Whys method for the team to identify the root cause of the problem. The exercise begins with the Scrum Master stating a problem and then asking the question “Why?” (meaning “Why did the problem occur?”). The group iteratively brainstorms answers based on direct observation.

    • Discuss potential solutions for each item selected and ensure multiple perspectives are elicited.

    • In the opportunity item:

    • Opportunities discovered in the Sprint retrospective are ideally implementable in the next sprint for quicker feedback but may also include longer term objectives.

    • Promote opportunities that may benefit the business unit or overall organization by adorning them with an “Promote” tag. This is the process group signal to analyze the opportunity for higher level implementation.

EXIT CRITERIA

  • Individuals shared their observations without retribution.
  • The team analyzed the most important outcomes reported.

SEE ALSO

Process Guidance Version: 10.4