How to Conduct An Effective Sprint Retrospective

2022-09-29 12:00:00
Jory MacKay
Source
Planio
Copied 1396
Summary : In this guide, we will describe what is a Sprint Retrospective Meeting, when to conduct it, and how to conduct it. Then we will introduce some best practices and recommendations for conducting a successful retrospective meeting.

Image Source: Planio

I. What is a Sprint Retrospective?

The official Scrum guide describes the Sprint Retrospective Meeting as:

"A meeting held at the end of a sprint where the Scrum Team can inspect itself and create a plan for future improvements to systems, processes, and workflows."

In more straightforward terms, it’s a safe space for the development team to discuss what went well and what missed the mark during the just-completed sprint and how they can improve in the future. During the sprint retrospective, the facilitator (most likely the scrum master) encourages conversation and documents each team member’s input in summary form.


Agile project development is all about continuous improvement. And as such, the ultimate goal is to come up with a list of actionable steps to make the next sprint more successful and enjoyable for everyone.


During the meeting, the team member may discuss:

  • Specific events that happened during the sprint–the good, bad, and ugly.
  • Improvements to processes like your daily scrum.
  • Changes to how you communicate internally or with stakeholders.
  • Any other places where someone sees an opportunity for improvement.

Each sprint is an opportunity to learn, grow, and improve your processes. The sprint retrospective is a chance to formalize this process and make sure actions are taking place, lessons are being learned, and positive change is being driven throughout the team.

II. When does the sprint retrospective happen?

As the name implies, a sprint retrospective happens at the very end of your current sprint, usually immediately after the sprint review and before your next sprint planning meeting.

If you’re a little confused by the difference between the sprint review and retrospective, here’s a simple way to tell them apart:

  • The Sprint Review is equivalent to a user acceptance test. During the review, the project team demos the deliverables to the product owner who reviews them against the acceptance criteria.
  • The Sprint Retrospective is closer to a project post-mortem where the whole team takes a step back and inspects their processes and workflows.

In other words, a sprint review is about the product while the retrospective is about the process.

III. How long should a sprint retrospective last?

While there are no established rules around how long a sprint retrospective should last, like all agile ceremonies, it needs to be time-boxed.

A good rule of thumb is to keep your sprint retrospectives to no longer than 45 minutes per week of the sprint. That means a one-week sprint would have a sprint retrospective of maximum 45 minutes, while a month-long sprint could take up to 3 hours.

Image Source: Planio

In addition, the duration of the Sprint Retrospective Meeting is affected by many factors, such as participants, working mode, the team running in degree, etc. The following examples will help you decide what is best for your team.

IV. Who should be at the sprint retrospective meeting?

The point of a sprint retrospective is to highlight all of the ways your team might improve in the future. And so it’s important to have a diverse set of voices present. In almost all cases, your sprint retrospective meeting should include the product owner, scrum master, development team members, and potentially even project stakeholders.

V. The red flags to watch out for during a sprint retrospective?

Any full team meeting runs the risk of going off the rails. But it’s especially risky when your team is talking about failures, mistakes, or places for improvement.

As you run your sprint retrospective, be sure to watch out for these red flags:

  • Don’t let teammates feel like retrospectives are being used against them: These meetings need to be a safe space for open discussion. But that won’t happen if your team feels like talking about their mistakes will lead to punishment. Make sure to express how the insights from the retrospective meeting will be used otherwise you’ll end up with a lack of conversation or apathy.

  • Make sure ideas from the retrospective are followed up on and turn into real actions: The goal of the retrospective is to facilitate continuous improvement not just air grievances and complaints. Make sure you have a process in place for capturing ideas and turning them into actionable tasks or user stories.

  • Don’t use the same format every single time: Like any meeting, sprint retrospectives can get repetitive with time. To get the most out of them, make sure that you switch things up, such as:

    • Cadence: Do you need a retrospective after every one-week sprint? Try experimenting with when and how often you run these meetings.
    • Style: Don’t use the same process each time. We’ve provided 7 different examples of sprint retrospective ideas you can try out below.
    • Who’s there: While the core team should stay the same (product owner, scrum master, development team), try switching up other members. For example, invite project stakeholders or other teams doing dependent or complementary work.
  • Be aware of the context (i.e. is your team in “crunch mode”?): Your team will have a hard time being retrospective if they’ve got a deadline breathing down their necks. Make sure the retrospective you’re planning is the best use of time given your team’s current commitments.

VI. 5 Steps to Change the Meeting Process and Effectively Conduct the Sprint Retrospective Meeting

Now that we understand what a sprint retrospective is, when it happens, who attends, and what to watch out for, let’s get into the specifics of how to run one.

If you’re new to running these sorts of agile retrospectives, start with the basics. With time, you’ll learn what works best for your team and your project.

1. Prepare and gather your tools

