Chapter 5

Showcasing Work, Inspecting, and Adapting

IN THIS CHAPTER

Showcasing work and collecting feedback

Reviewing the sprint and improving processes

At the end of each sprint, the scrum team gets a chance to put the results of its hard work on display in the sprint review. The sprint review is where the product owner and the development team demonstrate to the stakeholders the sprint’s completed and to market functionality. In the sprint retrospective, the scrum team (the product owner, development team, and scrum master) review how the sprint went and determine possible improvement opportunities for the next sprint. Underpinning both events is the agile concept of inspect and adapt, which Chapter 2 in Book 4 explains.

In this chapter, you discover how to conduct a sprint review and a sprint retrospective.

The Sprint Review

The sprint review is a meeting to review and demonstrate the shippable and valuable functionality that the development team completed during the sprint, and for the product owner to gather feedback and update the product backlog accordingly. The sprint review is open to anyone interested in reviewing the sprint’s accomplishments. This means all stakeholders get a chance to see progress on the product and provide feedback.

The sprint review is stage 6 in the Roadmap to Value. Figure 5-1 shows how the sprint review fits into agile product development.

© John Wiley & Sons, Inc.

FIGURE 5-1: The sprint review in the Roadmap to Value.

The following sections show you what you need to do to prepare for a sprint review, how to run a sprint review meeting, and the importance of collecting feedback.

Preparing to demonstrate

Preparation for the sprint review meeting should not take more than a few minutes at most. Even though the sprint review might sound formal, for agile teams, the essence of showcasing is informality. The meeting needs to be prepared and organized but doesn’t require flashy materials. Instead, the sprint review focuses on demonstrating what the development team has done.

If your sprint review is overly showy, ask yourself whether you’re covering up for not spending enough time developing. Get back to working on value — creating a working and shippable product. Pageantry is the enemy of agility.

The preparation for the sprint review meeting involves the product owner and the development team, facilitated by the scrum master as needed. The product owner knows exactly what the development team completed in the sprint because he or she was working alongside them to accept or reject the items completed as valuable and shippable. The development team needs to be ready to demonstrate completed, shippable functionality.

The time needed to prepare for sprint review should be minimal — usually no more than 20 minutes — just enough to make sure everyone knows who is doing what and when, so the demonstration goes smoothly.

Work not delivered has no business value. Within the context of a single sprint, shippable functionality means that the development team has satisfied their definition of done for each requirement, and the product owner has verified that the work product meets all acceptance criteria and could be released, or shipped, to the market if the value and timing are right for the marketplace. The actual release may be at a later time, per the communicated release plan. Find out more about shippable functionality in Chapter 4 of Book 4.

For the development team to demonstrate the functionality in the sprint review, it must be complete according to the definition of done. In other words, the product increment is fully

• Developed
• Tested
• Integrated
• Documented

As user stories are moved to a status of done throughout the sprint, the product owner and development team should check that the product meets these standards as well as the user stories’ acceptance criteria. This continuous validation throughout the sprint reduces end-of-sprint risks and helps the scrum team spend as little time as possible preparing for the sprint review.

Knowing the completed user stories and being ready to demonstrate those stories’ functionality prepare you to confidently start the sprint review meeting.

The sprint review meeting

Sprint review meetings have three activities: Demonstrate and showcase the scrum team’s finished work, allow stakeholders to provide feedback on that work, and make product adaptations based on reality and stakeholder feedback. Figure 5-2 shows the different loops of feedback a scrum team receives about a product.

© John Wiley & Sons, Inc.

FIGURE 5-2: Agile project feedback loops.

This cycle of feedback repeats throughout the project as follows:

• Each day, development team members work together in a collaborative environment that encourages feedback through peer reviews and informal communication.
• Throughout each sprint, as soon as the development team completes each requirement, the product owner provides feedback by reviewing the working functionality for acceptance. The development team then immediately incorporates that feedback, if any, to satisfy the user story’s acceptance criteria. When the story is complete, the product owner gives final acceptance of the functionality created for the user story, according to the user story’s acceptance criteria.
• At the end of each sprint, project stakeholders provide feedback about completed functionality in the sprint review meeting.
• With each release, end-customers provide feedback about new working functionality.

