paint-brush
How to Get the Most Out of Your Sprint Reviews by@justanotherteachlead

How to Get the Most Out of Your Sprint Reviews

by Just Another Tech LeadJanuary 29th, 2025
Read on Terminal Reader
tldt arrow

Too Long; Didn't Read

Sprint Retrospectives can be hugely effective or largely a waste of time depending on how they are run. Learn how to run an effective Sprint Retro.
featured image - How to Get the Most Out of Your Sprint Reviews
Just Another Tech Lead HackerNoon profile picture

With two decades in Software Engineering, I’ve participated in a lot of Sprint Reviews. Some were highly effective, while others felt like formalities lasting a few hours each sprint.


When executed correctly, a Sprint Review is vital for keeping your project on course. Poorly managed Sprint Reviews not only waste timebut also reduce trust in the Scrum framework.

This article outlines clear, step-by-step strategies to make your Sprint Reviews more impactful.



What Is a Sprint Review?

A Sprint Review is a short meeting held at the end of each sprint, typically every few weeks.


It provides the team with an opportunity to demonstrate their completed work through presentations, gather feedback, and decide on the next steps.

When run effectively, the Sprint Review highlights progress and builds trust with stakeholders involved in the product and project.


While you can inform stakeholders verbally about your progress, showing them during the Sprint Review makes a more positive impression.

Who Should Attend the Review?

Essentially, anyone interested should attend.


All project stakeholders, regardless of their role, can benefit from participating in these meetings.

The core of the meeting includes the scrum team, but Sales, Senior Management, other scrum teams, and Project Managers can also attend.


If someone can contribute valuable insights or gain useful information about the project, they should be present.

Preparing for the Review

To ensure a smooth meeting, presenters must be ready with their demos.

In my experience, live demos often encounter issues. Therefore, it’s best to have presenters record their workflows before the meeting. This way, if a live demo fails, you have a backup video.


Additionally, prepare a running order. Know who will present and group presentations on similar topics. For example, if six engineers are working on different aspects like the Login Page, back-end services, and database performance, organize their presentations accordingly.


Grouping similar topics reduces context-switching for the audience and streamlines the meeting flow.

During the Review

Engineers present their completed work to the scrum team and stakeholders. After each presentation, attendees can ask questions or provide comments.


Questions may aim to clarify aspects of the project or ask about specific solutions chosen.


Business-focused members might offer feedback on whether the demonstrated work aligns with the business goals.


Once all questions and comments are addressed, the next presenter takes the stage.


In Sprint Reviews, everyone is encouraged to participate, but typically, only Engineers are present. This allows focused feedback on the presented work from Product, QA, BA, and other roles.

Example Review

Consider a team of six engineers working on different tasks: two on the Login Page, two on back-end services, and two on database performance. The running order might look like this:


Presentations:

1.	**Larry:** Users are locked out after five failed login attempts and must reset their password to regain access.

2.	**David:** Users can reset their passwords by clicking the “Forgot Password” link, receiving a reset link via email.

3.	**Premilla:** The Reporting Service tracks the “User Exceeded Max Login Attempts” event and displays it on the dashboard.

4.	**Akshat:** The Reporting Service logs the “User Clicked Forgotten Password” event on the dashboard.

5.	**Olga:** Admins can view the monthly reporting dashboard and load reports within three seconds.

6.	**Trevor:** Admins can view combined user events on a single dashboard, loading reports within two seconds.


By presenting related topics together, the audience needs less context-switching. For example, the first two presentations focus on the Login Page, followed by reporting services, and finally database performance. This organization makes the review more efficient and easier to follow.


After Larry’s presentation, Product might ask why five retries were chosen as the limit before locking the account. Larry can respond or note that further research is needed to align with industry standards.


Each presentation may lead to questions, comments, and suggestions, fostering valuable discussions. For instance, some might suggest using email-based magic links instead of traditional usernames and passwords, highlighting the benefits of diverse perspectives in the review.

Actionable Takeaways

Here are some tips to enhance your Sprint Reviews:

Showcase Real Deliverables

Always present working software or completed tasks instead of static slides. For example, demonstrate a new login feature through a live demo. This approach makes the review more authentic and shows tangible progress.

Encourage Open Feedback

Invite questions from all attendees. Let stakeholders know their input can shape future work. Document their suggestions and decide if any changes should be added to your backlog.

Keep It Clear and On Track

Follow a simple format: start with a quick overview of the sprint goal, proceed to demos, and conclude with a discussion of next steps. Avoid diving too deep into technical details. If a topic requires more time, arrange a follow-up discussion.

Align on Next Steps

Update your backlog based on the feedback received. If a feature needs adjustments, add that task immediately. This keeps everyone informed about the plans for the upcoming sprint.

Keep It Short and End on Time

Focus on reviewing one scrum team’s work for each sprint, typically spanning two or three weeks.


If meetings become too lengthy, consider splitting the scrum team into smaller groups or improving the efficiency of your demos.


Respecting everyone’s time ensures that participants remain engaged and the team stays energized for the next sprint.


Aim to limit meetings to around 90 minutes, and set a firm end time to encourage concise feedback.

Conclusion

A Sprint Review provides stakeholders with a real-time view of completed work, ensures everyone is aligned on future tasks, and gathers solid and productive feedback for your project.

For more insights, visit my blog, Just Another Tech Lead. Best of luck with your next Sprint Review!