Sprint Reviews in Practice

First published in The Agile Zone, 23 May 2013

But to my mind, though I am native hereAnd to the manner born, it is a customMore honor'd in the breach than the observance - Hamlet Act 1, scene 4, 7–16

Let me tell you about a seat-of-the-pants agile maturity model you can apply to organizational transformations. It's simple: all you have to do is assess how many of the requisite practices are actually being observed. Scrum teams, for instance, can be assessed in this rough-and-ready way by looking at which of the Scrum events are genuinely happening. It's certainly a primitive measure but it relies on the fact that new ways of working don't always bed in evenly, and it's quite common for some techniques to be short-changed or elided altogether. In Scrum, you're likely to find that certain events will gain traction while others are a real struggle for teams to come to terms with. For example, most teams are able to organize a daily stand-up with at least a degree of consistency. The time at which the stand-up occurs might be vague in the the early days, and attendance might well be shaky, but in my experience I find that it usually happens. More often than not, there'll be enough for me to work with and to help the team improve.

Sprint Planning is another comparatively easy one. I don't mean that planning itself is easy...it isn't, it's bloody hard. What I mean is that it is fairly easy to make sure that a Sprint Planning event happens. At the beginning of each Sprint, teams can usually be made to assemble without too much of a struggle, and they'll make some sort of attempt to decide what to do in the next time-box. The resulting Sprint Goal might be pixie dust, and the Sprint Backlog nothing more than a cynical commentary on a lost cause, but the point is that it usually happens. Again, I find that something is generally there for me to build on so I can help the team improve.

Sprint Reviews are rather more problematical. The teams will certainly know they are meant to do them, because I make it quite clear from the beginning that ditching reviews is not an option. Yet I also know that if my back is turned, this event is prone to being tipped over the side in the heat of battle, while stand-ups and planning sessions are a bit less likely to suffer this treatment. So what is it about reviews that leads to their devaluation by teams that are new to agile practice? First of all let's consider what a Sprint Review is meant to be in the first place, and then we can try to figure why it is more honored in the breach than in the observance.

What is actually being reviewed?

At the beginning of a Sprint - during planning - a team will undertake to deliver something of value to the Product Owner. A Sprint Goal will be agreed between them, and they will negotiate to deliver a portion of the product requirements which is most relevant to the goal by the end of the Sprint. The entire set of product requirements is represented as an ordered list called the Product Backlog. The Sprint Backlog is the portion that the team will have agreed to action.

Each requirement must have clear acceptance criteria, and in addition the team must have a clear understanding of what it means for work to be done. Taken together, the Sprint Backlog and the Sprint Goal represent a forecast of the work that will be done in the Sprint. Taken together, the clear definition of done and the acceptance criteria will keep the risk of having to do any rework as small as possible. The team will plan to deliver the work so it meets their definition of done and also the specific acceptance criteria that have been set for each requirement.

At the end of each Sprint the team will meet with the Product Owner and look back upon what has actually been delivered in accordance with those terms. A demonstration of the deliverables is often the highlight of a review. This is an opportunity to show that the work has indeed been done, that the acceptance criteria have all been satisfied, and that the Sprint Goal has been met. It is an opportunity to satisfy the Product Owner that value is being provided, or to adapt the Product Backlog - or reconsider the project - if it is not.

Confusing Reviews with Retrospectives

The review is meant to look at what has been produced and still remains to be done. It isn't meant to address the method of how work is being done. The how is the topic of the Sprint Retrospective - an "inspect and adapt" opportunity for the team's implementation of Scrum itself.

It's very common for new teams to slur reviews and retrospectives together, and quite a few long-standing teams also make this error. It's another indicator of how far along a team genuinely is in its agile transition. While it's certainly possible to run a review and a retrospective back-to-back, the two events should nonetheless be kept quite separate and distinct from each other. I generally recommend doing the review before the retrospective, because the former can produce ideas for consideration in the latter.

A mature team will be able to think about the work they do in isolation from their implementation of the Scrum process, and vice-versa. For example, in a retrospective they'll be able to reflect on how agile methods were used on other projects and how those lessons can be brought to bear on the current one. They'll keep the review focused on the work at hand. The Sprint Review will focus on what was done and remains to be done, but won't spill over into how work is done.

How is a Sprint Review conducted?

Here's the format of how a typical Sprint Review will be conducted. Reviews have the potential to be a bit dry, so the imperative is to keep them brisk and as enjoyable as possible. The Scrum Master is the guardian of the Scrum process and it is his or her responsibility to make sure that the review is carried out properly. A review should be time-boxed to no more than 4 hours for a one-month Sprint, or 2 hours if the Sprint lasts 2 weeks.

Backlog grooming as a separate event

A team should never be surprised by the work the Product Owner wants them to do. It's important that the team keeps sight of the Product Backlog as requirements change, so they don't go into a planning session and find themselves dumbfounded by the work they are being asked to deliver. This review of the backlog can certainly be done in the Sprint Review, but since the review happens at the end of a Sprint, and planning happens at the start of the next, there's not much opportunity to resolve any issues. A strong case can be made for having at least one separate backlog grooming activity during the Sprint.

Backlog grooming is an opportunity for the team to see what they are likely to be asked to do in the next Sprint, to highlight any concerns, and to make recommendations. Ideally it will happen before the Review so enough time is allowed for problems to be ironed out. A team may organise multiple backlog grooming sessions if it helps planning to go smoothly. These sessions are also an opportunity for the Product Owner to decide on a goal for the next Sprint, to determine the priority of each item in the Product Backlog, and to discuss any concerns about feasibility or implementation with the team in advance of planning. The team should also be prepared to give tentative estimates following discussion of this work.

Sprint Review Antipatterns: what shouldn't happen

We're beginning to see why a Sprint Review is easily knocked off the agenda. There are many things that can go wrong or which are subject to misunderstanding, and which will make the perceived value of reviews unclear, or even undesirable. Let's summarize these problems so we can conclude why they are so often missed, and then see what we can do to increase their chances.

Common problems with reviews:

Why Reviews are often missed

Well, it's clear that there's no great mystery about this. Inexperienced teams will often try to short-change reviews for three basic reasons:

However, there's another reason why Sprint Reviews are often missed: the Product Owner may not care enough to attend. It sounds like a strange thing to say, but the fact is that many Product Owners are assigned to the role without even being genuine stakeholders in the first place. They get the job because of related domain knowledge or because they have occupied a management role in the past. This is an antipattern of product ownership and it raises questions about whether or not a project should go ahead if its interests cannot be represented properly.

How to make Sprint Reviews happen

Here's what you can do to increase the chances of a Sprint Review taking place and of being conducted in a professional manner.