How to Perform the Sprint Retrospective

Introduction The Scrum Retrospective is only for the Scrum Team and is used to make Adaptations to the way the team works. The duration is limited to 3 hours for a 4 week Sprint.

  • Is the way the team worked and involved its stakeholder effective and efficient or can something be improved?
  • Did the team have the right tools – can efficiency and effectiveness be improve by introducing a new tool?
  • Did the team use the right development methods or are the alternative better methods.

If yes – the team create requirements in the Release Backlog and get it prioritised in order to get into one of the following Sprints in the Release.
Who will participate? The participants have the following responsibilities:

Product Owner Development Team Scrum Master Business (users) O&M Tea,
Analyse collaboration C A/R C … …
Analyse tools used C A/R C … …
Analyse processes and methods C A/R C C C
Legend: R=Responsible;A=Accountable; C=Consulted; I=Informed

What is the input? The input to retrospective is the notes from the Daily Scrum (Scrum Master), team members personal notes, the the BurnUpChart/BurnDownChart from the Sprint and anything else that the Scrum Team consider valuable for the meeting.
Which tasks is expected? The following tasks are expected:

Task Description
Analyse collaboration The analyse of the collaboration shall cover both internally in the Scrum Team. Do all team members find it enjoyable to be on the team? It is important to be honest in the feedback to the rest of the team, but also to avoid finger pointing or starting a “blame game”. Make notes of all things that was good and things that was not!
Similar the collaboration with external stakeholders to the Sprint need to be analysed for being effective, efficient and enjoyable. Especially the motivation for external stakeholders depends on how the enjoyable and beneficial they think the collaboration is seen from their perspective. Make notes of all things that was good and things that was not!
If the analysis point to something that need to be improved, then a 5 x Why root cause analysis is a good tool to identify the best improvement initiative.
When an improvement opportunity is discovered do this:

  • Briefly describe the improvement option.
  • Can the option be introduced in the next Sprint with an minimum of effort, then make note to remember it during the Sprint Planning.
  • Do it require some effort to introduce in the next Sprint, then create an “User Story” for the improvement, get it prioritised and put in the Product Backlog.
Analyse tools used The right tools can have an tremendous impact on how effective and efficient the development is by e.g. automating or eliminating steps in the manual development process.
Similar the right tools can improve the quality of the final product.
The starting point for the analysis can be to look in two directions:

  • Which steps in the development process was most time consuming – could these steps have been performed faster if they have been supported by a tool.
  • Which errors did we discover during the development process, especially late in the process. Could these error have been identified earlier or easier in the development by use of a tool?

Make notes of all tools that was good and tools that was not and where new tools might be needed!

When an improvement opportunity is discovered do this:

  • Briefly describe the tool and the implementation of it in the Sprint.
  • Can the tool be introduced in the next Sprint with an minimum of effort, then make note to remember it during the Sprint Planning.
  • Do it require some effort to introduce in the next Sprint, then create an “User Story” for the implementing the tool, get it prioritised and put in the Product Backlog.
Analyse processes and methods A fine tuned process or method is one of the most effective ways to work. Most athletes know that it is the safest way to victory. The Scrum Team therefore should consider its processes and methods and look in three directions:

  • Which steps in the development process was most time consuming – could these steps have been performed in a different way or the same result obtained with a different process/method?
  • Which errors did we discover during the development process, especially late in the process. Could these error have been identified earlier or avoided by changing the process or choosing another process/method?
  • Could the deliverable been finished faster by another definition of ‘Done’, that do NOT conflict with regulatory requirements or organisational standards?

When an improvement opportunity is discovered do this:

  • Briefly describe the improvement to process or method.
  • Can the improved/new process/method introduced in the next Sprint with an minimum of effort, then make note to remember it during the Sprint Planning.
  • Do it require some effort to introduce in the next Sprint, then create an “User Story” for the improvement, get it prioritised and put into the Release Backlog.

How shall the result be controlled? The Scrum Team should reach consensus about what to improve and what to continue doing in the next Sprint.
What is the output? The output from the Sprint Retrospective is two lists:

  1. Processes, collaborations or tools that worked fine during the latest Sprint.
  2. Processes, collaborations or tools that did NOT worked fine during the latest Sprint, and suggestions for how to improve these things.
    • There might be created User Stories for these improvement, if they cannot be made with only little effort in the next Sprint.
When can we exit? The Retrospective meeting end when the time-box of 3-4 hours expire.
Hints and Examples The …
…