What To Do When The Sprint Review Goes Badly?

Share
What To Do When The Sprint Review Goes Badly?
Photo courtesy of sxc.hu

Sometimes the Sprint Review goes badly. This is an inevitable part of Scrum. Maybe you uncovered a bug during your demonstration. Perhaps the team member that was supposed to demo a function was out sick. Your technology might fail you. Or the customer just may throw up their hands and tell you that what you’ve delivered is all wrong. What should the Scrum team do when this happens? Read on to find out more.

To ensure that everyone know what we’re talking about, the Sprint Review meeting is when the Scrum Team demonstrates the product or solution to the customer and/or stakeholders. This meeting is held at the end of each Sprint when all of the Sprint backlog items have been completed.

In order to recover when the Sprint Review goes badly, here are six tips to proceed.

  1. Be sure to capture everything that went wrong. This is something that the ScrumMaster can do during the meeting to serve the team during the Sprint Review.
  2. The Product Owner should put items back onto the Product Backlog that failed testing during the Sprint Review. But instead of doing so blindly, the Product Owner needs to interject exactly what the customer was looking for out of that backlog item and rewrite it to be more accurate for the team.
  3. User Stories that are associated with the failed backlog items should be evaluated for accuracy. If necessary, these should also be updated to reflect exactly what the customer wants.
  4. The Team should move ahead and hold the Sprint Retrospective meeting. Instead of going back into the current Sprint, close this one out and move on to the next one. Remember that each Sprint is a time-boxed iteration cycle for development of the product. There are no provisions in Scrum for a second Sprint Review meeting during a particular Sprint.
  5. Discuss each item that went wrong during the Sprint Retrospective meeting. Focus on correcting the issue at hand instead of placing blame. This keeps the team morale high and ensures cohesiveness for upcoming Sprints.
  6. Don’t ignore what went right. Unless the entire Sprint Review was a total disaster, there are some positive outcomes from the Sprint. Ensure that everyone acknowledges what went well. A Sprint Retrospective isn’t just about correcting what went wrong. It is also about figuring out what went well so that the team can do more of the same during upcoming Sprints.

It is up to the ScrumMaster to keep the Team moving forward. The tips we’ve listed above should be in the toolbox of every capable ScrumMaster. If you find yourself regularly dealing with failed Sprint Review meetings, let Braintrust Consulting Group help you find and fix the underlying problems. With our experienced team of Scrum coaches, Braintrust can help you overcome these barriers and ensure that your customers and stakeholders are satisfied at each and every Sprint Review. Click on the Contact page to hear from one of our product specialists. Or, head over to the Services tab to find out more about our offerings.

Discussion Question – Have you ever had a bad experience during a Sprint Review? If so, please share the story in the discussion below, including your role, the problem encountered, and how the team recovered.