A Common Misconception

This basic misunderstanding leads to a number of erroneous assumptions about the development process itself. Chief among them is that work done during the sprint may not be released to the customer before the sprint is over.

The mistaken view of the Sprint Review holds that it is akin to a “final quality control inspection” of the product before it is “accepted” by the Product Owner. The Development Team demonstrates the results of the work it has performed. All the PBIs accepted by the team must be shown to be in place and working properly. Product Owners may accept or reject them based on how well they conform to the requirements. Any accepted PBIs are then considered releasable to the customers at a time of the Product Owner’s choosing. Any rejected items go back on the Product Backlog for reprioritization and rework during a future sprint.

The True Purpose of the Sprint Review

There are several assumptions about the Scrum Framework that are being made here, and they are not accurate.

First of all, The Scrum Guide states that the purpose of a sprint is to “create a done increment of product.” It further states that the Sprint Review inspects that done increment. The increment is done if it complies with the definition of done. If the increment has satisfied the definition of done, then there is no need for the Product Owner to accept it in a formal way. That done increment needs no such formal inspection.

The second invalid assumption is that a PBI cannot be considered done until the end of a sprint. In fact, the opposite is true. If PBIs are small, they can often be completed (and done) in just a few days. The Product Owner makes a business decision regarding to when to release the work to the customers. If the Product Owner decides to do so, there is no reason why that completed item can’t be released immediately.

Some people feel the Extreme programming technique of continuous integration, continuous deployment (CICD) is incompatible with Scrum. Once again, the opposite is true. CICD calls for the automation of testing and deployment. Many large software companies deploy their changes to their production environments many times per day. They have automated the process of validating software against the definition of done. These companies can and do use the Scrum Framework.

The Sprint Review is a demonstration and discussion of the Sprint Increment and does not depend on whether portions of that increment are already in customer hands. The point is to review the new version of the product after the work of the sprint is finished. It is not relevant whether some or all of the features and components are in “production.”

The purpose of the Sprint Review is not to ask: Is this increment working properly? Rather, the purpose is to note: This is what the product does now. In light of this, what else could it do?

At the beginning of each sprint, the version of the product that contains the changes to which the Product Owner and the developers agree only exists in the imaginations of everyone concerned. At the beginning, the finished product is imaginary. During the sprint, the Development Team changes the product from an imaginary one to a real one. The purpose of the Sprint Review is to inspect that new real product, react to it, and stimulate a discussion of further enhancements.

The primary beneficiary of the Sprint Review is the Product Owner. The Product Owner examines the value the product represents and uses it to stimulate ideas about how the product can be more valuable. These ideas turn into new PBIs. The Product Owner may ask for outside help in examining this new version of the product, and often invites stakeholders and customers to participate in the sprint review and the discussions that ensue.

An Example

An example of an effective sprint review occurred during a software development project that benefitted a not-for-profit organization near San Francisco, California. The organization conducted summer camps for children with cancer and other serious medical conditions. Their grounds contained a large garden full of exotic plants. A donor had given them a number of Apple iPad tablets and they wished to use the tablets as an electronic guide to the garden plants.

During the Sprint Planning Meeting, it was decided to create a database of plant information and display it on the iPad screens. A separate function would allow for the printing of barcode labels for the plants. When the finished product was ready, a user would be able to take a picture of a barcode label with the iPad camera and information about that plant would be displayed.

The Development Team got to work and two weeks later they had something to show. The Product Owner invited representatives of the not-for-profit organization to attend the sprint review.

When the sprint review got underway, the developers showed what they had done. They had not been able to print out the barcode labels yet, but they were able to project a label image on the wall. They then used the iPad camera to read the label, and information about a plant popped up on the iPad screen.

The representatives of the not-for-profit organization were thrilled. “Look at that! It’s only been two weeks and something is already working! My goodness.”

“And, oh! Look! There is a picture of the plant... Oh. Um, may we have more than one picture?”

The developers and the Product Owner hadn’t thought of providing for more than one picture, so they asked why more than one was needed.

The not-for-profit people replied, “Well, we want the child to recognize the plant on the iPad display, so they are sure they are getting information about the right plant. The trouble is, plants look different in the spring than they do in the fall.”

At this point the Product Owner interjected, ”Oh, so you need seasonal pictures—one each for spring, summer, fall, and winter.”

The not-for-profit people indicated that was what they wanted.

One of the developers then said, ”Okay, I get it. By the way, the iPad has a built-in calendar. Would you like us to figure out what the current season is and then display the associated picture automatically?”

The not-for-profit people asked, “You can do that? Wow!”

Another developer then asked, “Hey, would you like the iPad to talk?”

The not-for-profit people said, “What do you mean?”

The developer went on to explain, “Well, this is an iPad. It has great text-to-speech capabilities. We could put a button on the screen that says ‘Talk’ and then the iPad could read the screen out loud. Would you like us to do that?”

The not-for-profit people then said, “You mean we could use this with kids who are too young to read? We could use this with kids who can’t see? Wow!”

At the end of the sprint review, the Product Owner added a PBI about a rotating set of four pictures with the default one to be displayed keyed to the calendar date. He also added a PBI about adding a Talk button to the screen that would cause the iPad to read the screen out loud to its user. These two new PBIs greatly added to the value of the final product.

Summary

The Sprint and the Daily Scrum are events during which developers learn about and make decisions about the technical aspects of the product. The Sprint Review is an event during which the Product Owner, stakeholders, and customers learn about and make decisions about the product as it is being conceived and built. This learning process is just as important for the success of the product as it is to the technical expertise of the development team.