Process

How We Do Sprint Retrospectives

How to do sprint retrospectives

Table of Contents

Share this article

At Hivekind, we value Agile and practice Scrum. A notable cornerstone of the Scrum process is Sprint Retrospectives. Here we take a look at how we conduct these and why they’re so important to us.

The 12th and final Agile principle states:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

A Sprint Retrospective (or “Retro”) is a practice used by Scrum teams to iteratively reflect and evaluate the way the team works and how its processes may be improved. It is an opportunity for the team to discuss their internal processes and surface both what works and what needs refinement. The Retro provides an opportunity for teams to confide in each other about their experiences during the Sprint, discuss ways to support and empower each other, improve morale and build camaraderie.

Put simply, the Retro is an opportunity for the team to be open and honest about their work and to evolve accordingly. It acts on the three pillars of Scrum: transparency, inspect and adapt.

At Hivekind, we use Retros as a way to adhere to these empirical processes while having a bit of fun, and we do them pretty well. We think in advance about what sort of experience we want to create for our team, and what feedback would be valuable. Our own observations over the past Sprint may direct this.

We sometimes use retromat.org for inspiration and adapt ideas as needed to fit our remote-first teams. We then prepare a Retro board using easyretro.io, a software tool that is used across Hivekind owing to its excellent remote-first environment.

Hivekind Meeting Room Scene

We share the Retro board at least a day before the Retro ceremony so that team members across various time zones can fill out cards ahead of time. We have found that providing team members with the space to reflect on and fill in cards asynchronously often yields much better feedback than when they feel time-pressured to share.

Once we start our Retro, we follow these rules to ensure the session is useful:

Set the Stage

Opening up can be a challenging thing to do. This is particularly true for sharing unpleasant experiences. However, this often yields the most crucial information, so sharing must be positively encouraged. We’ve found that having a bit of fun at the start of a session helps discussions — even the awkward ones — to flow more easily and naturally.

We find creative ways to change up our conversation starters for each Retro and encourage the team to get creative. Examples might include “Leave an Amazon review of the sprint: Stars, Title, Review” or “Use 3 words to describe your experience.” This task can also be entertaining: “Share a gif or meme that best represents your feeling this sprint and why you chose it” or “Get to know your team members better by writing 2 truths and a lie; other team members must guess the lie.” The point of this exercise is to reassure your team members that they are in a safe space, which allows them to feel relaxed and ready to open up.

Gather Data and Feedback

We gather feedback from the everyone on three themes:

Concerns and Recommendations — what didn’t go so well, and what should we do to improve it? This invites team members not only to raise unpleasant experiences but also to offer constructive feedback. Putting a constructive spin on something less pleasant or awkward in nature can often encourage teams to be more open to sharing. Surfacing these issues is crucial to the team’s ability to adapt and improve.

If the team continues to struggle, the Scrum Master can steer them by taking cues and asking the right questions. For example, if someone says they felt a little overwhelmed with the task this Sprint but is struggling to elaborate, some questions that could help encourage them are: “Did you think we over-committed?”, “Do you think more pairing would have helped?” or “Do you think the team should reveal blockers earlier so members can receive support quicker?” Thoughtful questions that help members manage and express their feelings often lead to successful discussions.

Lessons Learnt — what did we learn in this Sprint that is worth sharing with the team? This is a great opportunity to share. A team member may have discovered new software that helped them manage their time better, found a blog post that helped them solve a complex and long-standing user problem, or uncovered some interesting results from a recent spike. Sharing lessons learnt can be incredibly useful for improving work and processes, as well as improving general knowledge within a team. We also consider whether some of these lessons could be shared generally with the wider teams via workshops or sharing sessions during Hivekind’s fortnightly ‘Investment Time’ concept.

Kudos and Gratitudes — this is a very popular space whereby team members give shoutouts, express their gratitude for each other and celebrate the work that others did well. This is a magical column filled with morale-boosting joy and positive affirmations that strengthen the bonds of friendship within the team.

Create a To-Do List

A Retro would not achieve its rightful aim if we didn’t act on issues surfaced during the meeting. We list possible solutions to these issues in the form of ‘to-do’ items, which remain transparent and visible to the team until the next Retro. The team will revisit the previous Sprint’s to-do list at every Retro and review whether the suggested solution helped to solve the associated issue. If not, the team can adapt the solution and try again in the new sprint.

Close the Session

We always close our Sprints on a positive note. We establish consensus on the to-do list. The action items in this list are then assigned so that each can be actioned by their respective owners without confusion or delay. We then open up the floor for any last remarks before thanking participants for their time. We use any relevant feedback received to guide the team’s next Sprint Planning.

Conducting a successful Retro takes good preparation, practice and humour. This setup works well for Hivekind because it supports remote-first working and asynchronous communication. It ensures we adhere to the Scrum principles of working while giving us the opportunity, as a distributed team spread across the globe, to connect with one another.

Your vision deserves a great dev team.

We're not about tech jargon or over-promising. Instead, we focus on clear communication, transparency in our process, and delivering results that speak for themselves.

Awards won by Hivekind