Near the end of the sprint, the team conducts two important inspect-and-adapt activities: the sprint review and the sprint retrospective. The sprint review focuses on the product itself. The sprint retrospective, on the other hand, looks at the process the team is using to build the product.
During sprint planning we plan the work. During sprint execution we do the work. During sprint review we inspect (and adapt) the result of the work (the potentially shippable product increment). The sprint review occurs near the end of each sprint cycle, just after sprint execution and just before (or occasionally after) the sprint retrospective.
The sprint review gives everyone with input to the product development effort an opportunity to inspect and adapt what has been built so far. The sprint review provides a transparent look at the current state of the product, including any inconvenient truths. It is the time to ask questions, make observations or suggestions, and have discussions about how to best move forward given current realities.
All Scrum team members (product owner, ScrumMaster, and development team) should be present at every sprint review so that they can describe what has been accomplished, answer questions, and enjoy the benefits of firsthand feedback.
Confirm That the Sprint Work Is Done
At the sprint review, the team is allowed to present only completed work—work that meets the agreed-upon definition of done. This implies, then, that sometime before the sprint review, someone has determined whether or not each backlog item is done; otherwise, how would the Scrum team know which items to present?
Demonstrating the product increment becomes the focal point for having an indepth conversation. Observation, comments, and reasonable discussion regarding the product and direction are strongly encouraged among the participants. The sprint review, however, is not the place for deep problem solving; that type of work should be deferred to another meeting.
Vigorous discussion allows participants who aren’t on the Scrum team to ask questions, understand the current state of the product, and help guide its direction. At the same time, the Scrum team members gain a deeper appreciation for the busi- ness and marketing side of their product by getting feedback on the convergence of the product toward delighted customers or users.
Through demonstration and discussion, the team is able to ask and answer questions, including the following:
- Do the stakeholders like what they see?
- Do they want to see changes?
- Is what we’re building still a good idea in the marketplace or to our internal customers?
- Are we missing an important feature?
- Are we overdeveloping/investing in a feature where we don’t have to?
Sprint Review Issues
Let’s say, however, that during the sprint review a senior-level stakeholder disagrees—he believes the product backlog item is not done. While that feedback is valuable, I would still say that if the product owner declared the original work done, it is done.
The sprint review needs to be viewed as a critical inspect-and-adapt activity, one that is worth people’s time to attend. Still, some organizations suffer from sporadic attendance.
Large Development Efforts
If you have a larger development effort with multiple Scrum teams, it might make sense to consider doing a joint sprint review. This is simply a review that includes the work completed by multiple highly interrelated teams.
Scrum provides two inspect-and-adapt opportunities at the end of each sprint: the sprint review and the sprint retrospective. In the previous chapter I discussed the sprint review, where the team and stakeholders inspect the product itself. Let’s now turn our attention to the sprint retrospective, where the Scrum team examines the process used to build that product.
Inside the timebox of the retrospective, teams are free to examine what’s happening, analyze the way they work, identify ways to improve, and make plans to implement these improvements. Anything that affects how the team creates the product is open to scrutiny and discussion, including processes, practices, communication, environment, artifacts, tools, and so on.
- What worked well this sprint that we want to continue doing?
- What didn’t work well this sprint that we should stop doing?
- What should we start doing or improve?
Because the sprint retrospective is a time to reflect on the process, we need the full Scrum team to attend. This includes all members of the development team, the ScrumMaster, and the product owner. The development team includes everyone who is designing, building, and testing the product.
A group of people can all experience the same event and yet interpret it quite differently. To successfully inspect the current sprint, it is important to get everyone on the same page so that they have a shared context.
When establishing a shared context, therefore, it’s imperative that you first ground the retrospective in an objective, big-picture view of the sprint. After getting everyone in a talking mood, share objective data, such as committed PBIs, PBIs completed, number of defects, and so on.
Creating an event timeline is a simple yet powerful way to generate a shared artifact that visually represents the flow of events during a sprint. Events could include “Busted the build,” or “Interrupted to fix production failure,” or “Salina returned from holiday.”
A common approach is to draw a timeline on a wall or whiteboard and have the participants put cards (or sticky notes) on the timeline representing meaningful events that occurred during the sprint. Distributed teams could do the same exercise using an online-shared whiteboard.
The event cards are placed on the timeline in chronological order. This temporal view of events provides excellent visibility into the flow of activities during the sprint and also provides a context for quickly identifying missing or forgotten events. To help visually categorize events, many teams use a variety of colored cards. Some do this to represent different event types (for example, green is a technical event, yellow is an organizational event, red is a personal event). Other teams use colors to represent feelings or energy levels (for example, green is a positive event, yellow is a neutral event, and pink or red is a negative event).
Many teams create an emotions seismograph as a complement to their event timeline. This is a graphical representation of the emotional ups and downs of the participants over the course of the sprint.
To create the seismograph each participant is invited to draw a curve showing how she felt or what her energy level was like over the course of the sprint. It is frequently convenient to draw the seismograph directly under the event timeline so that the two sets of data can be visually correlated. Later, the participants can mine this data for interesting insights for process improvement.