Sprint Review Vs. Sprint Retrospective – And How to Run Them

In Agile development and its Scrum methodology, there are distinct ceremonies designed to for both product development and team improvement. 

Two of these ceremonies are the sprint review and sprint retrospective.

While sometimes mistaken for one another, do different things and are both integral parts of our Agile methodology.

But when we get this wrong, we end up with misaligned teams and inefficient product development.

The five Scrum ceremonies

There are five events that Scrum product development teams perform to be successful. These are…

• Sprint Planning meeting
• Daily Standup meeting / Daily Scrum
• Sprint Review meeting
• Sprint Retrospective
• Backlog refinement meeting

The difference between Sprint Reviews and Sprint Retrospectives

The main difference between the Sprint Review and Sprint Retrospective is that the former is product-centric, and the latter team-centric.

Sprint Review: An outward-facing ceremony that primarily centers around the product. The goal is to align the development with business goals and stakeholders' requirements.

Sprint Retrospective: An inward-facing process focusing on the team's dynamics, their methods during the last sprint, and potential avenues for improvement.

The heart of Scrum lies in its emphasis on continuous improvement. It's not just about doing the work but also about refining how the work is done. This spirit finds its expression in these two ceremonies. Regular Sprint Reviews ensure the product aligns with market needs, while Sprint Retrospectives offer the team a structured way to identify and action on performance enhancement.

Sprint Reviews in Depth

Sprint reviews offer a brief moment of pause, reflection, recalibration, and more importantly, collaboration.

What is a sprint review?

Purpose: At its essence, the Sprint Review is about 'show and tell'. The objective? Provide insights about the product, display the achievements of the last sprint, and ensure alignment with stakeholder visions.

Participants: Sprint reviews are collaborative platforms. Besides the Scrum development team and the product owner, this ceremony welcomes business stakeholders. Their presence ensures a direct line of communication, allowing feedback loops to be short and effective.

Duration: Typically, it varies between one to four hours, depending primarily on the sprint length. The longer the sprint, the more there is to discuss and align.

What happens during a sprint review?

1. Reviewing the Sprint Report. Sprint reviews should begin with everybody already on the same page. It’s a good idea to distribute a sprint report, explaining the goal of the sprint, progress and key metrics.

2. Demonstration: It all starts with demonstrating the work completed. The team presents their product progress, features or complete work from the previous sprint.

3. Stakeholder Interaction: Stakeholders can share insights and feedback from those who represent users or the market. This is an opportunity to get aligned and bridge the gap between technical implementation and commercial vision.

4. Product Backlog Update: Post interaction, it's back to the drawing board. The product owner, armed with feedback, revises the sprint backlog for the upcoming sprint in the project management software. This ensures it mirrors current market needs and aligns with the next sprint's priorities.

During a sprint review, the product owner represents the voice of the customer and stakeholders and updates the sprint backlog.

The Scrum Master facilitates the ceremony.

The goal of Sprint Reviews

The ultimate goal of sprint review is alignment.

Everyone should leave the sprint review with a shared understanding about the product’s current state, and the future direction.

The product backlog should reflect this re-alignment, so that the team’s efforts in future sprints are directed towards the highest priorities.

Getting the most out of Sprint Reviews

For engineering leaders, three things warrant special attention:

1. The Sprint Report. One of the greatest downfalls at Sprint Reviews is wasting time simply explaining at a high level what has happened. Everybody should have had access to a concise, context-rich Sprint Report so that attendees can get to what matters, fast.

Try Stepsize AI to keep everyone aligned without lifting a finger.

Stepsize AI observes everything happening on your Jira or Linear board. It develops context about your projects and goals, and forms connections between tasks, activities and more.

The result is super accurate, automatic weekly sprint report with the perfect amount of context and detail to kick off your sprint review meeting.

2. Stakeholder Involvement: Stakeholders aren’t just passive observers. Their engagement is pivotal. Their feedback can alter product trajectories, ensuring alignment with market demands. Leaders should champion this involvement, ensuring stakeholders are prepped, present, and proactive.

3. Resource Allocation: The feedback from the Sprint Review can sometimes illuminate areas needing more attention or resources. Leaders should be agile, ready to reallocate resources, or infuse additional support. The aim? Ensure that the product trajectory remains in harmony with stakeholder feedback and expectations.

Sprint Retrospectives in depth

Behind every successful Scrum team is a ritual of reflection. That ritual is the Sprint Retrospective meeting, or the “retro”. 

What is a sprint retrospective?

Purpose: The Sprint Retrospective meeting provides the team with a platform to reflect on their methodologies, processes, and overall performance during the last sprint. Think of it as a health check-up for the team's operational dynamics.

Participants: This ceremony is reserved exclusively for the Scrum team. That includes the developers, Scrum Master and Product Owner. The absence of external stakeholders ensures an environment where there can be openness and candid conversations.

Duration: Retros should be fixed in length, with timings kept in check by the Scrum Master. Typically, retros will be about an hour, but that’ll depend on the team and sprint length.

During a sprint review, the product owner participates actively, sharing product-related feedback.

The Scrum Master facilitates the ceremony and tracks action items for the next sprint. They create a safe space for open communication.

What happens during a sprint retrospective?

Every team member should be actively involved in your retro. There are all kinds of models for a Scrum retrospective, but typically, the retrospective is divided into three key segments:

1. What went well? Start by identifying and celebrating what worked. What aspects of the sprint made the team proud? This acknowledgment not only boosts morale but reinforces positive behaviors, and encourages teams to spot positive opportunities.

2. What didn’t? Which areas left room for improvement? This isn’t about finger-pointing, but about collectively identifying bottlenecks or missteps.

3. What can we larn? Finally, we pinpoint actionable steps. The team collaborates on tangible solutions to ensure the next sprint is even more effective.

‍

There are loads of great models and ideas for sprint retros, including “Mad, Sad, Glad”, Sailboat retros, “Start, Stop, Continue” and various others. Here’s a great list of some of the most popular formats.

The goal of Sprint Retrospectives

The goal of sprint retrospectives is to improve engineering productivity. By having this open space for reflection, the team can spot opportunities and risks, and take action to capitalise on the former and minimise the latter.

It’s an opportunity to improve Ways of Working, and an opportunity for leaders to boost morale and acknowledge success, too.

Getting the most out of Sprint Retrospectives

There are all kinds of ways retrospectives can be counterproductive. Here are some common problems we can avoid to get the most out of our reviews.

• Begin with context. Use a Sprint Report to ensure everyone’s up to speed on the sprint goals and what’s happened during the sprint so far. You can use Stepsize AI to generate sprint reports effortlessly, based on your data in Jira or Linear, without lifting a finger.
• Keep retros actionable. It’s easy to descend into a venting session. Keep discussions gravitating towards solutions and actions.
• Plan to implement. Plans are fine, but we have to execute. Leaders should make it clear who is responsible for what and create accountability.
• Avoid monotony. It’s a good idea to vary the format or try new techniques to bolster engagement.
• Be disciplined. Leaders should manage time carefully during retros and keep discussions focussed and fruitful.

Stepsize AI automatically generates weekly product development reports to use at your sprint retrospectives or sprint reviews.

It does this by integrating with your team’s Jira board or Linear team, and developing context and understanding of what happens, your tasks, projects and goals.

The result is weekly sprint reports with the perfect amount of commentary, context and detail, all without lifting a finger.

Get your first weekly report for free here.