The Sprint Review as a Sign-Off Meeting
The Sprint Review as a Sign-Off Meeting
Should you wait until the Sprint review to have your Product Owner get the approval of your work from the stake holders? See what one Scrum Master has to say.
Join the DZone community and get the full member experience.Join For Free
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 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.
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 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 an 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? Please share your thoughts in the comments below.
Published at DZone with permission of Mike Cohn . See the original article here.
Opinions expressed by DZone contributors are their own.