No stakeholders at Sprint Review - cancel?

I have had this from teams in the past, and I have always asked them to go ahead with the sprint review and keep the invitation open to the stakeholders.

Sprint review is an important opportunity for the Product Owner and Development Team to be transparent about progress, and for the stakeholders to understand progress and discuss with the Scrum Team what they can expect and need from the team to support the business goals. It should be interesting to the team to understand how much support there is for this on-going tech debt work. It's usually good to have a reminder of work completed as input in to the Sprint Retrospective, so the review can help the team too.

The team often seem very protective of the stakeholders time, and I remind them that stakeholders make the decision to continue coming. To support this decision it can be helpful to send round a short agenda of the items to be reviewed, and Product Owner and Scrum Master might choose to change the audience for these reviews to include people who are particularly interested in any of the bug fixes.

Do you think there are deeper reasons why your team wants to cancel? Have you asked how sprint review could be changed to make it more efficient or appropriate for reviewing the current work from the team?

> The team is demo'ing features to our PO for his acceptance once
> every one is complete, rather than waiting until the end of the sprint.

That is generally a good practice. There is nothing in Scrum which says you have to defer the review of work, and accumulate risk, until the end of the Sprint.

> The team doesn't feel a Sprint Review would be valuable at the end
> of this sprint and are proposing not having it.

A Sprint Review is not simply a demo to the PO, it is also an opportunity to show other stakeholders the work that has been done. Furthermore, it is a review of the work that has *not* been done, and of the product scope that will be addressed in Sprint Planning.

Hi Steven,

Thanks for the reply. I have asked the team this question - in fact I took a retro action item to work with the PO to see how we can make our Sprint Review more valuable next time.

Our Sprint backlog tends to vary from sprint to sprint in terms of who our stakeholders are. In this case its just more the fact that the PO can't actually identify stakeholders - these are generally bugs the team have identified.

I don't think the team are against doing a Sprint Review - the problem we see are there are no relevant stakeholders to invite to this one in order to get feedback - aside from management and other interested teams. Do you think its sufficient to invite them if the work doesn't directly impact them?

there are no relevant stakeholders to invite to this one in order to get feedback - aside from management and other interested teams. Do you think its sufficient to invite them if the work doesn't directly impact them?

Transparency is always a good goal. There really is no harm with extending the invitation to other stakeholders.

My teams have not demonstrated bug fixes in Sprint Reviews, since this requires extra effort to preserve the original "bug" in some form in order to show the improvement. Instead, they have relied on metrics and a discussion around value to review removal of technical debt.

I would caution against applying your own "filters" to who may be relevant at a Sprint Review. You never know where valuable feedback might come from.

In my opinion, the Sprint Review invitation list should remain relatively static. Allow the invitees the freedom to decide whether their time is well-spent at that sprint's review, instead of managing the invitations sprint to sprint. Consistency is a friend to Scrum, and variability leads to waste.

Kaizen Master, I agree with Timothy - consistency helps everyone, and I would be as inclusive as possible in your invitation list. As a Scrum Master, at the end of the review, I have sometimes asked all the participants to rate the review as a use of their time (from 1 to 5, where 1 is a complete waste of the time), or asked "Please can you share something interesting that you've learned today". Also as Ian said, it is often surprising to the team how useful people find the opportunity to keep on top of the progress and contribute to the team's planning.

If you get low scores then you'll definitely want to explore how the reviews can be made more relevant. Also remember that you don't have to use the whole time box - if there is little to show, then the review should be short too.

In addition to what others have already said I think it's important to remember that the sprint review is also a planning event, i.e an opportunity to review the backlog and decide what to do next. It's not simply a recap of what has been done in the last sprint.
The PO should be able to explain to the stakeholders her reasons for prioritizing paying down on technical debt. Other stakeholders could (rightly) question this decision and you can have a healthy discussion around that.
You never know what feedback you will get, so always try to be as transparent as possible about the work being done.

