Sometimes teams get stuck in a rut of completing projects the same way. Work gets done. Customers seem happy.
But are projects running as smoothly as they could be?
Are team members frustrated with aspects of the workflow?
Are there new team members with valuable input based on their experience at other companies that could improve your processes?
When was the last time your team sat down to discuss what’s going well and what could be improved in your workflow?
If you’re practicing Agile and skipping the Scrum retrospective, more often called the sprint review meeting or sprint retrospective meeting, you’re missing out on an opportunity to improve productivity.
In this article, we’ll discuss:
- What is a Scrum retrospective meeting?
- Ground rules for retrospectives
- What are the five stages of a retrospective?
- Questions to ask in a Scrum retrospective meeting
- How to make a Scrum retrospective meeting productive
Let’s get started.
What is a Scrum retrospective meeting?
A Scrum retrospective, one of the five scrum ceremonies, is a meeting that occurs at the end of a sprint and includes the Scrum master, the product owner, and the team who worked on the sprint.
The goal is to allow team members to discuss what went well during the sprint and what needs to be improved in upcoming sprints.
The meeting should be a safe environment for everyone to have an open discussion.
Ground rules for retrospectives
It’s helpful to set some ground rules in a retrospective to keep the meeting a safe space.
- Remember the golden rule of treating others how you’d like to be treated.
- Respect other people’s input, even if you disagree.
- Don’t interrupt when someone is talking. Wait for your turn.
- Be prepared for the meeting. The meeting isn’t as valuable if everyone doesn’t participate. Jot down notes before the discussion about what went well, what issues occurred, and any suggestions you have to help make future sprints run smoothly.
- Share your honest feedback. If there is an issue, speak up. You're not being rude; you're just making the team better.
- Accept constructive criticism without viewing it as an attack. This is not a blame game, but a path to continuous improvement.
 |
What are the five stages of a retrospective?
The book Agile Retrospectives: Making Good Teams Great by Diana Larsen and Esther Derby discusses the five stages of a successful retrospective. Let’s take a look at each stage.
 |
Set the stage
Welcome the team and discuss the objectives of the meeting. It’s nice to give the team a few minutes to settle in before getting into a discussion that involves critiquing the past sprint. Consider an activity such as a short icebreaker to make everyone comfortable before getting too far into the meeting.
Gather data
Prepare for the meeting by having a retrospective agenda and data from the previous sprint.
For example, did a team member get sick and have to take some unplanned time off? Did a system that the team relies on go down during the sprint and cut into work hours? How did these events affect task completion? These are great data points to discuss during the scrum retrospective.
Then, during the meeting, discuss the number of story points the team completed compared to what the team committed to.
Generate insights
Allow everyone on the team to discuss what did and didn't work in the current sprint.
For example, in a software development project, members of the development team might have technical feedback.
The business analyst might have input on whether customers (or stakeholders) were easy to work with.
Or developers might have input on the specifications. Were they detailed enough? Or did they have to go back to the business analyst for further clarification?
And the QA team might have input on testing. Did it go well? Or did QA uncover basic functionality not working?
Everyone should feel free to share their thoughts and ideas.
Decide what to do
The team should then make action plans around the insights so that the next sprint runs smoothly.
For example, suppose the QA team shared that they are coming across a lot of bugs and broken functionality. In that case, the team might decide that developers share unit test results with QA to show their testing before sending the project to QA.
Assign each action item to a specific person who's accountable for implementing the action item.
Our software development team might decide to assign a QA team member to develop a unit testing template. It'd include test results development needs to complete before sending projects to QA.
Close the retrospective
Once action items are assigned, the team should recap important points of the retrospective. Someone on the team should document all action items and issues so the team can review them at the next retrospective.
At the end of the meeting, it’s important to thank the team for attending and for their hard work during the previous sprint.
Questions to ask in a Scrum retrospective meeting
Consider using the following questions to spark conversation in a scrum retrospective meeting.
Did we complete everything we committed to?
The team should begin by reviewing any work not completed in the sprint.
If tasks run past their deadline, the team should discuss what can be done differently next time.
For example, if a system went down that the team uses for work, is there a way to make the system more reliable? Is there an upgrade that’d fix the system issue?
As you brainstorm solutions to prevent missed deadlines in the future, consider using a project planning tool like Motion. Motion alerts users when a task is past its deadline.
 |
