No more sprint reviews!
For some teams, the sprint review has become meaningless and it’s time to consider stop doing them. Am I breaking Scrum? Sure, I suppose I am. Hear me out.
The Purpose of the Sprint Review
The purpose of the sprint review is for the whole team to get feedback on what has been done and delivered. It is an opportunity for clients and stakeholders to get involved to provide feedback to create new product backlog items that are either new or adjustments to what was recently developed. The feedback is the ‘inspect and adapt’ the backlog and finalising priorities for the coming sprint.
Holding a sprint review at the end of the 2 week – 4 weeks sprint is too I find too late for many teams when feedback that is provided and received at the end of the sprint.
The idea of the sprint review was an Agile practice formalised in Scrum, published in 1995 in the original paper presented by Jeff Sutherland and Ken Schwaber at the OOPSLA conference. During a time when the world was still uncovering better ways of delivering software and focus was around ensuring valuable increments of working software.
So, what happens when your teams are delivering value continuously through the sprint? The teams are getting feedback early, often and on an ongoing basis. Client feedback is fed back to the team often during a sprint, backlogs are inspected and adapted, work is refined and adjustments are made during the sprint.
Now, this has completely changed the nature of the sprint review.
Consider the situation of a team that delivers products or code to production a few times a day or multiple products over a few days. For great teams, this is pretty normal.
What is the discussion going to be like in their sprint review at the end of a ten-day sprint? When we have delivered over 30 different things, receiving continuous client feedback and Product Owner feedback.
In the world of continuous delivery, seeking feedback from stakeholders in an end-of-sprint review is too late–users are already using it, marketing it, promoting it, interacting and watching it.
So, what should we do then?
For teams also feel the sprint review is too late, then they should be getting feedback early, often and in small doses. As soon a something is done, team members and the Product Owner should show it to a few stakeholders who need to see it before it’s released. Often this could be the requestor of the deliverable and the Product Owner if they’re not the same person.
One or two of the team members who worked on the deliverable arrange a quick demo to show it off, and to see if it meets the requestor’s expectations, it’s what was expected. And rinse and repeat.
The idea of showing increments of value to get feedback early and often will stop teams from going too far down a rabbit hole. If there are lots of rabbit holes then they can identify it without going into them.
So this leads to the question do will still need a sprint review when we are working like this? When we are delivering frequently and, often?
A sprint review is a chance for the team, stakeholders, business sponsor to discuss priorities and the plans for what we should do in the next sprint, priorities in the backlog and kill backlog items.
I like to use the sprint review as a learning aspect of being the only time everyone sees everything. Seeing delivered and talk about what they learnt about delivering the piece of work.
I don’t feel like the sprint review as a mandatory element of Scrum within the context of teams delivering continuously. Though many teams, it remains appropriate and as super useful.
The idea of sprint reviews and people questioning them around the world are Mike Cohn in “Are Sprint Reviews Necessary”, John Cutler and Joshua Kerievsky.
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
Having said the single source of Scrum truth is — The Scrum Guide. And this still has the Sprint Review as a required part of Scrum.
