Skip to main content

Retrospectives vs Post-Mortems

Retrospectives are explicitly part of Scrum. About looking honestly at past performance and making changes where needed.

Common Misunderstandings​

  • A retrospective is the same as Post-Mortem
  • Retrospectives are Product-focused
  • Retrospectives all have the same Agenda

Its Not a Post-Mortem​

A meeting after a project, to help learn from what happened Retrospectives differ is some key ways:

  • Post-Mortems occur after the project is done so theres no time to improve. Retrospectives encourage change to happen throughout to improve the final result.
  • PM are long feedback loops, once per project. Retrospectives are short feedback loops, which happen oftenly throughout the project.
  • PM often generate attractive-looking reports that are placed on a shelf and ignored. Retrospectives are only honest communication and action
  • PM sometimes turn into blame and shame events. Retrospectives offer opportunites on 'how can we' rather than 'you should have'

Its Not a Spring Review​

Seperate product improvement from process improvement. Sprint Review gives the dev team and any intrested stakeholders a change to examine the product and make decisions about improving the product. Retrospective is about team and process impovement. When a team focuses too much time and energy on product discussion, it loses an opportunity for improvement.

Doesnt have to be the same agenda every time​

If you want your retrospectives to be engaging and reveal issues, must vary the style and content.

What is an effective retrospective?​

Its a strucutred moment for the team to stop, breathe, and reflect on the past cycle. Discuss what went well, what went bad and how to improve etc. What good does it do:

  • Reminder of positive things that have happened recently in the team
  • Focused improvement goals for the system
  • Encouraged collaboration in the Sprint by collaborating in the Retrospective
  • Heightended sense of ownership of their work and process
  • Increased work satisfaction, quality, and eventually, capacity/productivity
  • Better awareness of the needs of individuals and the team as a whole.

Elements of an effective retrospective​

Well-run retrospectives provide an opportunity for small improvements and clear agreement on actions to be taken afterward.

Not focused on 'Blame and Shame'​

Need to focus on the events which happend and not the people. Not the person who caused the issue, but how it occured and what was done to get it resolved etc.

Simple ground rules​

Have rules which are behavioural vs abstract;

  • Laptops and phone away
  • Share all relevant information
  • Explain your reasoning and intent
  • Come with an open mind from all team members with a focus on solutions, not on problems
  • Jointlyy design the next steps
  • etc

Well-Structured​

Set the Stage (check-in/opening)​

Invites people to the room and frames the retrospective and reminds people of the ground rules

Gather Data​

Look back and find what happend in the spring and create a list ,dont judge people.Some of this work happens before, to collect data;

  • Team calendar
  • Number of stories completed
  • Number of new defects introduced into the system
  • Items still in progress at sprint end Its important to gather the data before the retrospective as dont have accurate/complete memories of the past.

General Insights​

Data from previous round is used to inspire the insights this round. Goal of gathering data first is to ensure the team is working from the widest set of ideas to improve from.

Decide what to do​

Before was focused on having a deep understanding of the issue. Now need to decide which actions the team thinks will be most effective for making small changes

Closing​

Opportunity for the team to reflect on the retrospective itself. Provides an opportunity to celebrate.

Who attends a team-level retrospective​

Should involve the entire team. See or hear the product owner and the ScrumMaster.

Summary​

Retrospectives are to help the team celebrate all the things that are going well, to provide feedback to the team, and to create a plan to improve the next Sprint. Should happen at the end of every Sprint. Allocate one hour for every week of a Sprint.