What changes did we implement this sprint?
It's not enough to just make changes based on retrospective feedback. The scrum team should discuss changes that were made to make sure they did help.
For example, let's say that the team discussed (in a previous sprint) that developers sometimes didn't have enough information from QA in bug reports to recreate issues, resulting in a lot of back and forth to get clarification.
So the team decides to use a free trial of a screen capture tool. The idea is that QA records videos of how to recreate bugs they find.
After trying the screen capture tool, the team should then discuss if the tool was beneficial or not. Did QA find the tool easy to use? Was it a lot of extra work for QA to take the videos? Is training available? Did the developers find the videos helpful?
If the tool helped, great. If not, is there another option, such as QA filling out a template of the steps they took to create a bug?
What went well in the previous sprint?
Scrum retrospectives shouldn't focus just on issues. The team should also discuss what went well. Team members will be more likely to want to attend a meeting that doesn’t only focus on negatives.
Things that went well should be celebrated (and repeated in the next sprint).
What should our team improve upon for next time?
In any project, there'll be things that don't go as planned. Team members should discuss what could be done better the next time.
The team should recognize that this isn't meant to be critical of anyone, but is meant to get the team working more efficiently.
For example, if the team found that meetings were interrupting their work schedule constantly, the team might consider marking certain hours of the day for meetings on their schedule (and blocks of time for uninterrupted work). By the way, this can easily be done with Motion's meeting assistant.
What roadblocks did we have? How can we prevent them in the future?
Were there issues, such as not having what was needed to complete the work? If so, what can the team do to ensure they have the right supplies in the future?
Was communication lacking among the team (or from someone outside the team, such as a customer)? Can the team build time in their schedule to ensure they have time to communicate with others? Suppose communication with an external customer is problematic. Can the team contact someone who can discuss the need for timely responses (for example, a client account manager)?
Were the requirements unclear? If so, can the business analyst create a requirements template with the needed information to ensure the necessary information is included next time?
Did the project experience scope creep? If so, could some of the additional features have been postponed for a future sprint?
And did the budget suffice? If not, was there a way the team could have stayed under budget? Or was the budget just underestimated for what needed to be accomplished?
 |
Did we commit to the right amount of work?
The team should evaluate the workload they took on (and keep changes needed in mind when planning the next sprint).
Even if all tasks were completed, the team should evaluate if the amount of work was ideal. Did team members scramble to finish tasks at the end, putting in overtime or sacrificing quality to meet a sprint deadline?
Did team members have enough work to keep them busy throughout the sprint?
Are the lengths of our sprints working for us?
If the team finds that the sprint cycle isn't working for them, they should discuss trying longer or shorter sprints.
No rules say that you must stick with a two-week sprint if you're consistently not hitting the sprint goals.
How to make a Scrum retrospective meeting even more productive
Let’s take a look at a few ways to get the most out of a retrospective meeting.
 |
Limit meeting attendees
Keep meetings limited to the agile team. While key stakeholders or managers may want to attend, this will prevent some team members from feeling comfortable sharing honest feedback (which is critical for improvement).
Document findings
When issues are discussed, document the discussion. In fact, create a retrospective template.
Create concrete action plans during the meeting to implement for future sprints. Make sure there’s accountability for action items.
When the action plan and accountable person are documented, the team can more easily review previous action items at the next retrospective.
Encourage collaboration outside of the retrospective
As the team works to make changes based on retrospective feedback, they should work together. As the timeless adage goes, “teamwork makes dream work”.
If there are issues that need to be addressed and cannot wait until the next retrospective, the team should bring them up sooner. The daily scrums can be a good place to do that.
Use project management software
Project management software can help teams work together more efficiently.
Many project management software options allow users to store documentation such as meeting notes. Storing retrospective meeting notes in a central location where the team can refer to them helps to make sure action items are not overlooked.
Project management software also helps with collaboration. Some tools allow users to communicate directly on project tasks.
Reporting functionality in project management software also allows the entire team to get a clear understanding of what was done from the sprint backlog (and what was missed).
Use Motion to make retrospectives more productive
Motion is a great project management software to increase retrospective productivity.
In Motion, meeting notes can be attached to projects. If there is feedback from a previous retrospective, the team can see the notes (and comment on them) directly in the app. Teams can collaborate right where the work is taking place.
Motion’s Kanban view can not only be used to monitor tasks during a sprint, but also after the sprint is completed as a retrospective tool.
If you are not using Motion, access a 7-day free trial today.
