How to do a retrospective in scrum. If you aren’t familiar with agile, you must be wondering, what is a retrospective? 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 time-boxed 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.
Retro Playbook – Getting Started
OK, now that you have seen quite a few reasons why you should do a retro, let’s learn the specifics on how to prepare for one.
Here is a quick list of things you need so you can kick off your retro.
Prep
- A meeting spot booked for at least 1 hour – it can be in an office room or it can be an online meeting like a Zoom or Google hangout etc.
- Supplies – stickies, markers, paper, whiteboard, timer, or if it’s online, you can use an electronic board like FunRetro.
- Label the columns – Start, Stop, Continue, or What went well, what to improve? Action Items. You can also name the columns on the electronic boards.
Set the stage
One of the keys to setting the stage is getting everyone on the same page and knowing what to expect. This will help the retro get off to a smooth start. Let’s look at a few ways to set the stage. You can send these out in the invitation to the retro or even read them out before you get started with the meeting.
- Leave your egos at the door – come ready for a healthy discussion.
- Don’t make it personal – focus on the issues, not the person.
- State the time period – specifically say the time period you are referring to, most likely the last sprint, unless you are working on a different type of project (a non-agile one). If it is not agile, you could do it for a specific deliverable that was accomplished, or over a period of time, or another criterion that has been agreed upon.
- Focus on ways you as a team can improve
What went well:
For our first column of the retro – what went well, let’s go through a few simple instructions.
- Have each of the team members have green sticky notes where they can jot down multiple things that went well during the sprint
- If this meeting is taking place online, each person should log in on their machine or phone and get ready to fill in the notes under the respective column.
- Make sure it is only one idea per sticky. It is OK to have a board and a column full of stickies. We’ll sort those after.
- The same applies to online boards. Make sure it is one idea per tab created.
- Since some stickies may have recurring ideas or maybe similar, there should always be someone, a moderator, or even the scrum master to group similar sticky notes or duplicates. This helps to organize the column.
Once the team has finished writing out stickies about what went well, you can move onto the next column. One thing to keep in mind is to timebox each section. Maybe 5-10 minutes on each column to fill out the stickies.
What needs improvement:
Once you have completed the What went well column, it’s time to jump over to the what needs improvement column. For this one, we’ll use:
- Pink or red sticky notes
- Once again, the same process as you did before, but in a different column. Focus on the things that need to be tightened up or could use some improvement.
- Focus on the work, not specific people. E.g. avoid saying something like John was constantly absent the last sprint and this set us back, or he wasn’t pulling his weight in this last sprint and now we are really behind. Instead, aim for things such as, the team took on too much work or underestimated the stories for the sprint.
Discussion:
Now that you and the team have filled out what went well and what needs improvement columns, have a short discussion about each sticky note, that way everyone is on the same page and understand the good or bad issue. This will help when you vote. Once you have gone down the list of items, it’s time to vote on them.
Voting:
Take a few minutes with the team to vote on the most important items to act on. Make sure you tell the team how many votes they have, e.g. 3 votes. If you have stickies on the wall, you could do dot voting (each member could use a dot as a vote on the sticky note). If it is an online retro board, you could just click the thumbs up button.
Ok, so imagine you have just finished voting on the items. Now you can clearly see which items the team has deemed as priority items to focus on to improve moving forward.
Action items
– After the team prioritizes the action items, it is time to decide what to do with each item. Suppose that one of the most voted/agreed-upon areas of improvement was to always have the designs ready for the sprint or have fewer meetings so the team can code more. Let’s take the second one. Are there specific meetings that the team takes part in but add little to no value? These might be possible candidates to eliminate. This would be an action item to further investigate.
Retro example
Now for a real example of each of the columns and some example sticky notes.
What went well
– Good collaboration
– Willingness to work on new tech stack
– New member joined the team and onboarding is going well
– Have meeting mid-sprint to discuss future stories – helps gets the team on board and understand what’s coming.
– Good pairing work was done despite remote work.
– E2E automation has really improved things
– The team delivered all of the planned work even with big stories.
What to improve
– Fewer meetings more coding, Period!
– Before picking up any story, each story should have clear acceptance criteria.
– The team should pick more non-functional requirements to improve the code base
– Stories should be independent and have business value on their own
– Each feature and task should be divided, and people assigned to it – not everyone on the same story
– Guarantee e2e automation success status after every code merge to develop
– Use a more accurate way of estimating story size – what we use isn’t accurate.
– Need to have more team building events
Action items
– Guarantee all stories have clear acceptance criteria before picking them up
– Find more accurate ways to estimate our stories
– Try to eliminate unnecessary meetings
*Add these action items in the sprint so you make sure to do them.
Slide Deck
Wrap up
So, there you have it, how to do a retrospective. Remember, even though you have done the retro, it should not end there, make sure to create action items, or even review some of the action items in the subsequent retro and talk about what was done or not done. This can also be a good way to help jump-start the next retro session – reviewing previous retro action items.
How do you do retros with your team? Please share your experience with the community in the comments section below.
Remember, there is no perfect way to do a retrospective. Consider it as an iterative and exploratory process where you are looking for what works best with the team.
For more Agile step-by-step videos, check out the CareerPrep Youtube Channel.
Other articles you might enjoy:
