Sprint Retrospective sessions are a fantastic technique for a team to learn from mistakes and continuously improve. However, more often than not, facilitators use the same format to run those meetings, hindering collaboration and creativity.
Don’t be that person. Facilitation is about enabling great discussions to happen and it is sadly underrated. The structure provided for a meeting plays a key role in how effective it will be and how much input you will get from others. If you care about team and employee engagement, ensure there is a format that will give them a chance to speak.
In this post, we will share some techniques you can adopt in your next Sprint Retrospective. They are all remote-friendly, so they can be implemented in tools like Teamworki. Don’t forget to run an Icebreaker before the actual meeting to make it more fun!
What is it? Originally introduced as a structured format for discussing democratically-chosen topics, many consider this a possible format for a Sprint Retrospective, given it is a chance for team members to speak up about issues that are impacting / could impact the sprint, either positively or negatively.
When to use it? When there are too many ideas or potential issues to be discussed and the group wants to ensure they will be, at least, considered for the agenda.
How does it work?
- In a board structured in three columns (“to discuss” / “discussing” / “discussed”), people add items they would like to cover. They should be descriptive enough so that others would understand just by reading the cards.
- Once the time-box is over – let’s say, 5-10 minutes – the facilitator or the participants themselves group related and identical cards in common themes. That should take up to 5 minutes.
- Next, attendees vote for the items they would like to discuss. Each person has a set number of votes that can be allocated all in the same card – if important enough – or distributed across the board. 5 minutes should be sufficient.
- Finally, the top items are discussed. The facilitator can limit to a specific number of cards or simply determine a percentage (e.g. the top half). It is a rule of thumb to also time-box each discussion.
What is it? More often found in software development teams, burnup charts represent the number of work items delivered in a sprint over its duration. It can uncover high cycle times (due to unexpected dependencies, let’s say) or complex items that could have been better sliced in smaller, easier chunks (for instance, the chart would be at zero up until the last day of the sprint).
This technique would imply the facilitator sharing the burnup chart with the group at the beginning (project management tools, such as JIRA) to guide the conversation and identify opportunities for improvement in future iterations.
When to use it? When sprints don’t meet the original plan – to a point where there is frustration in the team. Another situation would be when carryover items become the norm, causing a lack of predictability over the delivery.
How does it work?
- In the beginning of the sprint retrospective, the facilitator shares the burnup chart for the past iteration with the group.
- Next up, using a board with a basic template set up (for instance, “worked well” / “didn’t work so well” / “learnings”), each member adds cards under each column, thinking about the sprint and the delivery burnup.
- After grouping and voting, similarly to the previous technique, the top cards are discussed. Based on the learnings, action items are created to hold the team accountable.
What is it? Employee morale and satisfaction can hugely influence the output of a team. Sprint Retrospective sessions aren’t only about the delivery, but also about the people doing the actual work. In this technique, team members would reflect on the past iteration and what situations affected their morale (both positively and negatively) as a way to leverage those positive opportunities and learn to mitigate the negative ones.
When to use it? When the Team Lead and/or Engineering Manager are struggling to get to the root causes of morale issues in the team while believing there’s enough psychological safety to discuss those as a group and brainstorm potential solutions.
How does it work?
- This technique would require members to “journal” their morale every day (or every couple of days) during the sprint (from 1 to 5, how were they feeling, and why). Alternatively, a tool like Teamworki can be used to log those check-ins.
- In the session, each member looks at that and logging, under “I felt great when” / “I didn’t feel good when” cards related to events in the past sprint.
- Next up, similar items would be grouped and then voted for. The top ones would be discussed and the team would come together to identify how they could better support their colleagues, creating action items to ensure something will be done to learn from that.
Do you have other to-go, non-conventional techniques for a Sprint Retrospective? Please share below, we’d love to hear from you. And if you’re looking for a free tool to run your next Retro, you are in the right place.