The Sprint Review as a Sign-Off Meeting

Some teams use the sprint review as a time for product owners or key stakeholders to formally approve the product backlog items completed during the sprint. Is this a good idea?

In general, a sprint review should not be used by a team to get formal sign-off on their work from their product owner. The team and product owner should be working so closely during a sprint that the team knows what the product owner thinks of what they’ve built.

No Surprises During Sprint Reviews

No surprises is my No. 1 rule for the sprint review.

It is absolutely acceptable for a product owner to reject the work of a team on a product backlog item. But the team should know that’s coming.

Team members should not walk into a sprint review expecting glowing praise from the product owner but then be blindsided by a litany of complaints about a feature.

Can Clients Use Sprint Reviews as Sign-Offs?

But what about acceptance by a client? Can a sprint review be used for formal sign-off or acceptance in those cases?

Ideally, in cases in which a client hires a vendor to develop a product, someone at the the client company would act as the product owner. And in those cases, it can be OK for formal sign-off on features to occur during the sprint review.

But I’d still stick with the advice that there should be no surprises during the review.

Even though the client product owner is providing feedback to the team during the sprint, it’s possible that the product owner needs to wait to fully accept something until other stakeholders have a chance to comment on the work.

As a simple example, my daughter recently asked me if she could go on a school trip. I said it was fine with me, but—guess what—we needed to check that it was OK with her mother. That is, my wife might have had plans for our family during that time that I didn’t yet know about.

This will be a common situation for client product owners in contract development situations. The product owner interacting with the team daily may like how a feature has been built, but may need to confirm that the stakeholders he or she represents agree. Sure, we can say that the product owner should simply go ask. But that can be impractical and might best be done in a sprint review.

But in outsourced, contract development, the client doesn’t always provide the product owner. Many times, the client hires the vendor to take care of everything.

The client is, of course, the true product owner. The client will ultimately accept or reject what is developed. But, on a day-to-day basis, the client doesn’t want to be “bothered.” And so the typical solution in this case is for the vendor to appoint a product owner from someone within its own organization.

And in this case, true acceptance (or “sign off”) on product backlog items cannot happen before the sprint review. The true product owner (from the client) is not sufficiently available and engaged to accept things any more frequently.

Sure, the team may have a preliminary sign-off from their own product owner representative during the sprint. But the true, client product owner may completely reverse that decision in the actual sprint review.

So the ultimate answer depends, like so many things, upon the context in which you’re operating. And so I’ll say that I’m not too concerned by actual, formal sign-off occurring during a sprint review. But I always want to stick with a policy of no surprises during the review.

Sign off or not, as needed. But the team should always have a good idea of what’s coming before they get to the review.

What Do You Do?

What does your team do in sprint reviews? Has the product owner largely seen everything before then? Are product backlog items formally accepted during the review? 


The Definitive Guide to the What and When of Product Owner Responsibilities

The Definitive Guide to the What and When of Product Owner Responsibilities

Sign up to get your free download

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.