The sprint review usually takes place later in the day on the last day of the sprint, often a Friday for a sprint that starts on a Monday. One of the rules of scrum is to spend no more than four hours in sprint review for a one-month sprint, so you usually spend no more than one hour in a sprint review meeting for every week of the sprint, as shown in Figure 5-3.

© John Wiley & Sons, Inc.

FIGURE 5-3: Ratio of sprint review meeting to sprint length.

Here are some guidelines for your sprint review meeting:

• No slides! Show actual working functionality. Refer to the sprint backlog if you need to display a list of completed user stories.
• The entire scrum team should participate in the meeting.
• Anyone who is interested in the product may attend. The product stakeholders, the summer interns, and the CEO could all theoretically be in a sprint review. Customers may also be invited whenever available.
• The product owner introduces the release goal, the sprint goal, and the new capabilities.
• The development team demonstrates what it completed during the sprint. Typically, the development team showcases new features or architecture. When negative or critical feedback is given, resist the temptation to become defensive because it will discourage stakeholder feedback.

• The demonstration should be on equipment and environments as close as possible to the planned production environment. For example, if you’re creating a mobile application, present the features on a smartphone — perhaps hooked up to a monitor — rather than from a simulator on a laptop.

• The stakeholders can ask questions and provide feedback on the demonstrated product increment.

• Do not use non-disclosed rigged functionality, such as hard-coded values and other programming shortcuts that make the application look more mature than it currently is. Rigged functionality creates more work for the scrum team in future sprints, catching up to what the stakeholders think already exists. Build trust by setting accurate expectations.

• Sprint reviews are excellent opportunities to reflect with transparency on the remaining budget to help the product owner evaluate the value of the remaining backlog.

  The formula AC+OC>V is helpful here for deciding when to stop or shift development. When the actual cost (AC) plus the opportunity cost (OC) of the future development is greater than the value (V), stop or shift development. Sprint reviews are great opportunities for concluding with stakeholders that future investment in the feature or product development should end.

• The product owner can lead a discussion about what is coming next based on the features just presented and new items added to the product backlog during the current sprint.

By the time you get to the sprint review, the product owner has already seen the functionality for each of the user stories that will be presented and has agreed that they are complete. If the product owner does not accept a user story that the development team worked on, the story doesn’t get demonstrated in the sprint review. As the product is iteratively built sprint after sprint, the sprint review is critical for ensuring alignment with the stakeholders and the product vision. Every sprint, the team should be obsessed with solving customer problems.

The sprint review meeting is valuable for the development team because they can show their work to stakeholders and customers and get their efforts acknowledged. The meeting contributes to development team morale, keeping the team motivated to accomplishing the product vision, solving customer problems, and achieving the desired business outcomes. Stakeholder confidence and trust in the development team increases as they hear them use business language during the product demonstration. (Another benefit of having stable teams is that they retain hard-earned knowledge about the customer and the business.)

Inspection is a valuable tool. The largest number of world records are broken at the Olympics. Why? Because millions of people from all over the world are watching. Sprint reviews provide a similar, albeit much smaller, stage for scrum teams. Accountability is higher because of the frequently exposed transparency of their work.

Collecting feedback in the sprint review meeting

Gather sprint review feedback informally. The product owner or scrum master can take notes on behalf of the development team, as team members often will be engaged in the presentation and resulting conversation. Capturing feedback publicly on a whiteboard, for example, validates that the feedback was given and received as intended. The transparency also prevents duplicates.

Because the sprint goal was selected based on the team’s assumptions about what the customer wanted, the sprint review offers the team the opportunity to validate their assumptions with stakeholders and, even better, customers.

Keep in mind the example project used throughout Book 4: a mobile application for XYZ Bank. Stakeholders responding to functionality they saw for the XYZ Bank mobile application might have comments such as the following:

• From a person in sales or marketing: “You might want to consider letting the customers save their preferences, based on the results you showed. It will make for a more personalized experience going forward.”
• From a functional director or manager: “Given what I’ve seen, you might be able to leverage some of the code modules that were developed for the ABC project last year. They needed to do similar data manipulation.”
• From someone who works with the quality or user experience professionals in the company: “I noticed your logins were pretty straightforward. Will the application be able to handle special characters?”

