Sprint Review

The Sprint Review

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 Increment

  • The Product

  • The Market, including any competitors

  • The challenges/headwinds faced

  • What the best next-steps are

  • Stakeholder satisfaction

  • etc.

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.

Ineffective or long Sprint Planning sessions

I’ve spoken to a number of people recently who have been struggling in their Scrum teams, specifically with planning sessions feeling ineffective and taking up too much of the team’s time.

When planning sessions take too long, there are a few common causes that I have come across, but at the top of the list is that the Sprint Review isn’t covering everything that it should. I’d estimate that around 80-90% of the Scrum teams I come into contact with call the Sprint Review a “demo” which is usually reflective of what their Reviews consist of and where the focus of this session lies.

My own team was struggling with this element until fairly recently, so I have experienced first hand the impact that ineffective Sprint Reviews can have on Sprint Planning.

The Sprint Review is explained fully on page 11 of the Scrum Guide if you wish to re-familiarise yourself fully, but it is specifically this action that I find is typically forgotten:

“The entire group collaborates on what to do next.”

“The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.”

If the Scrum Team and stakeholders aren’t reviewing and revising the product backlog as part of the Sprint Review there is a high probability that the team are entering Sprint Planning without a clear understanding of the Product Backlog Items that are likely to be included in the Sprint. This means that they are coming across the items for the first time when they should be firming up their understanding enough that they can assert with relative confidence the effort and time required to complete the item. Instead, they are wrapping their head around the high level concept before hurriedly making a sizing decision.

Of course, the team should be aware of the backlog prior to the Sprint Review, but teams that aren’t perform the appropriate actions are in all likelihood also not performing adequate Backlog Refinement.

This may mean that you need to make your Sprint Review slightly longer, but the additional focus in this area may well be all that the team requires. Chances are though, that the improvements your planning sessions (and consequently the entire Sprint) will be worth a little bit more time in the Review — remember, transparency and understanding are fundamental parts to your team’s success so don’t be afraid to invest time improving them!