(R)Evolutionary Agility: What the hell is a Sprint Review?

This is the last post before New Year’s Eve: so it is time to “review” the year which is going to give us the gift of enjoying the last days in its last month. That’s why I decided to spend few lines about Sprint Review.

2013 has been for this blog quite an interesting journey of 22 articles: I learned a lot by publishing them and I hope the 9000 readers (R)Evolutionary Agility had in the last 2 years have learned something as well. I wish you all an exciting and joyful 2014!

Some weeks ago I delivered a 3-days course for Scrum Masters. I usually visualize the agenda as a backlog of subjects we prioritize together throughout the training.

During a coffee break a guy approached me and asked: “I recognize the different ceremonies in the agenda, but I never heard about Sprint Review. We normally do a Sprint Demo: is it the same thing?”

“It depends on what you do in your Sprint Demo. Can you tell me more?”, I answered.

“Well, at the end of the iteration our Program Manager calls for a Demo meeting. All Scrum Masters are attending and reporting what we have been doing during the past 3 weeks”.

“So what are you demoing then?, I asked.

“We’re presenting a powerpoint slide set, showing a detailed report of the different activities during the Sprint, who was doing what and how much time was spent given the people allocation”.

Again? Yet another manipulated buzzword!?

And yet another empirical evidence of how an organization can produce so powerful antibodies to resist and protect itself from cultural change bacteria.

So let’s see if we manage to inject some virus of learning and growing mindset: these are usually quite effective in spreading willingness for improvement.

Let’s start from some why: why is a Sprint Review important? What is the purpose it is meant to serve?

Scrum is grounded in empirical process control theory and therefore uses an iterative and incremental approach to optimize the path towards a certain business goal by means of fast feedback loops.

As any other implementation of empirical process control, it is based on 3 pillars:

Transparency

All information necessary to handle the process must be available to those handling the process

Inspection

The different aspects of the work must be inspected frequently enough so that unacceptable variances can be detected. Of course the skill and diligence of the people inspecting the work resul matter.

Adaptation

If the inspector determines from the inspection that one or more aspects of the process and the resulting product are unacceptable, the inspector must adjust the process or the material being processed. The adjustment must be made as quickly as possible to minimize further deviation.

The Sprint Review meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint.

The Sprint Review is then an important learning point and a fundamental step in the empirical process control applied by Scrum. That’s why calling it just “demo” is mislabel, since this word does not capture the real intent of this ceremony. Let’s analyze what might be the learning points for the main actors:

The Product Owner and key stake-holders learn what is going on with the product, what are the results of the Sprint and check whether those results are able to bring the whole Scrum Team closer to the Product Vision. The Sprint result will have anyway impact on the Product Backlog for the next Sprint Planning: new stories might be added, changed or removed and prioritization might change.

The Development Team learns what is going on with the Product Owner and the market. They also learn whether the Sprint Result validated the assumptions they made during the Sprint Planning. For that reason it might be useful to review the estimates, to check whether they got confirmed after the story was actually built: in this way the team know how to estimate better and build a better baseline to relate further estimations. They’d better review also the different team metrics and the Sprint Burndown Chart to gather interesting data for the coming Sprint Retrospective. Review of Team Working Agreements and Definition of Done will indicate the team whether what they learned during the Sprint can affect the team’s rules or their quality criteria.

For these reasons, the most important element of the Review is the conversation and collaboration between the Team and Product Owner to learn the situation, to get advice, and so forth.

It is a public ceremony: the Product Owner, Team members, the ScrumMaster, plus customers, stakeholders, experts, managers and anyone else interested is allowed to attend and anyone present is free to ask questions and give input. The Scrum Master will work to maximize the learning of all participants.

Even though calling the Review just “demo” doesn’t really make the point, the demo is anyway an important part of it. But what does it make sense to demo?

Let’s have a look at some of the Principles in the Agile Manifesto:

1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

7) Working software is the primary measure of progress.

It doesn’t mention powerpoint slides, right? J

So the only demo which makes sense is showing an installation of an integrated potentially shippable product increment. BTW, the Product is the only language which everybody, from business to developers will understand the same way.

Remind: spend as little time as possible on preparing for the demo. If you need to spend a lot of time there must be something wrong somewhere.

If you read and liked this article, I have a question for you: