Scrum History — The evolution of the Sprint Review
By: Willem-Jan Ageling
Tags: Scrum, Agile, Product, Scrumhistory, Serious Scrum

Scrum History — The evolution of the Sprint Review

Scrum then and now, part 9

Scrum has been around for years. Jeff Sutherland and Ken Schwaber presented it to the world at OOPSLA in 1995. They based it on “The New New Product Development Game“ (1986) by Hirotaka Takeuchi and Ikujiro Nonaka.

Since 1995, many elements of Scrum have not changed at all. By contrast, some other parts of Scrum have continued evolving. With this series I aim to show you how radically Scrum has changed over the years. Through this I wish to achieve transparency on why certain ideas about Scrum materialised and help raise understanding on the current definition of Scrum.

With this article, it is my goal to give you an overview of the evolution of the Sprint Review throughout the years. This important event always had a significant purpose but, the implementation to inspect the Increment, and adapt the Product Backlog has evolved a lot.

The New New Product Development Game

The paper that started the ball rolling — ‘The New New Product Development Game’ — doesn’t discuss regular feedback moments. However it does bring forward interaction with the customer, as one of the ways to build in “subtle control” (as opposed to rigid control by management):

“Encouraging engineers to go out into the field and listen to what customers and dealers have to say.” — Hirotaka Takeuchi and Ikujiro Nonaka 1986

It doesn’t say how this should be established but the interaction with the user is brought forward.

The first Scrum paper — 1995

With the OOPSLA paper in 1995, Sutherland and Schwaber introduced their own adaptation of Scrum. The Sprint Review immediately got a prominent spot:

“Each Sprint is followed by a review, whose characteristics are : · The whole team and product management are present and participate. · The review can include customers, sales, marketing and others. · Review covers functional, executable systems that encompass the objects assigned to that team and include the changes made to implement the backlog items. · The way backlog items are implemented by changes may be changed based on the review. · New backlog items may be introduced and assigned to teams as part of the review, changing the content and direction of deliverables. · The time of the next review is determined based on progress and complexity. The Sprints usually have a duration of 1 to 4 weeks.” — Ken Schwaber 1995

The Sprint Review is already established quite well here. Note that the length of the Sprint can differ based on progress and complexity! And that this is determined during the Sprint Review.

SCRUM: An extension pattern language for hyperproductive software development — 1998

Oddly enough this 1998 document stepped away from the term “review”:

“At the end of each Sprint, there is a Demo to: 1. show the customer what’s going on; […] 2. give the developer’s a sense of accomplishment […] 3. integrate and test a reasonable portion of the software being developed […] 4. ensure real progress — reduction of backlog, not just more papers / hours spent […]” —Mike Beedle, Martine Devos, Yonat Sharon, Jeff Sutherland and Ken Schwaber 1998

Although called a demo there’s more brought to the table than a demo only. It is interesting to see that it was renamed to “demo”. Also interesting: the part about ‘what’s next’ is absent.

First Scrum Book 2001

The book “Agile Software Development with Scrum” spends 2 full pages on the Sprint Review. It discusses the reason for the event but also describes in detail how this event should be conducted. The book is a step-by-step approach of how to do Scrum and the part about the Sprint Review is no exception.

Notable snippets are:

“The Sprint Review meeting is a four-hour informational meeting. During this meeting, the team presents to management, customers, users, and the Product Owner the product increment that it has built during the Sprint.” — Ken Schwaber and Mike Beedle 2001

Interesting is that the team (Development Team) drives this event. Also, the introduction only emphasises the demo part of the Sprint Review. But there’s more:

“The Sprint Goal and Product Backlog are compared to the actual results of the Sprint, and reasons for any discrepancies are discussed.” — Ken Schwaber and Mike Beedle 2001

And then there’s the focus on what’s next:

“During the meeting, everyone visualizes the demonstrated product functionality working in the customer or user environment. As this is visualized, consider what functionality might be added in the next Sprint.” — Ken Schwaber and Mike Beedle 2001

The Sprint Review is (again) the place where stakeholders chip in to discuss what to do next.