New user stories may come out of the sprint review. These stories could be new features or changes to existing functionality. Both are welcome.

In the first few sprint reviews, the scrum master may need to remind stakeholders about agile principles and practices. Some people hear the word demonstration and immediately expect fancy slides and printouts. The scrum master can shield the scrum team by managing these expectations and helping stakeholders uphold agile values and practices.

The product owner needs to add any new user stories to the product backlog and order those stories by priority value. The product owner also adds back to the product backlog any stories scheduled for the current sprint but not completed, and reorders those items based on the most recent priorities.

The product owner needs to complete updates to the product backlog in time for the next sprint planning meeting.

When the sprint review is over, it’s time for the sprint retrospective. You may want to take a brief break between the sprint review and the sprint retrospective so that scrum team members can come to the retrospective discussion fresh and relaxed. Having just completed the sprint review, the scrum team will come into the retrospective ready to inspect its processes and will have ideas for adaptation.

The Sprint Retrospective

The sprint retrospective is a meeting in which the product owner, development team, and scrum master discuss how the sprint went and what they can do to improve the next sprint. The scrum team should conduct this meeting in a self-directed way. If managers or supervisors attend sprint retrospectives, scrum team members will avoid being open with each other, which limits the effectiveness of the team’s ability to inspect and adapt in a self-organizing way.

The team might invite others with whom they regularly interact (such as stakeholders) to participate in the sprint retrospective, but these invitations are generally an exception.

The sprint retrospective is stage 7 in the Roadmap to Value. Figure 5-4 shows how the sprint retrospective fits into agile product development.

© John Wiley & Sons, Inc.

FIGURE 5-4: The sprint retrospective in the Roadmap to Value.

The goal of the sprint retrospective is to continuously improve your processes, environment, collaboration, skillsets, practices, and tools. Improving and customizing how people work together according to the needs of your scrum team increases scrum team morale, improves effectiveness in achieving desired outcomes, and increases velocity — work output.

However, what works for one team won’t necessarily work for another team. Managers outside the scrum team should not dictate how all scrum teams should overcome their challenges and should instead allow them to find the best solutions for themselves.

Your sprint retrospective results may be unique for your scrum team. For example, members of one scrum team decided that they would like to come to work early and leave early, so they could spend summer afternoons with their families. Another team at the same organization felt that they did better work late at night and decided to come to the office in the afternoon and work into the evenings. The result for both teams was increased morale, effectiveness, and velocity.

Use the information you learn in the retrospective to review and revise your work processes and make your next sprint better.

Agile approaches — particularly scrum — quickly reveal problems in projects. Scrum doesn’t fix problems; it simply exposes them and provides a framework for inspecting and adapting exposed issues. Data from the sprint backlog shows exactly where the development team has been slowed down. The development team talks and collaborates. These tools and practices help reveal inefficiencies and allow the scrum team to refine practices to improve, sprint after sprint. Pay attention to what gets exposed. Don’t ignore it and don’t work around it.

In the following sections, you find out how to plan for a retrospective, how to run a sprint retrospective meeting, and how to use the results of each sprint retrospective to improve future sprints.

Planning for retrospectives

For the first sprint retrospective, everyone on the scrum team should think about a few key things and be ready to discuss them. What went well during the sprint and what should we keep doing more of? What would we change, and how?

Everyone on the scrum team may want to make a few notes beforehand or even take notes throughout the sprint. The scrum team could keep the roadblocks from the sprint’s daily scrum meetings in mind. For the second sprint retrospective forward, you can also start to compare the current sprint with prior sprints, and track progress on the improvement efforts from sprint to sprint. Chapter 4 in Book 4 mentions saving sprint backlogs from prior sprints; this is one instance where they might come in handy.

If the scrum team has honestly and thoroughly thought about what went right and what could be better, they’ll go into the sprint retrospective ready to have a useful and actionable conversation.

The retrospective meeting

The retrospective meeting is an action-oriented meeting. The scrum team immediately applies what it learned in the retrospective to the next sprint.

