Skip to main content

Shall Sprint Demo/Review be Cancelled if Stakeholders are aware about the Product Increment during the Sprint ?

Last post 06:24 pm March 18, 2020 by Stijn Decneut
3 replies
03:16 pm March 17, 2020

Hi Everyone,

Recently I came across a situation where I was asked to cancel Sprint Review/Demo as required Stakeholders have already tried (experienced) and walked through the stories adding increment to the product during the Sprint.

  1. One of the reason was that team assigns stories to Product Owner for UAT during our Sprint itself and once story passes through UAT, they are marked as Done. Since everything worked smooth this time and all stories were passed in UAT with no major bugs, PO came up with idea to cancel Sprint review and replace with some other useful meeting. 
  2. According to PO, stories are marked as Done only when it passes through UAT in Staging env. which is consumed by stakeholders/PO only. 
  3. Hence, PO is already aware about the product progress and increment during the Sprint.

Also there is no other Stakeholder who is attending the Sprint review and hence this suggestion came to me to save time and utilize it for other useful purpose.

I would like to know from you all experts about what should be mine action with this situation as Review is one of the important ceremonies. Also going forward there could be situation where stories are delayed and cannot reach UAT. Hence Review sessions will be useful in those times. 

Regards,

Praveen


06:38 pm March 17, 2020

How important is inspection and adaptation to you, in your implementation of Scrum?


07:38 pm March 17, 2020

The opening paragraph in the Scrum Guide's section on the Sprint Review:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

Based on the description you gave, there was not a discussion to which the Development Team was privvy. So does that impact their ability to inspect and adapt according to the feedback?  And how is it fostering collaboration between the Scrum Team and stakeholders to keep all of the interactions segregated? 

If I were you I'd be focusing on the fact that no stakeholders attend the Review instead of ways to eliminate the Review entirely.  Your team is missing out on an important feedback loop and opportunity to discover information related to the stakeholders intentions and needs. 


04:15 pm March 18, 2020

Hi Praveen, 

great to see that UAT is part of your Definition of Done!

As for your question: In my view, the main goal of a Sprint Review is not to demonstrate the finished Product Backlog items. Sprint Reviews are organised to gather (new) learnings on the product and to update the Product Backlog accordingly. As the Scrum Guide states: "The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint."

So, even if the entire Sprint Backlog was accepted by end-users, there still are questions to be answered in the Sprint Review: What feedback dit we get from UAT? Is our vision and priorities in the PBL still optimal with what we learned? How do we know that? What data do we use to decide? How is that data evolving? What assumptions are we still making on the product? How can we validate our assumptions? Should we adapt our planning/expectations on the upcoming Product Increments based on what we experienced this sprint (e.g. a certain development activity going faster or slower than anticipated, or "people are starting to mention the main page of the product is getting bloated")? ...

Don't forget that the Sprint Review is "[...]at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter." - Scrum Guide. Make sure the (mandatory) Sprint Review happens, but don't make it last longer than is valuable for your product, team and stakeholders. People usually don't complain when they get a bit of extra free time because a Sprint Review took less time than planned.

And keep your Sprint Review pleasant for all, so they don't mind joining in. One summer time in Australia, I've had great Sprint Reviews during after work drinks with key stakeholders :-).

Cheers,

Stijn

 

 

 

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.