Dropping the Sprint Review from Scrum — is this really possible?
My reflections on Mike Cohn’s article
Last week Mike Cohn dropped a bomb when he posted this article:
The takeaway of this article is: the Sprint Review might not always make sense in a true CI/CD environment.
“I no longer consider the sprint review a mandatory element of Scrum.” — Mike Cohn in “Are Sprint Reviews Necessary? The answer might surprise you”
Mike isn’t the first to state this. On the contrary: many have been questioning the Sprint Review in the world of continuous delivery. People like John Cutler and Joshua Kerievsky come to mind.
But the fact that Mike Cohn states this is from a different magnitude. For me at least. He may not be one of the writers of the Scrum Guide (which are Ken Schwaber and Jeff Sutherland), but:
- He is referenced in the first Scrum Guide (from Scrum Alliance, 2010).
- He co-founded Scrum Alliance (with Ken Schwaber and Esther Derby).
- He was pivotal in popularising Scrum. We all know his books, like “Agile Project Management with Scrum” (2004) and “Succeeding with Agile: Software Development Using Scrum” (2009).
So when Mike Cohn comes with a statement like this, it’s serious.
What is Mike saying about the Sprint Review?
Mike states that times have changed. Great teams nowadays deploy many items throughout a Sprint, 7 to 10 times a day.
I imagine the team asking stakeholders in a review, “So, what do you think of 70 new things we developed?”
And the stakeholders reply, “Who cares what we think? What do our users think? They’ve been using these features already.” — Mike Cohn
He then states that seeking feedback at the end of the Sprint is too late. You can already get feedback from the users earlier and this the best feedback that you can get.
So what then? According to Mike teams could:
“…get feedback often and in small doses. As soon a product backlog item is done, team members should show it to perhaps one to three stakeholders who need to see it before it’s released. Often this could be only the requestor of the new functionality and the product owner, if they’re not the same person.” — Mike Cohn
This could repeat every two or three hours, depending on how fast teams deliver items. The risks of working like this are small because we’re talking about a limited number of lines of code every time.
However the Sprint Review is about more than giving feedback on what is being built:
“A sprint review is a chance for the team and stakeholders to discuss priorities and plans for the product.” — Mike Cohn
This activity may still be very useful for teams, even if they deploy 70 times in a Sprint. On top of that: Mike addresses the fact that the demos of the pieces of functionality may only reach a limited number of people, but you may want to show the complete picture to more people.
So Sprint Reviews are still very useful for many teams — also for teams that deploy multiple times per day — but it should not be mandatory anymore, according to Mike Cohn.
This is a clear departure from what is stated in the current Scrum Guide:
“Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.” — Scrum Guide 2017 Ken Schwaber and Jeff Sutherland
Other things to consider about the Sprint Review
Within the Serious Scrum community the article lead to many interesting observations:
Sjoerd Nijland: “there are some BIG prerequisites Mike lists that should be in place for the team to be able to skip it the way he sees it. The main one being: the team needs to be able to collect and process feedback from stakeholders and Product Owner on a continuous basis. The big thing that will be missing even if the team is doing this: there is no longer a group collaboration taking place between Scrum Team and stakeholders where they review the backlog and market changes together.”
Ionut-Adrian Bejenaru: “it is one thing to deploy and another to release. Even if you technically deploy 20 times a day — releasing is a marketing event that most often than not must be timed. I do agree that it is wonderful to get feedback as fast as you can but I still do see the Product Owner being sole responsible for value. And thus he can take the decision to release without the consent from anyone else. In the cases of a CD environment perhaps one week Sprints are most suitable. Having a whole product review is the kind of big picture that is still needed. Secondly you can’t really get actionable metrics to make an improvement from these daily releases — you need to follow users behaviors for at least few days. “
Maarten Dalmijn says: “You need more than a few days, sometimes even weeks to get data. So until then, feedback is still welcome. Not all feedback needs to come from data. Secondly, if you have data I would actually use the Sprint Review to discuss the data and get feedback. Interpreting data and coming up with actions based on it, still would be good to do with different stakeholders with different viewpoints.”
I agree with the points that Sjoerd, Ionut, Maarten and Mike Cohn (in his article) make. The Sprint Review is not a demo only and with your frequent demos you probably will not be able to reach as many people as with the Sprint Review. Also the availability of your stakeholders can be an issue if you have frequent demos throughout the day.
Having said all of this: the power of Scrum is that it works in any complex environment. The Sprint Review however can be an issue for specific teams, notably teams that deploy frequently in an environment with a limited number of stakeholders that can easily be brought together to discuss the increments. I can imagine that the people responsible for Scrum wish to find a way to make Scrum work for them as well. A way COULD be to stop considering the Sprint Review as mandatory for Scrum.
What does it mean for Scrum if the Sprint Review stops to be a mandatory event?
So suppose that the next iteration of the Scrum Guide says that the Sprint Review isn’t mandatory anymore, what then? I believe that the consequences of saying “The Sprint Review is an optional event” could be disastrous. We are talking about an event that covers a pivotal thing in Scrum: Inspecting the increment and adapting the Product Backlog. It’s the heart of Scrum (collaborate, deliver, reflect, improve — Heart of Agile). Making the Sprint Review optional can’t be an isolated change to Scrum. There has to be an assurance that the inspect and adapt opportunity is being covered. Because without it Scrum loses its heart.
Many teams struggle to understand what a Sprint Review is about and have a hard time to make it effective. Making it optional will trigger them to drop the event altogether and completely miss out on the pivotal purpose of inspecting the increment and adapting their course.
Perhaps this inspect and adapt opportunity could be tackled similarly as the Refinement. Refinement is part of Scrum, but it is not an event. The Scrum Guide says that Product Backlog Refinement should be in place, but the guidelines are limited. It is up to the Scrum Team to decide how. This could work for the act of inspecting and adapting what was built too. But there’s more.
With the Sprint Review as an integral part of Scrum, what is left of Scrum when it stops to be mandatory?
What is the reason for a Sprint if you decide that it doesn’t need to end with an inspect and adapt moment to discuss what you have done and what you will do next? And if the Sprint can be questioned, you can do the same for all other events.
Scrum Guide revision upcoming?
We may see a new version of the Scrum Guide soon. Why? Well the Scrum Guide improvement suggestions site is put to read-only with the remark: “User Voice is read-only while new Scrum Guide is under development”.
Is this article from Mike Cohn a glimpse of what is to come? Well he IS an important person in the Scrum community and perhaps the old phrase “where there’s smoke there’s fire” is true.
Conclusion
Mike Cohn dropped a bomb with his statement that according to him the Sprint Review isn’t a mandatory Scrum event anymore. Mike didn’t create the Scrum Guide, but he is a very important person in the Scrum community.
The Sprint Review truly has been a pivotal event as it touches the heart of Scrum: it is here where you inspect the increment and adapt the Product Backlog. Making it optional can only happen by having something in place to ensures that this inspect and adapt opportunity remains intact. Otherwise the results will be disastrous.
Having said all of this. Right here right now there’s still that single source of Scrum truth — The Scrum Guide. And this still has the Sprint Review as immutable part of Scrum.
Who knows what the future brings, but until then Scrum isn’t Scrum without the Sprint Review.
