Is the sprint review meeting mandatory to have? We do all scrum meetings religiously except “Sprint Review”. Actually we never felt need of having this meeting.


TL;DR- Highly recommended. If you don't have it, then you are losing your inspect and adapt loop with your stakeholders.

The longer answer Nothing in Scrum is required (Though by the technical writing of the Scrum guide if you don't use all the events and artifacts it's not technically scrum). Scrum and agile are based on the concept of inspect and adapt. Figure out what works for the team and organization and keep doing that.

Now that being said, the five events (Sprint, Planning, Standup, Review, Retrospective) are based on decades of experience and use. Sutherland and Schwaber just updated the Scrum guide and they haven't magically removed any events.

So then we come back to the specific team and organization and ask why an event might not be seen as useful. In my years of coaching, I've seen all the events challenged as "not needed". In all that time I've rarely found the root cause to actually support out not having that specific event.

The Sprint Review's primary purpose is to "inspect the Increment and adapt the Product Backlog if needed". It's your GPS on if you are building the right thing, in the right way.

The main reasons I've seen for not having a Review:

  • The product owner has already seen the stories and approved them.
  • The stakeholders are not available.

So the first one is a great thing to have. In fact, if the PO isn't seeing stories until the Review, then you have a problem. The Review is led by the PO, so they should know what's being demoed.

The second is a constant challenge. However, without the stakeholder feedback, you can easily fall back into the Waterfall trap of "That's not what I asked for" when they finally see the product. Instead of not holding the meeting, try adjusting when and how you hold it. Maybe go for every other sprint or try a science fair type model.

When a Scrum Event is not working, start with asking why. They exist because of decades of experience that they work.

And just read this excellent and timely blog on the Sprint Review. Some good pointers. http://www.romanpichler.com/blog/sprint-review-tips-for-product-owners/

  • You are so right about reasons for not having sprint review. Both reasons stands true in our case. :) – ssharma Nov 20 '17 at 19:00
  • How do we overcome on above two reasons? – ssharma Nov 20 '17 at 19:03
  • 1
    You don't want to overcome the first. This is a good thing to have the PO signing off when a story is done. Getting your stakeholders more engaged is going to start with questions. You need to find out why they are not engaged and work from there. There isn't a single, sure-fire solution. – Joel Bancroft-Connors Nov 20 '17 at 19:44
  • A third reason I have come across a few times is when teams are uncomfortable with showing their work; they lack the confidence, the work isn't tested, or the transparency it creates is undesirable for some. Obviously, these point to far deeper problems. IMHO, sprint review meeting is the most important scrum event, with all being almost equqally important! – Muhammad Nov 21 '17 at 21:05


You don't have to follow Scrum to be agile, but you do have to follow the Scrum framework and implement all of its ceremonies to claim that you're practicing Scrum.

Sprint Review is Mandatory in Scrum

Is the sprint review meeting mandatory to have?

Yes. It's a defined ceremony within the Scrum framework, and must be adhered to in order for what you're doing to be considered "Scrum." In fact, the end note of the Scrum Guide says:

Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.

You can extend Scrum, or use additional practices within it, but you can't choose to implement only some of Scrum and still claim to be following Scrum.


Generally, if you don't see the point of the Sprint Review, the team and the organization are Doing Scrum Wrong™. For whatever reason, you're not seeing value in collaborating with stakeholders, demoing completed increments, or feeding additional data into the product ownership or Sprint Planning functions of the process. All of these things (and more) are spelled out in the Scrum Guide's description of the Sprint Review.

So, you have two basic choices:

  1. You can review the actual purpose of the Sprint Review, educate your team and stakeholders about the need for a properly-performed Sprint Review, and then work with the Scrum Team and the stakeholders to integrate the review into your Sprints and take full advantage of all the process goodness that comes along with proper performance of the Sprint Review.
  2. You can choose to be a Scrum-But team by saying: "We're' not actually doing Scrum. We're working on being agile, though. What we're doing is Scrum-like, but..." Then just list all the ways you're not actually doing Scrum, along with your business justifications, if any.

Danger, Will Robinson!

There are two types of people who commonly implement Scrum-But. The first is extremely experienced practitioners who have truly mastered both the four values and twelve principles of agile software development, and are working to adapt Scrum to a use case outside the usual target. For example, using Scrum for support work or administrative workflows rather than for product development.

The second, and much more common, group of people are teams that are new to agile, haven't truly mastered the values and principles, and who simply don't like one or more of the ceremonies or practices. This second group is much more likely to experience failed Scrum implementations, and to then blame the framework rather than their incomplete implementation for any failures.

Real mastery allows you to leverage the framework without allowing it to become a straitjacket, but if you're changing core tenets of a framework without a thorough understanding of why those things are part of the framework in the first place, then that shows a probable knowledge gap rather than insight into a unique use case.

Your original post certainly doesn't contain enough information for me to pass judgement on your process, but statistics and Occam's Razor certainly suggest that your team is more likely to be misunderstanding the need for, and utility of, the Sprint Retrospective than it is to be making a masterful and well-considered change to a non-Scrum (but possibly Scrum-like) framework.

Scrum doesn't fit every use case, and agile practices aren't a panacea. However, if you haven't implemented the full framework, it's hard to defend the notion that it doesn't work properly in your case when it hasn't been properly leveraged in the first place.

Your mileage on your journey towards agility may vary. In the meantime, following well-traveled roads on your journey is a lot easier and more productive than off-roading in the agile equivalent of a Ford Fiesta.

  • 1
    This is an excellent answer!! It's heartbreaking that it is not the selected answer. It exemplifies the ignorance in this community regarding the Scrum framework. – Alan Larimer Nov 23 '17 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.