Agile Development

SCRUM Retrospective why is it so important

Retrospectives are probably one of the most important aspects of SCRUM practice, it helps inform a team about where they are as a team. It is not just about did we estimate correctly or did we do what we said we would, it is much more about teamwork. I have always seen it as building the first layer of a team which is trust.

The aim is to work as a team to inspect and adapt after each sprint.

Let’s start with who should be in a retrospective:

  1. ONLY the sprint team members. This includes developers, QA, Product Owner, whoever was part of the team during the sprint.
  2. The Scrummaster is there to facilitate guiding the meeting steps given below.

Next what should a retrospective meeting look like, it should be well structure, follow a repeated pattern, and with all SCRUM practices time boxed. So what would one of these look like, the following is based on Esther Derby’s book Agile Retrospectives: Making Good Teams Great which is a key reference book in the SCRUM community, and I think is a good summary. I would strongly recommend that Scrummasters and teams read this and try some of the techniques.

Set the stage

  • Welcome everyone’s participation – don’t forget this, everyone”s time is valuable.
  • State goal, approach and time allowed (~1 hour). 
  • Review and affirm the team working agreements/Code of Honor
  • Ask everyone to say ONE or TWO words (not 3 or more) about how they feel coming into this meeting… everyone says something no exceptions this is an ice breaker. 

Gather Data

  • Start with hard data. (this should have been prepared before the meeting). 
  • Using time-lines to show data helps immensely. 
  • Added data about feelings – this is important!! and a lot of people hate doing this, there are some good techniques to help with this.

Generate Insights 

  • Team Examines conditions, interactions and patterns that lead to success. 
  • Investigate breakdowns and deficiencies. 
  • Looks for risks and unexpected events or outcomes. 
  • Don”t jump to solutions look for alternative possibilities. 
  • List all the possible improvements and things to keep doing. 

Decide what to do

  • Pick one or two things practice oriented to work on in the next sprint. 
  • Don”t choose stretch goals all the time. 

Close the retrospective

  • Team should state their collective ownership of the improvements.
  • Perform a quick retrospective on the retrospective. 
  • Close the meeting decisively – call ”End of Meeting”. 

Data Gathering

Some initial data gathering suggestions:

  1. Events (Meetings, decisions, team changes, etc.) 
  2. Metrics (burndown, defect counts, velocity, etc.) 
  3. Stories (completed, refractors’, incompletes, etc.) 

The key is not to hide issues but discuss them openly so the less filtered the data the better.

What not to do for a retrospective 

  • Do No Preparation
  • Have No Focus
  • Failing to Gather Data
  • Allowing One or Two People Dominating the Conversation
  • Focusing Only on Impediments That Are Outside the Control of the Team
  • Biting Off More than the Team Can Chew
  • Choosing Actions the Team Doesn’t Have Energy For
  • Keeping a Separate “Improvement Plan” hidden from some team members

Retrospective only work in organisation where trust is established or exists, so it is essential that the entire organisation focuses on using these to improve and always approaches these from a perspective of ownership and responsibility for moving forward.