Is It Time to Stop Holding Sprint Reviews?

Sprint reviews have long been an important part of Scrum. They exist as a mechanism for collecting feedback on what the team has just built. The product owner then considers that feedback in determining priorities for the next sprint.

But, have sprint reviews outlived their usefulness?

Perhaps 10 years ago, every Scrum team followed a pattern similar to sprint, sprint, sprint, release. A release would occur every few sprints, or at the most, after each sprint.

Releasing mid-sprint was unheard of. Today it is very common and many teams practice continuous delivery or deployment and release multiple times per day.

Think about such a team and its sprint review.

If they are releasing multiple times per day, they will be asking the product owner and stakeholders to comment on features that are already being used by real users.

If I were a stakeholder and asked that, I’d reply, “Uh, well, what do our users think about those features?”

For teams that release product backlog items as they are finished during a sprint, the formal sprint review as it’s been historically used is of very limited value.

I coach such teams to do one-at-time feature reviews.

One or two people from the team meet with the stakeholder(s) who requested that feature. They include the product owner if possible and when appropriate. And they demonstrate just that one feature, collect feedback on it, and then either release it or make necessary changes.

Instead of a formal sprint review where perhaps a dozen product backlog items are demonstrated, reviewed and discussed all at once, subsets of the team do a dozen one-at-time reviews in real time as needed.

But even in this case, there may still be value in the traditional, end-of-sprint review. The primary purpose of a sprint review has always been getting feedback. But a side effect of that is that stakeholders leave the room better educated or informed about the product.

A team that does one-at-a-time reviews may still want to consider holding a formal sprint review. It’s a great way to educate all stakeholders about all the things that were released during the sprint.

Moving away from the formal, big-bang sprint review is not appropriate for all teams. If your team builds, for example, a physical product that is released once a year, a traditional-style sprint review is likely still the best.

But if your team releases more often than at the end of the sprint, considering a move to one-at-a-time feature reviews will help you succeed with agile.