Hi All, I am having kind of similar situation now and my question is who should decide whether to cancel the demo  or keep it? is it the Scrum Master? Product Owner? Delivery Lead/Team Lead? 

Scenario & Background: My Delivery lead and team lead are traveling so they won't be able to attend plus we don't have a lot to demo because we worked on technical debt and some of the team members were not available due to 4th July holiday. We do not have 'other stakeholders' for this project. Product owner has already seen and accepted the work the deliverables that we have worked on in this sprint. 

Challenge: The delivery lead and team lead have asked me to cancel the demo but I don't know if I should cancel it or talk to my product owner. 

Any help? 

TIA

Anuj

First I am going to assume that when you say "demo" you are referring to the Sprint Review.  And making that assumption I am going to point out that the Sprint Review is not a demo. It can involve doing a demo of the work done but that is only a mechanism to fuel the discussion about what adjustments may be needed to the Product Backlog. So to answer your question I am going to ask you a couple of questions.

1. Is there a chance that something that affects the Product Backlog could occur during the Sprint Review? 
2. Why are the Delivery Lead and Team Lead making decisions for the entire Scrum Team? Even further are the two Leads even part of the Scrum Team?

The fact that you came here, looked for a post that provided some guidance and then decided to add on to a 3 year old post leads me to believe that you already had an answer to your own question.  The wording of your question and the older post you chose to associate with also makes me believe that your answer is probably more "correct" than you think.  Part of being a Scrum Master/Agile Coach is learning to follow your initial reactions when they are based upon agile practices even if they go against organizational politics. Also remember that any suggestion you make is just that, a suggestion. Always pose it to the team and let them arrive at an option that they want to try. Make sure that it is discussed in a Retrospective so that the team can determine the effectiveness of their option and adjust it going forward. 

Thanks Daniel for a quick response and yes my demo I meant Sprint Review. Here are my responses to those two questions: 

1. Is there a chance that something that affects the Product Backlog could occur during the Sprint Review? Yes, the feedback! but as I mentioned we have already received the feedback from the Product owner during the sprint. 
2. Why are the Delivery Lead and Team Lead making decisions for the entire Scrum Team? Even further are the two Leads even part of the Scrum Team?  They are making decisions because they are responsible for the delivery. Sadly, they have the decision making power in situations like these. 

The reason I came to this post was because when they asked me to cancel the sprint review, I felt like I needed to talk to the product owner if it is okay to cancel the demo since she has already seen/accepted the work or should I re-schedule to a later time of the week. I also felt that my delivery lead and team lead still thinks that I am the incharge of these scrum meetings that's why they did not even think about checking with the product owner (business) before making their decision on cancelling the sprint review. I understand that we need a bit of education here but yes I am working on it. 

Thanks

Anuj,

Some housekeeping first.   The event is called a Sprint Review.   It is not a "demo".   Proper Scrum vocabulary will help you, your team, and your organization improve their Scrum understanding and execution.

Now, back to the "Sprint Review".   The Scrum Guide outlines the following content of a Sprint Review:

• The Product Owner explains what Product Backlog items have been "Done" and not "Done"
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved
• The Development Team demonstrates the work that it has "Done" and answers questions about the Increment
• The Product Owner projects likely target and delivery dates based on progress to date
• Attendees collaborate on what to do next to optimize value.   They discuss how the marketplace or potential use of the product might have changed what is the most valuable thing to do next
• Attendees review the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product
• Attendees inspect the Increment, and adjust/update the Product Backlog if needed

So, based on the above, what items would be impacted by a couple Development Team members being unable to attend, or some of the Development Team being unavailable during the sprint because of a holiday?   

What does a lack of stakeholders for the items offered by the PO for the sprint tell you about how the PO is optimizing value?

What does the rest of the Scrum Team feel about canceling the Sprint Review?   What might be your reasons as a Scrum Master for disagreeing with such a request coming from just two of the Development Team members?