Scrum sprint reviews don't work well
One issue often encountered during Scrum sprint reviews is the lack of stakeholder interest and an excessive focus on what was accomplished instead of considering the bigger picture. While showcasing the completed work is crucial, discussing the broader objectives and project goals is equally important.
Steering committee meetings are old-fashioned
Monthly development steering committee meetings are no longer popular due to the emergence of Agile methods. As per Agile values and principles, having a committee of managers discussing the direction of development activities is no longer effective.
Strike two birds with one stone - better Agile by combining the meetings
Here we have a situation where stakeholder steering committee meetings don’t work because the team isn’t involved, and the sprint review meetings don’t work because the stakeholders aren’t interested. So do you see the solution I’m hinting at? Both these problems can be addressed by redefining the role of the sprint review meeting as more of a steering committee meeting.
Sprint review antipattern - focus on what was done
One sprint review antipattern is when the team focuses solely on showcasing the completed items without considering what was learned during the sprint. This approach overlooks the valuable insights and lessons gained from the development process, missing opportunities for improvement and growth. To overcome this antipattern, the team must allocate time during the sprint review to reflect on what was learned, discuss any challenges faced, and identify actionable steps for future sprints.
Sprint review antipattern - failing to analyze contributing factors for not finishing tasks
Another common antipattern is when the team fails to analyze why specific planned tasks were not completed as expected. By not addressing the root causes of incomplete work, the team may struggle to identify process bottlenecks, impediments, or gaps in their planning. The team must take a proactive approach during the sprint review, examining the reasons behind unfinished work and engaging in open and honest discussions. This analysis helps the team to make necessary adjustments, refine their estimates, and enhance their planning and execution in subsequent sprints.
For the team, looking at these root causes may be painful and bring unwanted fear when bringing these failures up to stakeholders or managers. However, this kind of transparency is essential for successful Agile. That’s why we would need to have the review meeting take place in an atmosphere of blameless postmortem, where the successes and failures of the team can be analyzed and not hidden.
Check out our guide on Improving your Agile ceremonies.
Stakeholder interaction missing
Furthermore, a problematic antipattern occurs when the team doesn’t actively seek feedback from stakeholders who don’t provide updates on the market situation or customer needs. This lack of communication can lead to misalignment between the team's efforts and the evolving requirements of the product.
Stakeholders often exhibit reluctance to participate in sprint reviews due to several factors. One of them is they perceive the review as merely a technical showcase, where detailed discussions and decisions regarding the project's direction are not actively made. This lack of perceived influence and decision-making power can lead to disinterest and disengagement among stakeholders.
Emphasize the steering value of the sprint review meeting
To improve the sprint review meeting, we should motivate the stakeholders to participate by making the language used in the meeting less technical and easier to understand, as well as making it clear the review meeting is a meeting to steer the development.
You could even consider changing the name of the meeting. For example, it could be called a “Sprint review and steering meeting” or just “Review and steering”.
Suggested agenda
Here is an idea for the agenda for a sprint review & steering meeting:
- Welcome and a reminder to set the meeting tone to involve everyone and be a blameless post-mortem
- Review of sprint goals: were they achieved, and did the goals work in helping the team to self-organize? What could be done differently to make the sprint goals work better in the next sprint?
- Review and demo of work that was completed
- Review and analysis of work that was not completed
- Implications for future direction: what was learned, what kind of impact on the backlog did the current sprint have, what influences the next sprint goal setting, and how are we on track to meet the next Product goals?
- Stakeholder updates: what news from the market or other stakeholders may interest the team
- Open discussion: risks, concerns, feedback on the process, etc.
- Decision and action point summary
- Wrap up and thank you for participating
Consider alternating between a team demo and a stakeholder-involved session
Alternating between sprint reviews involving stakeholders and internal sessions focused on demos or team discussions can be a viable way to strike a balance and address the concerns of a heavy sprint review process. By alternating between the two formats, you can meet the needs of both stakeholders and the development team.
During the stakeholder-involved sessions, you can emphasize collaboration, gather feedback, and discuss the project's bigger picture and future direction. This allows stakeholders to participate in decision-making, providing valuable insights and aligning the product with their expectations.
The team can then focus on demos and discussions more specific to their needs in the internal sessions. This allows them to showcase their work, analyze what was done (and what wasn’t done), and conduct retrospectives to improve their processes and productivity.
By adopting this alternating approach, you can maintain a lighter and more focused sprint review experience while ensuring stakeholders are involved and the team has the space for internal discussions and improvements.
Keep retrospectives separately
It’s worth noting that the retrospective is typically not included as part of the sprint review meeting. The retrospective is a separate ceremony within the scrum framework where the development team reflects on their performance, identifies areas for improvement, and defines action items for the next sprint. Unlike the sprint review, the retrospective is intended for the internal team and doesn’t necessarily require the active involvement of stakeholders.
By holding the retrospective independently, the team can openly discuss and address internal matters, team dynamics, and process enhancements without navigating potential distractions or concerns related to external stakeholders. This gives them a dedicated space for reflection and continuous improvement, helping refine their practices and deliver greater value in future sprints.
Published: Sep 21, 2023
