Rethinking the Sprint Review: Why a “Steering Meeting” is Better #
For many agile teams, the Sprint Review has become a standard end-of-sprint ritual. But here’s the truth: Sprint Reviews aren’t working the way they were intended to. Instead of supporting continuous improvement, they often cause delays, create bottlenecks, and restrict the team’s ability to adapt quickly. Let’s look at why Sprint Reviews are a broken concept and why shifting to a Steering Meeting could be a much more effective approach.
Why Sprint Reviews Are a Broken Concept #
The Scrum Guide states that Sprint Reviews shouldn’t act as a gate for releasing value. In theory, increments can be delivered to stakeholders anytime during the sprint, and feedback should be gathered continuously. According to the Scrum Guide:
Yet, in practice, many Scrum teams end up doing exactly that—treating the Sprint Review as a gate. Often, the completed work is deployed just before the review meeting, and the team presents what’s now in production. At this point, feedback is too late to act on, making it impossible to implement any changes before the next sprint starts. In other cases, the team plans to release the entire sprint’s work right after the review, but the product owners are reluctant to delay deployment because the team needs to close the sprint and move forward. Both situations are far from ideal.
Delays in Feedback #
Having a “review” session encourages teams to hold off on getting feedback until the end of the sprint, slowing progress. Teams may hold back, reasoning that the review session exists specifically to gather feedback. But in reality, a continuous feedback loop would be far more effective, allowing the team to address issues as they arise rather than waiting for the review.
Imagine this scenario: a user story is marked as “completed,” and the developers move on to the next task. But when the product owner sees the work in the Sprint Review, they might request changes that could have been made earlier. With timely feedback, the team could potentially implement these adjustments within the same sprint, while the work is still fresh.
A Flawed Goal: Completing Work for the Sprint Review #
When teams work toward completing tasks for the Sprint Review, they lose sight of continuous improvement. Ideally, feedback should happen when it’s most relevant, not just at the end of a sprint. Sprint Reviews encourage a focus on “completing things in time” for a scheduled session instead of focusing on quality, user satisfaction, and iterative progress.
The reality is that the end of a sprint isn’t the time for a “review”; it’s the time to assess ongoing progress toward broader goals.
Replacing Sprint Reviews with Steering Meetings #
Instead of having a Sprint Review, which focuses on reviewing past work, consider adopting a Steering Meeting that looks forward. A Steering Meeting is an interactive discussion between the team and stakeholders about the near-term and long-term direction of the project. Here’s how it can work.
Continuous Feedback with Walkthrough Videos #
To ensure the product owner can review features as they’re completed, consider creating a short video walkthrough of each completed user story. This way, product owners and stakeholders can watch these videos at their convenience, providing feedback promptly rather than waiting for the end of the sprint. These videos also allow stakeholders to see each feature in action without interrupting development flow, creating a truly continuous feedback loop.
By organizing these videos in a shared location, anyone on the team can access them at any time. This setup keeps everyone on the same page, without waiting for a formal review session.
Steering Meetings: Looking Ahead Instead of Backward #
A Steering Meeting is a forward-focused session where stakeholders and the team discuss the project’s direction. It’s less about “reviewing” past work and more about “steering” toward future goals. The goal is to capture insights from stakeholders on both immediate and long-term priorities.
During the Steering Meeting:
- Stakeholders share their thoughts on the direction of upcoming features.
- The team and stakeholders discuss short-term priorities and the evolving roadmap.
- The conversation is interactive, encouraging stakeholders to voice any new ideas or concerns about the application’s direction.
This meeting structure also gives the team time to reflect on the project’s overall direction and any adjustments needed to align with stakeholder goals.
Benefits of Steering Meetings Over Sprint Reviews #
Reduced Meeting Length and Cost: Sprint Reviews often end up being long and time-consuming, taking up the entire team’s time. Steering Meetings, by contrast, can be shorter and more focused on forward-looking discussions, keeping everyone engaged.
Constructive, Forward-Looking Conversations: Sprint Reviews often focus on the past and can lack constructive conversation about where the project is headed. Steering Meetings shift the focus toward upcoming priorities, fostering a shared vision for the future.
Timely Feedback: By replacing Sprint Reviews with Steering Meetings, teams can shift toward a continuous feedback model, where input on completed work is gathered throughout the sprint. This real-time feedback allows for more meaningful improvements without waiting until the sprint’s end.
Stakeholder Engagement and Satisfaction: Steering Meetings create a collaborative environment where stakeholders can voice feedback, ideas, and concerns about the project’s direction. This keeps stakeholders engaged and ensures their input directly impacts future work.
Conclusion: Why Steering Meetings Are Better Than Sprint Reviews #
Sprint Reviews, as commonly practiced, are expensive in terms of time, disrupt team focus, and often lack engagement. They’re focused on the past, but agile development benefits most from discussions focused on steering toward a better future.
By replacing Sprint Reviews with Steering Meetings, teams can foster a more interactive and proactive approach, keeping everyone aligned on the project’s direction. The result? A development process that’s faster, more collaborative, and geared toward continuous improvement.