In this meeting, which is facilitated by the scrum master, team members reflect on the last sprint to identify what went well and what can be improved during the coming sprints.
This document helps you as a scrum masters conduct more successful retrospectives using the Heartbeat approach, it highlights what is Heartbeat retrospective, how a typical heartbeat retrospective meeting looks like, and what are the important characteristics of this type of retrospective.
What is Heartbeat Retrospective?
Heartbeat Retrospective (HR) is a relatively new type of Retrospective meeting presented by Boris Gloger in 2007. Gloger was aware that mistakes lead to frustration and frustration prohibits learning. As retrospectives main purpose is to learn from our mistakes, Gloger suggests a six-steps retrospective he called ‘Heartbeat’.
If you are a scrum master than you have definitely experienced blame in some retrospectives, and you are aware of the negative impact of blaming on your team and on the learning process. The first directive of Heartbeat retrospective is to settle a ‘No blame ground’.
“Norman L. Kerth” perfectly settles this ground in his famous quote:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
As scrum master you need to make sure your team is fully aware of this first directive before starting the retrospective, and you need to make sure you keep the purpose of this meeting all meeting long: that is for the team to learn from mistakes and not to blame anyone.
This will make your team members feel secure and speak freely about problems.
Set a timeline on the board for the sprint days. If your sprint is 1 week than set the weekdays on the board. Ask each team member to write facts that marked him/her the most during the sprint (this can be related to work or not). Encourage each person to share these loudly with all the other members and post them on the board at the specific day where they happened.
This will form the “Team History” from and will help remembering what happened during the sprint with all team members.
After going over the “Team History”, ask your team: What went well?
Each team member writes what he/she thinks went well, and puts the notes in the center of the table.
You as scrum master you need to organize the notes (by grouping similar notes in one group) and put them on the “what went well board”. You can simply set a part of the board for the “what went well” notes. You can then go over all these notes to share what went well with all team members so they can catch these positive experiences in the process and apply them in the next sprint.
At this stage, you have your Team History and the “What went well” experience visible. You ask your team: What could be improved?
Each team member writes down “what he/she thinks could be improved” and puts it in the center of the table (each item needs to be written on a separate sticky note). You as scrum master organizes the notes (by grouping similar notes in one group) and put them on the “what could be improved board”. The “what could be improved” board is a two columns board, column one is titled “Control inside the team” and column two titled “Control outside the team”. More details are available in section 5.
Each circumstance in life could be in my circle of control or outside my circle of control. When driving my car for example: the traffic on the road, the weather conditions, and the snow falling are outside my circle of control, however the car itself and the heater in the car are in my circle of control. The same applies to all actions / impediments that one would face in the day today work.
To get back to your team’s retrospective, draw on the board two columns, the first column is titled ‘Control inside the team’ and the second column is titled ‘Control outside the team’.
For each note or group of notes, you and the team should identify who is in control: the team himself, another team, a manager…? Stick the note then in the corresponding column.
You will get in the first column a list of items that the team can improve and in the second column a list of items that are outside the team’s control. This will help your team to focus on resolving or improving the items they can work on instead of wasting energy on items outside their control.
If the list of items is long and cannot be addressed all in the next sprint you can ask each team member to vote for the most important two items on the list and therefore you will get the highest priority items for all team members.
For each of these items the team needs to create a story and add it to the backlog so that it can be part of the coming iterations.
Now your team has identified the main items that need to be improved, it is clear what are the items that your team can control, wrote a user story for each item, and added these stories to the backlog. At this stage the team will negotiate these stories with concerned people (Product Owner, Business Owner) in order to prioritize them in the backlog and push them to the next sprint.
• Time: Heartbeat Retrospective should be time boxed to 90 minutes maximum. It should occur at the end of each sprint. Each sub activity (example: “what went well?” should also be time boxed to 10 or 20 minutes depending on the activity itself.)
• Place: HR should be done in a dedicated room, so for the team not to associate any hard feelings or frustration that might arise with the current team room. And to allow the team to freely talk.
• Items needed: make sure to have sticky note, pens and a board or a flip chart.
• Attendees: The team decides on who is welcome to attend this meeting and invites them.
• Atmosphere: Trust and No Blame are the key characteristics of a Heartbeat retrospective Success.
A successful Heartbeat Retrospective starts with trust and ends with learning. As a scrum master you need to establish a no blame atmosphere, help your team draw a history, capture what went in the sprint, encourage your team to be truthful in determining what could be improved, acknowledging responsibility, and learning from past mistakes. Finally make sure the talk is translated to stories in the backlog to get executed next sprint.
Article written by Joanna Khoury an Agile Scrum Master, Agile Product Owner and Product Manager at Ayna Corporation , and Youssef Zaki Certified Scrum Master and Certified Product Owners at Ayna Corporaiton.