The sprint retrospective meeting is an action-oriented meeting, not a justification meeting. If you are hearing because …, the conversation is moving away from action and toward rationale.

One of the rules of scrum is to spend no more than three hours in sprint retrospective for a one-month sprint. So you usually spend no more than 45 minutes in a sprint retrospective meeting for every week of the sprint. Figure 5-5 shows a quick reference of this timetable.

© John Wiley & Sons, Inc.

FIGURE 5-5: Ratio of sprint retrospective meeting to sprint length.

The sprint retrospective should cover three primary questions:

• What went well during the sprint?
• What would we like to change?
• How can we implement that change?

The following areas are examples of topics for inspection:

• Results: Compare the amount of work planned with what the development team completed. Review the sprint or release burndown charts and what they tell the team about how they’re working.
• People: Discuss team composition and alignment.
• Relationships: Talk about communication, collaboration, and how the team works together.
• Processes: Go over support, development, and peer review processes.
• Tools: How are the different tools working for the scrum team? Think about the artifacts, electronic tools, communication tools, and technical tools.
• Productivity: How can the team improve productivity and get the most work done in the next sprint while maintaining a sustainable pace? Remember Principle 8, “Agile processes promote sustainable development.” Perhaps there are opportunities to “maximize the amount of work not done” (Principle 10) or to work smarter? (See Chapter 1 in Book 4 for more on agile principles.)

If the team works in one-week sprints, they’ll have nearly 52 opportunities each year to hold a retrospective. To maintain engagement in each retrospective, many retrospective formats exist, and it’s helpful for the team to have variety and to have these discussions in a structured format. Esther Derby and Diana Larsen, authors of Agile Retrospectives: Making Good Teams Great (Pragmatic Bookshelf, 2006), offer a great framework for sprint retrospectives that keep the team focused on discussions that will lead to real improvement:

1. Set the stage.

   Establishing the goals and scope for the retrospective upfront will help keep your scrum team focused on providing the right kind of feedback later in the meeting. As you progress into later sprints, you may want to have retrospectives that focus on one or two specific areas for improvement.

2. Gather data.

   Discuss the facts about what went well in the last sprint and what needed improvement. Create an overall picture of the sprint; consider using a white board to write down the input from meeting attendees.

3. Generate insights.

   Take a look at the data gathered and come up with ideas about how to make improvements for the next sprint.

4. Decide what to do.

   Determine — as a team — which ideas you want to put into place. Decide on specific actions you can take to make the ideas reality.

5. Close the retrospective.

   Reiterate your plan of action for the next sprint. Thank people for contributing. Also find ways to make the next retrospective better!

For some scrum teams, it might be difficult to open up at first. The scrum master may need to ask specific questions to start discussions. Participating in retrospectives takes practice. What matters is to encourage the scrum team to take responsibility for the sprint — to truly embrace being self-managing.

In other scrum teams, a lot of debate and discussion ensues during the retrospective. The scrum master facilitates these discussions to guide them towards the desired outcome and keeps the meeting within its allotted time.

Any action item coming out of a sprint retrospective should be added to the product backlog. All work the scrum team will do to achieve the product vision, such as features, technical debt, overhead, and improvements, should be added and prioritized in the product backlog. Scrum teams should agree to include at least one improvement item from a previous retrospective in each sprint to continuously improve how they go about the work of delivering potentially shippable functionality every sprint.

Be sure to use the results from your sprint retrospectives to inspect and adapt every sprint throughout your product development, not just when it is convenient.

Inspecting and adapting

The sprint retrospective is one of the best opportunities you have to put the ideas of inspect and adapt into action. You came up with challenges and solutions during the retrospective — don’t leave those solutions behind after the meeting. Make the improvements part of your work every day.

You could record your recommendations for improvement informally. Some scrum teams post the actions identified during the retrospective meeting in the team area to ensure visibility and action on the items listed. Don’t forget to add action items to the product backlog as a reminder to implement them during an upcoming sprint.

In subsequent sprint retrospective meetings, it’s important to review the evaluations of the prior sprint and make sure you put the suggested improvements into place. High-performing teams have learned how to convert retrospectives into velocity acceleration.