For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.


One of the "worst practices" I've discovered several times when coaching Scrum teams is when a team uses their Sprint Review as a "signoff" meeting, with either the Product Owner or other stakeholders acting as approvers. Getting feedback at a Sprint Review is great, but treating the Sprint Review (some call it a "Demo", a mistake in my opinion) as some sort of acceptance meeting causes all kinds of problems. In this article, I look deeper at this worst practice from the following angles:
  • Possible Symptoms
  • Possible Causes
  • Possible Consequences
  • Possible Solutions


The Sprint Review is one of the most important feedback loops in the Scrum framework. It creates an environment where stakeholders can give immediate feedback on features that were just completed within the last few weeks. However, in my coaching travels, I've discovered a worst practice in Sprint Reviews, and the practice has negative consequences that every team should be aware of.

Possible Symptoms

  • During the Sprint Review, the development team appears to treat the Product Owner as the primary audience member.
  • During the Sprint Review, the Product Owner appears to be seeing the new features for the first time.
  • Product Backlog Items & Stories are not marked as "Done" before the Sprint Review.
  • Numerous Product Backlog Items or Stories carry over from one Sprint to the next.
  • During the Sprint Review, the Product Owner does not seem to be taking a prominent role in leading the meeting.
  • A developer or ScrumMaster leads most of the Sprint Review.
  • Someone on the Scrum Team appears to be trying to get buyoff/signoff from the Product Owner or other stakeholder.
  • It appears as if the non Scrum Team stakeholders are
    • deciding whether a story is "done," OR
    • deciding whether a story gets "signoff" or "approval." (or not)

Possible Causes

  • Waterfall thinking - this is a short way of saying, "Well, this is how demos used to work, and we always heard that the Sprint Review was just a demo."
  • Lack of Scrum Maturity - a general lack of Scrum knowledge on the team about what a Sprint Review is supposed to be.

Possible Consequences

  • Scope Creep in current Product Backlog Items(PBI's)as the Product Owner or stakeholders request changes to be completed in the next Sprint.
    • Feedback from the Product Owner should have already been obtained within the Sprint and any time up to the time that the Product Owner signs off on the Product Backlog Item. Said another way, PBI's should be accepted, or signed off on, prior to the Sprint Review.
    • Feedback from the stakeholders should almost always be reflected in future PBI's.
    • The only way feedback during a Sprint Review should ever cause a PBI to carry over to the next Sprint is if someone notices that one of the PBI's requirements or acceptance criteria was truly not met. This should be extremely rare, since the development team has said it thinks the PBI is complete, and the Product Owner has signed off on the story prior to the Sprint Review. By definition, when a Product Owner signs off on the story during the Sprint, they are saying that all of the acceptance criteria for the PBI have been met.
  • Demotes the Product Owner role
    • The role of the Product Owner is to provide vision for the product. If the stakeholders external to the development team have signoff authority, then this usurps the role of the Product Owner. Of course stakeholders are important, but their role is to give feedback. It's also perfectly fine for a stakeholder to disapprove of the way a feature was implemented. Yes, I said it was perfectly fine! What I mean by that is that the stakeholder should be expressing their opinion on the functionality just developed, and any feedback they give (positive or negative) should be taken into account in future backlog items. Said another way, a Product Backlog Item should not be considered incomplete because a stakeholder doesn't like what was implemented. A PBI should only be considered "incomplete" when one or more members of the Scrum Team (usually the Product Owner)have decided that all of the acceptance criteria for the story have not been met.
  • Builds a wall between the development team and stakeholders
    • If you let signoff be a part of this process, it sometimes encourages an "us vs. them" mentality, especially when high level stakeholders are present at the Sprint Review. This problem is exacerbated if the Product Owner doesn't have a predominent role in leading the Sprint Review, or if the Product Owner seems to always side with the external stakeholders.
  • Builds a wall between the Scrum Team and stakeholders
    • This is the same as the previous consequence, except this time the Product Owner seems to always side with the development team
  • Doesn't encourage the exact feedback that is the most important part of the Sprint Review.
    • The feedback *from* the stakeholders, *to* the Product Owner and Scrum team, is the most important thing to get out of the Sprint Review.

Possible Solutions

  • First, foremost, and most importantly, know what a Sprint Review is supposed to be. Read the Scrum Guide, it's only like 20 pages. Specifically, read the section on the Sprint Review and make sure your team is in alignment with the Sprint Review as it is described in the guide.
  • If you are developing software for an external client who "pays the bills", don't use the Sprint Review as a signoff or acceptance meeting. Instead, if your Product Owner is not employed by the client, consider scheduling a different meeting for that purpose, and maybe limit attendance as appropriate. If your Product Owner is employed by the client, then the Product Owner should be signing off on PBI's as soon as they are completed in the Sprint.
    • It's hard to tell an external client that they don't decide what's approved and what's not. However, you can effect the same thing by saying "Yes, we'll take care of that", and then secretly throwing it on your backlog as the first priority item, or whatever urgency/priority you negotiate with them. Again, consider holding this "external client demo" separately from your Sprint review if at all possible. Besides, the other things you discuss at the Sprint Review might be unimportant to your external client.
  • For other possible solutions, see my article on Tips for a Good Sprint Review

In Closing...

The Sprint Review is one of the many feedback loops that are baked into Scrum. I hope you have learned some things here that will help turn your Sprint Review into a highly productive feedback loop that enhances your Scrum Team.

Related articles