…the Production Episode is over.
✥ ✥ ✥
There must be closure on the state of a product after development is over, and having completed a checklist of anticipated outcomes doesn’t alone ensure that the product has come as far as necessary, or that the team will take the appropriate next steps in development. A Development Team works as an Autonomous Team and a Self-Organizing Team, producing Regular Product Increments, completing Product Backlog Items (PBIs) as they understand them, in light of a Sprint Goal that provides context and focus.
The Product Owner and the Development Team work together to deliver value to the organization by creating a Potentially Shippable Product Increment. Development Team members generally work among themselves during the Production Episode, but they are accountable to the Product Owner and other stakeholders to make sure they have developed the right thing. Left to their own impressions for too long, they may stray from the intent of the Product Vision.
Good Product Owners can concretely envision the Product Increment that they ask the team to build during Sprint Planning. Even though this vision stands on thorough planning and discussion with the Developers, to the level of being an Enabling Specification, one can’t have perfect foresight when building a complex product. Concrete implementations almost always raise questions beyond those that arise while envisioning the product or while discussing it with the team. And there is always the possibility that communications between the Product Owner and the team loses information, or that Product Owners don’t communicate all of their tacit assumptions and aspirations for the product.
To inspect what is really going on you need transparency and the only way to get that is by inspecting working product, rather than by just checking off items on the Sprint Backlog, for example (, p. 56). Even checking off a list of stipulations for the Product Increment isn’t enough, because such lists are always necessarily incomplete because of the possibility of latent and emergent requirements, that is, of unknown unknowns. It is also necessary to establish a Community of Trust.
End the Production Episode with an event to assess the status of the product and to learn about end user needs, risks, opportunities, problems and likely completion dates to ensure product is moving in the direction of Greatest Value. The Development Team, the Product Owner, and other invited stakeholders attend the event. They work together both to discuss what parts of the Product Increment are and are not ready for deployment, about lessons learned about the product during the Sprint, and about tentative future product plans. The group ideally achieves consensus about deployment decisions and future plans, but the Product Owner has the final say in these matters.
A good way to address problems in complex development is with short feedback loops so that stakeholders can assess the solution and the team can adapt quickly without going too far astray. The Sprint Review is the focal point of deliberation and feedback during the Sprint cycle. The Product Owner can invite any stakeholder to the Sprint Review and is well-advised to invite key end users and to elicit their feedback.
The participants inspect the product not only to learn about the suitability of the current product increment for delivery, but to provide information to shape future work (such as reordering the Product Backlog).
The event should be timeboxed to a maximum of three hours. The focus is on assessing the product. The Development Team should not spend more than about 30 minutes specifically preparing for this event. Too often a team will prop up the product with temporary supporting structures to make it work well for the Sprint Review, or will spend time trying to “impress” the stakeholders with a sophisticated presentation. There is very little opportunity to be convincing here: the product stands on its own. The team demonstrates the product in an environment that approximates that of an end user, without any special “demo support,” and without any props that could make the product appear better than it is. A good rule of thumb is: No PowerPoints® (unless your product is PowerPoint).
Typical activities for this event may include:
It is good for the Product Owner to adopt a vulnerable posture and to hear whether the team endorses and trusts the decisions and directions by which he or she is directing the team, particularly with respect to the product direction and dealing with technical debt and product quality. This helps reinforce the Community of Trust.
✥ ✥ ✥
A Sprint Review creates information for all parties: the Product Owner and stakeholders learn about the status of the product concerning possible shipment and future direction. The Development Team learns how well they met the expectations of the stakeholders, giving them more information for their Sprint Retrospective.
A good way to validate status and get feedback on the PBI(s) is by having users explore them hands-on (, ff. 66). For example, members of user focus groups who support the team with different market perspectives can offer on-the-ground insights. Another example is that of a game studio that have gamers play their game to get feedback. Such assessment during the Sprint Review is not a substitute for, say, a full acceptance test; however, Enabling Specifications can sometimes reduce the need for such extensive testing. (Scrum’s iterative development is not an excuse to omit long-running stability or endurance tests, if the Product Owner can empirically justify the need for them.) Thoughtful users nonetheless appreciate the opportunity to be listened to, and engaging them in this review builds trust. End users may indeed notice lapses between the product and their expectations, and in any case can provide great input as the group discusses future product directions.
Many Scrum adherents view the Sprint Review as the main mechanism of agile feedback in Scrum, bringing to mind the usual forces of emergent requirements and market changes, change in business conditions, and so forth. There may be a bit of that. But a Product Owner and other stakeholders are unlikely to always be able to assess, in a three-hour meeting, whether a complex product increment really does meet the intended need or not. More realistic and honest insight comes from trying to use the product in a more realistic application setting and over a more protracted period of time. However, the Product Owner and other stakeholders can and will notice misaligned assumptions and perspectives between what people believed they agreed to at Sprint Planning, and what the Development Team delivers. Such discrepancies come less often from emergence or evolution, or from a change in the mind of the customer, than from problems in the process. One of the main functions of the Sprint Review is for the team to note what process lapses allowed them to deliver something the customer did not expect, and to carry this knowledge forward into the Sprint Retrospective.
A Sprint Review is an opportunity for the team to reflect on their accomplishments during the past Sprint, which contributes to growth in Product Pride. A Sprint Review can be a form of celebration if the team reaches a particularly noteworthy goal, or just for the sake of celebrating now and then for its own sake. A company in Finland would occasionally have a Sprint Review in a sauna, with good food and drink, going late into the evening. The event covered the perfunctory agenda items but the real focus was for the team to celebrate their work together. (Thanks to Jukka Järvelä for this story!)
 Ken Schwaber. Agile Project Management with Scrum. Redmond, WA: Microsoft Press, 2004, p. 56.
 John Kolko. “Design Thinking Comes of Age.” In Harvard Business Review 93(9), Sept. 2015, ff. 66.
Picture credits: https://upload.wikimedia.org/wikipedia/commons/8/89/Members_of_the_Women%27s_Royal_Naval_Service_sampling_the_Christmas_pudding_at_Greenock_in_Scotland%2C_19_December_1942._A13392.jpg (public domain).