A little over a year ago I spoke about Ineffective or long Sprint Planning sessions, and explained that ineffective Sprint Reviews were often an underlying cause. I'd like to dive into that a little more and explain what a good Sprint Review might look like.
"A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed." — it's a chance for the Scrum Team, stakeholders and other business people (invited by the Product Owner) to get together and take stock of the current situation.
Part of the Sprint Review is likely to take the form of some sort of demonstration of the work that has been done, which is the part that most teams overly-focus on (some even calling the whole event a "demo" rather than a review) — but there should be much more to a Review than that, and a lot more value available to teams should they wish to extract it.
The Scrum Guide describes the result of the Sprint Review as a "revised Product Backlog".
If you think of every Scrum event as an opportunity to inspect and adapt, we can see the Review as an opportunity to inspect several key things:
The Market, including any competitors
The challenges/headwinds faced
What the best next-steps are
You may choose to adapt several things as a result, but it is primarily the Product Backlog that should be your focus. You can easily imagine why any of the things listed above could result in a change; if feature x is proving more challenging implement than expected, but a competitor has just released feature y, perhaps we want to change direction slightly in response to that. Stakeholder feedback can frequently prompt a re-ordering of backlog items to help maximise the value delivered sooner.
Without a well-functioning Sprint Review, some of these inspections may take place in other meetings, but there's a few problems with that approach:
One of the aims of Scrum is to reduce the need for other meetings, and thus reducing waste.
If some people aren't included in these discussions, what steps will be necessary to maintain appropriate transparency?
In all likelihood though, if the Sprint Review hasn’t been effective in providing the necessary inspection/adaption, it is unlikely that something else will — teams that omit part of the process tend not to compensate for it elsewhere. However, a common pattern is ‘process bloat’ where more and more processes & meetings are added to try and cover everything that needs to be covered. Before long, things that should become simple, like adding a new item to the product backlog or prioritising the reduction of technical debt require a series of meetings and handoffs. As well as being slow & wasteful, the greater risk is that work that needs to be done doesn’t get done because it’s simply too difficult to get it brought into scope.
The consequences of inadequate Reviews will vary, but it is a safe bet that they will be spread both far and wide. You can of course expect issues connected to all of the inspection points; poor awareness of market trends, unsatisfactory value being delivered to stakeholders, etc. but you should also expect issues with, for example, team morale as people feel in the dark and perhaps being pulled in different directions to what they expect.
My advice to teams is to leverage all that they can from frameworks like Scrum before trying to create their own solutions to problems; stand on the shoulders of giants and leverage their learning, rather than re-inventing the wheel. Exceptions to this are far less common than many believe.