Nimble Work Management
Kairon - Gen AI Solutions
AKT/ AKC Access
You don’t have to be around agile project management for long before you hear someone talk about a retrospective. We’re not talking about your favorite artist’s latest gallery show, although we are looking back at past work.
A project management retrospective is all about collating feedback to empower the team to improve continuously. In this article, you’ll learn what a sprint retro is for and the 5 steps to making it happen.
First, let’s make sure we’re completely clear on what a retro is in Scrum.
Scrum is an agile approach that heavily leans into ceremonies, one of which is the retrospective.
The retro happens at the end of each sprint and it’s a meeting where the team gets together to review how the sprint went. It’s more than simply, “Did we complete all our work?” It’s a time to reflect on and inspect working practices and the processes involved with a view to drawing out how the team could be more efficient and effective in the next sprint.
The retro is attended by the Scrum Master and the Scrum team and will also normally include an inspection of the Definition of Done: in other words, is it still clear what ‘done’ looks like and does that definition of work complete still serve the team? If it doesn’t, some of the retro session could be spent coming up with a new definition, or that task could be added to the backlog to be addressed in the next sprint.
Humans are hard-wired to reflect about past events. Consider the last time you went out for a meal: did you discuss it with your fellow diners during or after the event? Chances are you left the restaurant and either commented on how nice it was or complained a little about some element of the meal that left you underwhelmed.
A Retro is a work-based opportunity to do exactly that, but with the added benefit that you can actually implement changes to make things better. While you can’t influence how a restaurant serves its food (you could email and send in your feedback, but you can’t force them to act on it), you can make sure feedback on a sprint is taken forward proactively.
The purpose of the sprint retro is to identify behaviors, ways of working and tools that are efficient and should be used again in the next spring. You also want to identify behaviors or techniques that are not working well and should be modified.
The retro also serves to foster transparency and collaborative working. It can identify other areas where the team needs to develop skills. Simply talking about these topics can also improve morale.
Even if you haven’t worked in an agile environment before, you may have come across the three questions commonly asked during a retrospective. They are commonly used in predictive/linear project management lessons learned sessions too, and also crop up in other reflective situations. The questions are:
👉 What went well?
👉 What could be improved?
👉 What will we commit to doing in the next sprint?
The team discusses areas of collaboration and processes that worked really well and should be maintained. Then spend some time talking about any impediments or problems the team faced and whether they were adequately resolved. If not, why not? If so, what contributed to helping to get them sorted out?
The Scrum Guide recommends that the whole session should last less than 3 hours for a sprint that lasts a month. If your sprint is shorter, shorten the retro time appropriately – you don’t need to tie everyone up for hours!
You’ll probably hear the team talk about the 5 steps or phases of the retro process. These come from the 2006 book, Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen. Let’s look briefly at each of the steps so you know the process of running a great retro.
When the team comes together for the meeting, welcome everyone and set the expectations for the time. Share the agenda and purpose of the conversation and how the retro will be run. Some Scrum Masters use facilitated activities like Glad, Sad, Mad, or the 4 L’s to draw out key points. You’ll know what activities are likely to work best for your team, and explain them now so the team knows what is coming. Bring up the template on screen if you are hosting a virtual retrospective.
Next, review what happened during the sprint. Share the facts, but also give the team the chance to talk about how they felt during the sprint. Was it calm or stressful? Was it well-organized or disjointed? How much work was completed compared to how much was planned?
Now it’s time to ask the first two retro questions: what worked and what didn’t go so well. Note down the answers on a virtual whiteboard or in your agile project management software so everyone can participate and see the points that have been raised.
Before the meeting closes, spend some time reviewing what you will do differently in the next sprint. Are there any actions that need to be taken forward? Make sure they have an owner and a plan.
You might not be able to act on everything at this point, so if there are lots of potential areas for improvement or change, consider which are the priority to focus on for the next sprint.
Finally, draw the session to a close. Thank everyone for their time and recap the key takeaways. Share the next steps so people know what happens next, for example, that you will store the outputs of this meeting in a shared repository so they can access the notes at any point.
You can choose to use a different process but this is a common, structured approach to making sure all steps are covered.
With NimbleRetro’s Workboard, you can track all your actionables.
The most important stage of the 5-step retrospective process is step 4:Deciding what to do and what the team will commit to.
The team takes responsibility for implementing changes identified as a priority during the retrospective. The goal is continuous improvement, and making sure that the actions are carried out is a sure-fire way to improve delivery next time.
Retrospectives are most useful when what is learned is put into practice. Keep doing what works well and change up what could be done differently!