How To Do A Retrospective + (Step-by-Step Playbook and Example)

How To Do A Retrospective + (Step-by-Step Playbook and Example)
Complete article at: careerprep.me/how-to-do-a-retr...
How to do a retrospective in scrum. If you aren’t familiar with agile, you must be wondering, what is a retrospective? Ok, here we go. A retrospective is a meeting where you get together with your development team to discuss the last sprint. The goal is to self-inspect, identify improvement opportunities, and then create a plan on how to put that improvement into practice. Normally the last sprint we’re referring to is the last 1 week, 2 weeks, or 1 month of work. This meeting is typically timeboxed e.g. you allocate maybe an hour to an hour and a half to discuss work that was done in the sprint(s).
So, now that we know it’s a meeting to discuss past work and ways we can improve moving forward, what exactly is done in this meeting and how does it go? There are three major things covered in this meeting: What actions would you start; what actions would you stop, and what actions would you continue doing.
These three questions can come in different forms, but it all boils down to, “what went well?” and “what can we improve?”
Sometimes, there are mixed feelings about doing retros. We will explore both sides of the coin, but I can guarantee you that you should do them with your team as they will bring value. Let’s explore this more.

Why are some people against Retros?
Some managers and other individuals are against doing retrospectives. Some believe it is a waste of time and doesn’t bring value to the team. Others think that taking 7 or 8 members of the team and sitting them in a room just to discuss the last couple of weeks of work is a real financial drain and a costly meeting.
One of the pillars of Agile is continuous improvement. Conducting retros helps you look for ways to learn from your past work and help make things go smoother in the future. We will see the specifics of this in the section below on - Why you should do it.

Why you should do it
Individual and team expression: Another great reason to do a retrospective is that it allows the team to express themselves. This could be the good, the bad, or the ugly, but it is still important that the team, product manager, and scrum master know what the overall sentiment is. These meetings can be extremely important and really unearth certain things about projects, team dynamics, and work in general.
Get to know your team better: from a PM’s perspective, one of the great things about doing retros is that it is a great way to get to know your team better. This could be:
- What they like to work on, specific projects, tasks, hobbies, and what they think of the work. This even makes it easier when you want to pitch a project to them or get help on something, you would probably know the best person to approach.
- What they are confused about: another important thing to know is what confuses people. What are the things the team has trouble with? What are some of their pain points or that causes them to lose focus on the job? Also, what are some possible risk factors for your project? Having retros are great ways to find out if there are any risks to your project. Maybe you are already a few sprints into the work, having these sessions is a great way to gauge how things are going and how you can mitigate these risks through discussions.
Trust building: The more you work with your team, through both the good and the bad times, you will grow closer together. There is an element of trust that builds. Doing retros is a great way to build trust.
Create a blameless space where valuable feedback can be obtained: One rule to be followed is, you should not go pointing the finger at other teammates during a retro. It’s not a blame game. But it is a place where you should collect valuable feedback and help make the team more productive.
Address current wins and challenges: As mentioned earlier, retros can reveal what went well, and what didn’t. Examining what went well can help you continue doing what you’re doing and harness these positive outcomes. The same applies for what didn’t go well. Discussing what didn’t go well can help create valuable lessons learned so you can avoid them in the future.
Look for ways to improve the processes: Teams can always find scope for improvement on their projects/tasks. One of the areas is process improvement. This could be e.g. the amount of work taken on at one time (WIP), and then controlling the throughput, or the ways that the team conducts refinements, or a series of other things. The process can always be a little bit better and can improve.
- Team maturity building: The more a team works together and tries to improve itself, the more mature they become. Retros can help facilitate this.

[@SK-kf8dq]

Very well explained.

[@UmairKhan-hc2ql]

Excellent explained with practical approach

[@florianbonnet]

Actually I'm gonna post another comment. Because this helps me prepare my first retrospective. Very clear explanation. Just change the looks

[@sonipanghal3636]

Hows your scrum master role going?

[@nicolegalvao5306]

Congratulations, very good explanation.

[@vasudhaharan6214]

thanks

[@NutritiveSoul]

CC is broken

[@dharmdutt1771]

Hi, how can I get the template pls?

[@TristanBailey]

Good explanation but the examples were a bit poor. These should be one category as they are always a variation of what comes up and you need to get a bit closer to the why or test ideas to make change. Also outline at the beginning of the retro is it the retro of the delivery or the process of the team as to not just get side tracked from the team on the business value.

[@florianbonnet]

Nice thanks man. You should reshape your channel a bit and you'll get the visits

[@stefgerber2736]

The flippen long adds are annoying