Chapter 14
The Sprint Review

It’s really common for Scrum teams to misuse sprint reviews and have the event go off the rails—we see it all the time in our consulting. Here’s a situation Todd witnessed that illustrates some of the many ways that sprint reviews can fail.

A few years ago, Todd was asked to consult with a product owner at a nonprofit company. The company had an old-school, manual process for issuing donation receipts to donors that involved paper, pens, and the postal system. They dreamed of a digital system that would free up employee time so that employees could focus their energy on other, more important tasks like inciting donors to keep giving to their cause. The nonprofit’s board passed a budget and anointed as product owner a manager with in-depth knowledge of the donation processes. The remainder of the Scrum team was assembled, and off they went on their first sprint to begin fulfilling the company’s digital donation receipt dream.

The first sprint began with the product owner telling the team her expectations of what they were going to complete during the sprint. At the first sprint review, the Scrum team gathered, and the product owner carefully inspected the work the development team had completed during that sprint. The development team went through each PBI in the sprint backlog as the product owner gave a thumbs up or down to signify whether she accepted or rejected the work. The product owner made it clear that she wasn’t terribly upset with the results because it was the team’s first sprint, but that there was certainly room for improvement.

A few sprints into the project, the development team started sensing a disconnect between the product owner and some of the stakeholders with which the development team had been discussing scope. Todd made a visit to the organization and suggested to the product owner that she might want to invite some stakeholders to the next sprint review. The product owner scoffed and said that she knew what was best for the department and that all of the stakeholders’ opinions would add unnecessary scope.

After several months, nothing had shipped, and pressure began to mount on the product owner. The organization was ailing from all of the manual work. When the pressure became too great, the product owner finally took Todd’s advice and invited stakeholders to the sprint review, including some back-end office employees and a few executives who had approved the project’s funding. As the development team demonstrated their working software, the frustrated stakeholders raised lots of questions:

• “Have you considered what will happen with foreign currencies?”

• “How will this integrate with our customer relationship management system?”

• “Will the receipts be available on a mobile device?”

• “Did you handle these edge cases?”

The stakeholders were surprised that the software wasn’t even close to being ready for production. The people who had funded the effort were especially upset: They argued that many of the issues identified in the sprint review should have been raised very early in discussions. They remarked that Scrum doesn’t work, and that with a better upfront plan, these items would have been considered during the requirements phase. A few days later the project was canceled, the product owner was fired, and the Scrum team disbanded.

The product owner in this example refused to invite stakeholders to the sprint review out of fear that the project’s scope might expand beyond of her control. She treated the review as a mechanism for her to accept or reject the team’s work—not as an opportunity to get feedback from stakeholders. The lack of transparency to the wider organization outside of the Scrum team caused the company to waste a lot of money, and not solve the problem that the project was meant to fix.

The sprint review is an important event that occurs toward the end of a sprint. It’s where the Scrum team inspects the increment and adapts the product backlog. In collaboration with stakeholders, the Scrum team reviews what has happened and decides what to do next. There are many problems that can arise from noncollaborative sprint reviews. Let’s explore some of these anti-patterns—and how to avoid them.