How to make sprint retrospective meetings more effective
Lucid Content
Reading time: about 10 min
Topics:
What is a sprint retrospective?
A sprint retrospective, typically the last step involved in Scrum methodology, is a meeting scheduled at the end of a sprint. The team, including the Scrum master and product owner, reviews what went well during the sprint and what could be improved in an effort to continuously analyze and optimize the process.
You spend a lot of time in meetings. On average, anywhere from 23% to 37% of your time is spent in meetings. If you are a Scrum master or in middle management, it’s possible that you spend up to 50% of your time attending meetings.
If you’re going to spend a large chunk of your time in meetings, you should always make sure that the meetings you plan—especially one as important as a sprint retrospective—are productive and efficient. In fact, a good sprint retrospective idea may be to discuss how many meetings the team attends, how long meetings should last, how productive those meetings are, and how you can make meetings more productive.
This article includes some fun ideas that you can easily incorporate to run your sprint retrospective meeting more effectively and efficiently.
What is covered in a sprint retrospective?
Simply put, the Scrum retrospective meeting lets you analyze your process in the previous sprint and create a plan for improvements in the next. So what do you discuss in a sprint retrospective? Really anything that affects how the team creates the product is open to scrutiny and discussion, including processes, practices, meetings, environment, and so on.
The meeting is meant to give the Scrum team the opportunity to ask and address questions such as:
- What did we do right in the previous sprint?
- What did we do wrong in the previous sprint?
- What should we start doing in the next sprint?
- What should we stop doing in the next sprint?
- What can we do to improve productivity?
When is a sprint retrospective meeting held?
Your sprint retrospective meeting should be held after your sprint review and before the next sprint planning session. Sandwiching the retrospective between the two, you and your team can most effectively discuss what worked in your previous sprint, as well as what can be improved, while your previous sprint is fresh in your mind. You can also discuss what commitments your team can make to ensure the next sprint is successful, based on data and observations from your previous sprint.
Who should attend sprint retrospective meetings?
All members of the Scrum team—Scrum master, product owner, and developers—should attend the retrospective meeting. The meeting should provide an environment where the team members feel safe to share honest feedback on what’s going well and what could be improved and to participate in a discussion of what needs to change with clearly defined action items.
How long should a sprint retrospective take?
The length of your sprint retrospective meeting may vary slightly based on the length of your sprint and the retrospective technique you employ. Sprints lasting a month usually require no more than a three-hour sprint retrospective. Shorter sprints will likely require less time to dissect (and as we'll mention below, we recommend keeping the meeting as short as you can). Scrum masters should allow for ample time to discuss and collaborate between team members while also making sure that the meeting remains productive.
Sprint review vs. sprint retrospective
While the purpose of the sprint retrospective is to help teams reflect on the previous sprint in order to improve processes, the sprint review’s purpose is a little different. The sprint review is a two-part meeting in which the Scrum master, the development team, the product owner, and other stakeholders present their progress to the customer. The team’s progress is carefully measured against the commitments made at the beginning of the sprint, and the customer is given a chance to offer input on the progress made.
How to run a sprint retrospective effectively
Studies show that a major complaint of the Agile methodology is the perception that there are too many meetings. Of course, for some people, one meeting per week is too many. What can you do to keep the team from thinking that a sprint retrospective is more than just another meeting?
Keep it simple
You are not going to solve all your problems in one meeting, so don’t try to. Instead, boil the discussion down to the few questions we listed earlier:
- What do we need to stop doing?
- What do we need to start doing?
- What do we need to continue doing?
The idea is to engage your team by encouraging them to quickly identify where improvements can be made and what actions can be taken to make those improvements. For example, maybe your team has the problem of going over the 15 minutes scheduled for the daily standup meetings—you can easily fix this by making sure your meetings always start and end on time.
Whatever you discuss in a sprint retrospective, make sure you are inviting participation, documenting suggestions, and voting to determine which actions to take.
Keep it short
Meetings take time, and time means money. According to a 2014 report, over $25 million is wasted per day on meetings—$37 billion per year. In addition, it can take up to 20 minutes for employees to focus on their work again after an interruption such as a meeting or incoming email. Keeping your meetings short and to the point can go a long way to keeping costs down and productivity up.
You’ve scheduled your sprint retrospective for one hour (or three), but does that mean that you have to use the whole hour? It’s okay to end meetings early.
Stay focused
Your retrospective meeting should not be a social gathering. Stick to your agenda to stay focused. Create a retrospective meeting agenda that can help members of your team who seem to spend more time on unrelated tangents than on topic.
Change things up a bit
Meetings can be really boring, and bored team members are less likely to participate. In fact, bored employees are more likely to read email, work on other projects, or fall asleep. Regularly scheduled meetings, such as a retrospective, can become repetitive. If you see eyes glazing over and you keep getting the same answers to the same questions, you need to change things up a bit to get team members involved.
You can also try to add games or other fun activities to liven up the room and get your team more excited about participating in another retrospective meeting. See the examples below.
See how you can use Lucidchart to improve each stage of your sprint, particularly if you're part of a dispersed team.
Learn moreSprint retrospective examples
A simple way to get your team more involved is through the following activities. Click on the images below to get started with a template in Lucidchart.
Glad, sad, mad
Use this activity to let your team express their feelings so you can understand their emotional health. Meeting tight deadlines can cause a lot of stress and put your team under a lot of pressure. This is a good activity to help you understand the things in the previous sprint that made your team mad, sad, or glad. Group similar observations, and discuss and vote on which observations have the most impact.
Starfish
This exercise goes beyond the typical three retrospective questions ("What went well?” “What didn’t go well?” “What can be improved?”) by focusing on the following five words within a circle:
- Stop: Activities that add no value to the team or customers.
- Less: Activities that have been included in the past, but do not add any overall improvements to the process.
- Keep: Activities that add value to the process and are already being used and don’t really need any modification or improvement.
- More: Activities that the team should focus on or perform more often.
- Start: Activities and ideas that the team believes will add value and will improve current processes.
Sailboat
This is a simple exercise that helps you and your team define where they want to go and identify any problems you may run into. Use a drawing with:
- A sailboat on the water with its anchor lowered
- Some rocks below the water’s surface
- Some clouds with lines to indicate wind
- An island or shoreline
The sailboat represents the team. The island or shoreline represents the team’s vision or goal. Everything else in the drawing represents things that can help or hinder your progress (wind pushes the boat forward, the anchor slows it down, the rocks can strand or sink the boat).
Using the drawing, start a brainstorming session to identify your goals, the actions that can help you achieve your goals, and the things that can hinder you. Discuss and vote on action items that will help you more efficiently achieve your goals in the next sprint.
Start, stop, continue
The start, stop, continue retrospective technique is the process by which sprint team members come up with actionable items that they can incorporate into the next sprint. During a start, stop, continue retrospective, scrum masters ask their team to identify items to:
- Start: Activities that the team should implement during the next sprint. These can include ideas that would potentially address current problems.
- Stop: Activities that the team should stop. These items may be steps within your process that cause unnecessary work or bottlenecks.
- Continue: Activities that are currently being implemented and should continue to be implemented in the next sprint. This list can include items that create value, make your process more efficient, etc.
The Scrum master should begin the sprint retrospective by asking the team what’s working and what’s not and then sorting each idea into the categories above. They should also remind your team that this process is not about assigning blame or dwelling on the negative but identifying inefficiencies and creating a more effective process.
4 Ls
The 4 Ls retrospective technique is similar to the start, stop, continue method in that it asks a sprint team to examine the previous sprint from every angle. Instead of focusing on deliverables, team members dissect their performance as individuals and as a team and look for ways to improve processes as a whole by identifying the 4 Ls:
- Things they liked: Activities that proved productive, increased efficiency, fostered greater cooperation, or added value to the process.
- Things they learned: Any knowledge that caused a shift in perspective or provided valuable insight into the product, customer, or process.
- Things they lacked: Activities that could’ve been done better, more efficiently, or at a lower cost.
- Things they longed for: Activities or resources that they team wished they’d had at any point during the sprint.
Participants should submit their suggestions anonymously to avoid biased submissions, after which suggestions are grouped into categories and discussed by sprint team members. Participants can then vote on submissions to denote which are most important to them moving into the next sprint. A 4 Ls retrospective should last no more than 30-60 minutes total.
WWW
The WWW (or what went well) retrospective technique is a basic technique that focuses on the team’s strengths and weaknesses. It’s best used when your team wants to take a logical view at what’s going right and what needs to be improved before the next sprint. Very simply, sprint team members identify what went well and what didn’t go well during the last sprint.
To complete a WWW retrospective, scrum masters should ask their team to submit activities that did and didn’t add value to their previous sprint, recording each idea on a chart, which can be referenced for further discussion. Scrum masters should guide the discussion to focus on constructive improvements that can be made to team processes. This retrospective should take anywhere between 30-60 minutes, depending on the length of your sprint.
By using the templates above and collaborating with your team in real time, you can effectively and efficiently run sprint retrospective meetings, keeping team members fully engaged and defining the ways to improve your next sprint.
Sign up for Lucidchart to streamline every part of your sprint, from planning to recording feedback during the sprint retrospective.
Try it nowAbout Lucidchart
Lucidchart, a cloud-based intelligent diagramming application, is a core component of Lucid Software's Visual Collaboration Suite. This intuitive, cloud-based solution empowers teams to collaborate in real-time to build flowcharts, mockups, UML diagrams, customer journey maps, and more. Lucidchart propels teams forward to build the future faster. Lucid is proud to serve top businesses around the world, including customers such as Google, GE, and NBC Universal, and 99% of the Fortune 500. Lucid partners with industry leaders, including Google, Atlassian, and Microsoft. Since its founding, Lucid has received numerous awards for its products, business, and workplace culture. For more information, visit lucidchart.com.