Every meeting needs preparation to be a success and a sprint retrospective is no different. A few days before your meeting is set, take some time to prepare and gather the tools you’ll need. At a minimum, this means you should review the notes and actions for the previous retrospective and ask a few questions:

  • Did these actions actually take place? Why or why not?
  • Did you get the depth of insight you were hoping for? If not, what questions can you ask that will prompt your team to be more introspective?
  • Are there recurring themes popping up in previous retrospectives? If so, how can you dig deeper into them and find real solutions?

Next, you’ll want to gather the tools you need to properly conduct your sprint retrospective. These are collaborative meetings and so you’ll need to make sure you have:

  • A meeting space booked for the maximum allotted time plus extra for set-up and tear-down.
  • Whiteboard or somewhere else to put up insights.
  • Markers and sticky notes for team members to write their thoughts
  • A timer to keep the meeting on track.
  • Project management tool like ZenTao to organize insights and turn them into actionable tasks.
  • Sprint retrospective template to keep you organized.

2. Seting the Meeting Time and Agenda

Every good meeting needs an agenda to set expectations and put everyone on the same page before they show up. The agenda of the meeting needs to include the content to be discussed, the chair of the meeting, and the ideal schedule. In addition, before the meeting starts, we need to spend a few minutes summarizing what the sprint has done. This step is very important because it can help participants retrospect their work quickly.


For example, here’s a sample agenda for a 45-minute sprint retrospective:

  • Opening (5 minutes): Set the stage and discuss the goal and outcome of the previous sprint (or more).
  • What went well (10 minutes): Give everyone time to talk about the positive aspects of the sprint.
  • What needs improvement (10–15 minutes): Move onto what needs improvement.
  • Next steps (10 minutes): Concentrate on what you can do to improve or fix those issues you just identified.
  • Closing (5–10 minutes): Leave a bit of time to thank everyone and run through the list of follow-up items, who’s responsible for them, and when they’re due.

3. Before the sprint retrospective starts: Establish a set of ground rules

Image Source: Planio

Once everyone has arrived for the sprint retrospective, take a few moments to welcome them and establish a set of ground rules that will guide the meeting, such as:

  • This is a positive ceremony: No matter how the last spring played out, make sure everyone knows that the point of the retrospective is to focus on continuous improvement of the team and processes. Stay away from the blame game and put the onus on ways to move forward.
  • Don’t make it personal (and don’t take it personally): Project management is about people. But a sprint retrospective is about processes. Make sure everyone knows that they’re critiquing workflows, situations, and systems, not the individual actions of other teammates.
  • Everyone gets an opportunity to speak without being interrupted: Respect the agenda and ask everyone to listen with an open mind.
  • Set boundaries of discussion: Set a limit on what’s going to be discussed and don’t fall into the trap of “backpacking”—bringing up issues from previous sprints, quarters, or years.

4. During the meeting: Run through what worked, what could have been better, and the next steps

The best way to run scrum review meetings is to keep asking questions. The choice of meeting questions also needs to be considered: don't stay on the surface, but go deep into the specific details, such as what changes we need to make and what motivates us to do this. What skills or knowledge can help sprint succeed? Where should we do better? How do we promote a spirit of teamwork?


In addition, each team member should also be allowed to speak so that they can have an opportunity to express their ideas and then paste the summarized information on the whiteboard (you can also answer different questions with stickers of different colors).

Project management is about people, but Sprint Retrospective Meetings are about process. We should ensure that everyone knows they're criticizing workflows, situations, and systems, not the personal behavior of other teammates.


Finally, it would help if you focused on the next steps you can take to improve and solve these problems. These solutions need to be tightly focused on actionable tasks. When participants present their ideas, we should try to make them concrete as much as possible so that their ideas have a good chance of being translated into action.


Once you have produced some solutions at the meeting, it is necessary to clarify the delivery value and delivery time of this solution and ensure that a definite action plan is produced after the meeting. Remember, this is not easy. But once the meeting is successful, it will greatly improve individuals and teams.

5. After the sprint retrospective: Document what was discussed and update your product backlog

Team meetings are one of the most expensive uses of time you have. And there’s no point in taking everyone away from their work if you’re not going to see tangible benefits.

You can then give them a priority and due date, attach them to your next sprint or milestone, assign them to the agreed-upon team member and even link them to the full Meeting Notes you have written up already.


Not only does this ensure that your big ideas get seen through, but it also gives you a record of each sprint retrospective that you can go back through before the end of your next sprint.


Need more help? Check out the Zentao blog. They have more articles on project management tools, software management, DevOps, and so much more.


--


Author bio :


Jory MacKay is a writer, content strategist and award-winning editor of the Unsplash Book. He contributes to Inc., Fast Company, Quartz, and more.

Write a Comment
Comment will be posted after it is reviewed.