What are the differences between sprint retrospectives vs. sprint reviews?
Before we dive into the key differences between these scrum events, it’s important to note that you need both a retrospective and a review for maximum success. Contrary to some opinion, the events aren’t in competition; they work together to optimize future sprint planning.
Retrospectives and reviews can both be held synchronously and asynchronously, and we’ll go into why synchronous meeting formats shouldn’t be your default (spoiler alert: it’s because of meeting overload, clogged calendars, and disengaged teams).
In this digital age, it’s super simple to use async platforms like Yac for non-urgent meetings, ticking this important meeting box while maintaining productivity. (But more on this later.)
Below, we outline the benefits of sprint reviews and retrospectives and why your agile team needs both.
Sprint retrospectives focus on the human side of the project
You already know that a happy and productive scrum team is integral to project success. Sprint retrospective meetings exist to reflect on the human side of a sprint.
These meetings are an opportunity for product managers, developers, scrum masters, and any other key scrum team members to talk about their sprint experience, rather than just its outcome.
Sprint retrospectives reflect on how the entire team worked together and how future sprints or projects can be improved. They are an important opportunity for project managers and scrum masters to flex those leadership muscles.
During a sprint retrospective, leaders devote time to thanking their teams for their contributions to the sprint.
If the project went well, this meeting is a well-earned celebration. If the project didn’t go quite as planned, the meeting serves as a morale booster and an opportunity to create an action plan to mitigate future problems.
Team members need to feel heard and understood by their managers. Retrospectives should serve as a safe space for the team to vocalize their opinions, needs, and concerns.
Talking points can include:
- Did the team understand their manager’s expectations?
- Did the scrum team feel motivated and inspired by the sprint?
- Is there a disconnect between employee experience and management perception?
- What were the communication challenges?
- Did the chosen methodology work?
- Do daily scrum meetings need improvement?
- Is there a specific team member weighing down productivity and harming morale?
It’s best to prompt team members before the retrospective to come prepared for discussion. (We’ll show you how to do this later in the article.)
This also helps retrospectives be time-efficient. From our research, we found that 64% of sprint retrospectives take 30 minutes to 1.5 hours. Providing discussion points upfront and, even better, holding them asynchronously can save a ton of that time and keep people on track with their immediate tasks.
Sprint retrospectives are an opportunity for project managers and agile team members to come together and discuss how they can work together more efficiently.
While team collaboration and employee satisfaction are essential, sprints exist to execute a specific project with product output goals too. This is why sprint reviews are needed.
Sprint reviews focus on product output
While sprint retrospectives concentrate on the experience of the sprint, sprint reviews focus on the outcome.
A sprint review meeting focuses on the numbers, often with data from sales and marketing teams. Sprint reviews are also an opportunity for employees outside the product team (e.g., sales and marketing) to gain insight into product development.
The data discussed in these meetings might be hard numbers like:
- How many new customers did the outcome of the sprint bring to the company?
- How many existing customers purchased the new product?
- What are the impressions on the product marketing campaign?
- How much new revenue did this revenue bring to the company?
- How much did the sprint cost in total? Was it worth the investment?
However, there are other, non-quantifiable questions that are important too, such as:
- Are our customers happy? Do we have any common feedback?
- Are there any outstanding bugs/issues that need to be addressed in the product?
- Did the team improve over the previous sprint?
- Can we consider the sprint a success?
So, retrospectives exist to improve any gaps in communication or other aspects of teamwork, while reviews assess the outcome of this teamwork: did the team work together to create a quality product?
Both sprint retrospectives and sprint reviews should conclude with actionable takeaways and next steps. Retrospectives should lead to more efficient collaboration and communication, and reviews should lead to positive workflow and development changes.
As any agile team leader knows, running an effective and productive meeting isn’t always easy. With a clear plan, sprint retrospectives and reviews can be streamlined, collaborative, and (dare we say it) enjoyable.
Let’s look at how to make the most of your team’s time while wrapping up a sprint.
How to lead a sprint retrospective
First things first, you need to determine if you’ll be having a synchronous meeting or an asynchronous meeting.
Synchronous retrospectives work best when there are urgent issues, such as conflicts between scrum team members. A good rule of thumb: If the conversation could get contentious, sync is the way to go.
Another consideration is the size and length of your project, as well as the number of people involved. For larger projects with a lot of moving parts, stakeholders, and opinions, a sync meeting is often better.
For general wrap-ups, async retrospectives can be just as efficient without filling up your teams’ calendars with another real-time meeting. Async meetings let employees respond to meeting queries at a time that suits them best, and as such, they’re less wasteful of team members’ time. We’ll look at an example in just a moment.
Regardless of the way your team will be communicating during the retrospective, an agenda is essential for the meeting to be effective. The agenda for an async retrospective could look something like this:
Let’s look more into these agenda items.
Meeting prep
Before the meeting, the host should help the team prepare by sending questions ahead of time. This helps team members collect their thoughts at the end of the sprint and allows the meeting to run more efficiently when the time comes.
Put your meeting prep in a collaborative document, like a Google Doc or Notion board, and share it in a Yac to explain what’s coming up.
As an example, let’s say you’re going to host a meeting on a Miro board (an interactive whiteboard tool).
Items on your meeting prep could include:
- Questions about the team’s experience. This prompts team members to reflect and include insights to share. It’s also a reminder that this retrospective is about the experience of the sprint, not how well the team reached sprint goals.
- A survey to gauge team temperature. This isn’t always necessary, but can be helpful if there were some significant issues during the sprint. This survey allows leaders to effectively prepare for a potentially heated conversation (and, if necessary, pivot to a sync meeting).
Using Miro, you could use dot voting and have team members place colored dots on pre-loaded answers, such as rating their overall experience on a scale from one to five.
Sprint highlights
As a manager, a big part of your job is uplifting and motivating your team. Regardless of how the sprint went, starting on a positive note is essential for morale.
Share a Yac voice message to thank team members for their contributions, and call out any big challenges they overcame.
Of course, the retrospective is a dialog, not the product owner’s soapbox. Team members should take this as an opportunity to share their thoughts on their sprint experience.
Heading back to the example, using Miro’s retrospective template, teams can post digital sticky notes on a “highlights” board so the team can see everyone’s experience in one place.
Areas of improvement
Here, team members share what they think needs to be addressed for a better sprint experience next time around.
Using an “areas of improvement” board on Miro’s retrospective template, team members can again use the digital sticky note function to call out what they think needs work.
These areas of improvement should focus on workflow and communication. It’s fine for product managers to strategically give constructive criticism, but team members should be leading the conversation.
This is where tools like Yac can be a big help. Using voice communication helps you get sensitive points across better than text-based comms. Product managers can use Yac to share with the team what changes need to be made in future sprints.
Sending an async voice message lets you consider a comprehensive answer with a sensitive approach. Coming up with this on the spot in a sync meeting is far more difficult.
Action items
The meeting should end with clear actionable items. Empower your team to suggest ideas to try out for the next sprint.
For example, you could put these concrete ideas on an “action items” board within your Miro retrospective template and then copy them onto your next sprint retrospective board to see if these ideas played out.
By concluding with action items, you’re wrapping up the retrospective (and the sprint) with solutions, not problems, and setting your team up for future success.
Stay focused and confident
A sprint retrospective is an opportunity for development teams to find ways to work more collaboratively and efficiently. Product owners need to be focused and confident throughout the meeting to instill the same feeling into the team.
Jake Knapp, who wrote the book on sprints, says:
“Be confident so the group has confidence in you. And be confident in the structure, so things keep moving, but be humble enough to let others come up with the content, the insights, the solutions—and sometimes go a little off topic.”
Of course, while team experience is important, you’re all there for a purpose: to build an amazing product that drives revenue. This is why your team also needs a sprint review.
How to lead a sprint review
Sprint reviews and sprint retrospectives are run similarly, but with key differences.
Again, you’ll need to determine if your review will be sync or async.
Because sprint reviews include input from sales and marketing teams, async generally works better for everyone’s busy schedules. If the sprint went poorly and there are real issues to comb through, a face-to-face sync meeting is better.
Sprint reviews also require an agenda, which would look similar to the agenda for a retrospective. But the execution of each item isn’t quite the same.
Let’s elaborate.
Meeting prep
Because sprint reviews focus on the outcome, you’ll need the data from sales and marketing teams (and potentially operations or data teams in larger organizations) to quantify the sprint’s success.
Before the meeting, product owners should share this data with the team, so they have the necessary knowledge for an impactful conversation.
A Notion board is a great tool for organizing all this data into one place. Product owners can also send a Yac screen share with a link to the board to elaborate on data as necessary.
Sprint highlights
If the product didn’t do as well as hoped, morale may be low. The review is an opportunity to focus on the positives from an outcome perspective.
For example, team members can add their Yac voice messages to the collaborative review Notion board, giving their own input on these highlights.
For a full discussion, project managers can ask questions such as:
- What processes and tools led to the sprint’s success?
- What did the team do differently this time that led to a better outcome?
- What successes are the team most proud of?
- Were there any issues with a specific product backlog?
- What can we add to the scrum framework?
- Did the team fulfill the product increment?
Celebrate the team for completing another project. As Jake Knapp says, it’s important to “trust the recipe.” Even if this sprint did not meet the product goals, the next sprint can.
Areas of improvement
Your team may already know what caused problems with the product, so pay attention to these pain points. And remember, team members should be driving this conversation, not leaders.
Instead, product owners should ask their agile teams what specifics they need to improve the sprint outcome and create a cohesive product backlog, such as:
- A longer timeline
- Better project management tools and technology
- More support from other teams
- More training
You could record these areas of improvement in Notion, so the team can clearly see them as they develop action items.
The areas of improvement stage is also an opportunity to pay attention to customer feedback. What does the team need to better address customer concerns?
Action items
A company is only as good as its product, and improving the product sprint process is in everyone’s best interest, regardless of their team.
Because of this, action items from the sprint review may require more input from stakeholders and senior team members, especially if it includes investing in new tools or talent.
Any action items should focus on one key question: What does the product team need to create products that our customers will want to buy?
When product owners determine action items at the end of a sprint, it’s important to remember that those who worked on the product know it better than anyone else. Their input should be weighed heavily when creating action items.
Like with retrospectives, it’s important to end the review on a positive note. Product owners should wrap things up, ideally with a Yac thanking the team again and giving a high-level overview of these action items.
Focus on solutions, not problems, and stress how grateful you are for the team’s contributions.
Key takeaways
Sprint reviews and retrospectives both serve an important purpose. Retrospectives focus on the experience of the sprint, while reviews focus on the outcome.
By assessing both the product itself and the workflow and communication of the humans behind it, product teams can be more successful, which means success for the company.
With a bit of preparation, you can lead efficient sprint reviews and retrospectives that will allow your team to thrive. Learn more about why Yac is the perfect tool for your asynchronous meetings.