First edition of Scrum Guide — 2010

The first Scrum Guide discusses the length of the Sprint Review:

“This is a four-hour time-boxed meeting for one-month Sprints. For Sprints of lesser duration, this meeting must not consume more than 5% of the total Sprint.” — Sutherland and Schwaber 2010

So the Sprint of a month has a four-hour Sprint Review, shorter Sprints are more up to the teams, as long as it doesn’t take more than 5% of a Sprint.

Then the guide discusses what is done during the Sprint Review:

The Scrum Team and stakeholders collaborate about what was just done (and what hasn’t been done);

The (development) team demos the work that is done and answers questions;

The Product Owner discusses the current Product Backlog and likely completion dates “with various velocity assumptions”;

Based on that and changes to the Product Backlog during the Sprint, they collaborate about what are the next things that could be done as input for the next Sprint Planning.

It clarifies that it’s an informal meeting to foster collaboration on what to do next. It also brings forward that this is an event where the whole Scrum Team (including Product Owner) drive the discussion. This is different than discussed in the 2001 Scrum book.

The first Scrum Guide doesn’t discuss the PURPOSE of the Sprint Review, only what is being discussed. This is a subtlety resolved later.

Second edition of Scrum Guide — 2011

It is here, in the second edition of the Scrum Guide, that we see the purpose of the Sprint Review being addressed.

“A Sprint Review Meeting is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.” — Sutherland and Schwaber 2011

It then mentions the length:

“This is a four-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints. For example, two week Sprints have two-hour Sprint Reviews.” — Sutherland and Schwaber 2011

It is basically discussed in the same way as the first Scrum Guide, but with different wording. However, the second version is much more rigid about the length. Teams can’t choose to have shorter Sprint Reviews.

What is being discussed during the Sprint Review is largely the same as mentioned in the first Scrum Guide. There’s one major exception though: the Product Owner no longer is supposed to discuss likely completion dates based on velocity. Instead it is discussed based on progress to date. The term “velocity” is removed from the Scrum Guide.

Fourth edition of Scrum Guide — 2013

In 2013 there are some subtle changes in the Scrum Guide:

“This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.” — Sutherland and Schwaber 2013

Sutherland and Schwaber felt it important to note that the Sprint Review isn’t a status meeting and stressed that feedback is key.

There are also subtle changes regarding the length:

“This is a four-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.” — Sutherland and Schwaber 2013

One-month Sprints are still 4 hours, but for shorter Sprints it can now be anything less than 4 hours. The rigidity length in the first 3 versions of the Scrum Guide is removed for shorter Sprints.

It’s also interesting to note that this version discusses the role of the Scrum Master during this event:

“The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box.” — Sutherland and Schwaber 2013

But there’s more, besides a few clarifications a number of additional topics are to be addressed:

Attendees are invited by the Product Owner;

During the Sprint Review changes to the marketplace or potential use of the product are discussed as they can impact what is the most valuable thing to do next;

Timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product is discussed.

With this the Sprint Review becomes even more important than it already was as it now also touches upon strategic product decisions. With the Product Owner inviting the participants it’s the Product Owner in the driver’s seat of the event.

Sixth edition of Scrum Guide — 2017

There’s a subtle change of the length of a one-month Sprint:

‘This is at most a four-hour meeting for one-month Sprints.” — Sutherland and Schwaber 2017

Now the flexibility that was there for shorter Sprints is also there for a one-month Sprint.

There’s also a subtle change in the quote below:

“Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.” — Sutherland and Schwaber 2017

Now that the Scrum Guide widened the scope to be a framework for any complex work this change was apparently required to make sense for non-software related Scrum teams.

Conclusion

Sprint Reviews were introduced in 1995 and have had the prominent place ever since. However, just like the rest of the Scrum framework there have been many changes to this event over the years, like:

the length of the Sprint Review;

the topics to discuss during the Sprint Review;

the ownership of the Sprint Review (Development Team vs Scrum Team vs Product Owner);

the name (it was called “demo” for a brief period!).

It makes very clear how important it is to be on top of the Scrum changes. Scrum evolves.