Questions about sprint review

Who are the Users of the website? 

You should use the Review to get valuable feedback from the Users and the Customer. It's really nice the gov people trust you, but maybe they have some new ideas based on the increment you presented..

Thank you for your reply Nils. The website is aimed at school teachers and students, but anybody can use it. I was already told that it'd be too complicated to get a panel of teachers and students even to do user studies, so it won't be possible either to have them in demo.

The sprint review is really going to be only for the scrum team and maybe, (from time to time), for executives in our company. I cannot control that.  So, when only the scrum team is going to attend, is there benefit of keeping that review?

AFAIK, it is not planned to invite gov people to sprint reviews, so the reviews will just be the scrum team.

Is there anypoint maintaining the review in this scenario?

The Scrum Guide says:

"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."

Wouldn't that be a worthwhile activity in the scenario you describe, irrespective of whether or not government stakeholders are invited?

If the Sprint Review would be improved by their attendance, then isn't that the issue to be resolved?

Does anyone outside of the Scrum Team care about the changes made to the product? Who makes the decision to renew, increase or cut funding to this product?

Even if the people making funding decisions aren't able to give meaningful feedback, they presumably do ultimately consider opinions that originate from end users.

Can you therefore afford to ignore the feedback of such users?

If not, then wouldn't the Sprint Review provide a convenient opportunity to harness that feedback?

Thank you Ian and Simon for your responses.

attendees collaborate on the next things that could be done to optimize value. (scrum guide)

but I thought that it could be done in a less formal way if only the Scrum Team is attending the review. Another motivation behind my question is that some people in the team have a profound dislike of `meetings`, or they may potentially be working from home on the day of the review.

However, from what you are saying, I should really maintain the sprint review. 

Inviting end users is not an option (as I was told), but I'll try to persuade my hierarchy to invite people funding the project (who get feedback from end users, as pointed out by Simon).  The project is already funded, but I fully agree that it is important to get feedback.

Thanks again

Inviting end users is not an option (as I was told), but I'll try to persuade my hierarchy to invite people funding the project (who get feedback from end users, as pointed out by Simon).

I think it's wise to know the opinion of the people who are paying for the product, and they may bring real users' feedback (by acting as a proxy for those users), but I would challenge the idea of not having end users present. The closer the Scrum Team are to their users, the more likely they can make the right decisions to satisfy their needs.

We get funded by the government to re-develop a website, but we are still the ones who decide about features and design (it's a partnership)

AFAIK, it is not planned to invite gov people to sprint reviews, so the reviews will just be the scrum team.

Is there anypoint maintaining the review in this scenario? The PO will have already accepted/rejected the stories by then, and the scrum team should already know what has been done by everybody else.

 

From my perspective, here are a couple of issues:

• Features and design can arguably be decided by your scrum team, but wouldn't you want the opinion of those who'll actually use it ***** so that you know, before even building the website, what would be a tentative list (to be inpected and reviewed as more is learned)? Read about Pareto Law (80% of the benefits come from 20% of the features). I argue constant cooperation with end users, from the very early stages, is crucial.
• ***** due to the fact the userbase is so large (teachers and students), the government (department to be more precise) can easily gather interest (by email/phone) from schools/universities and they can create a "stakeholders group" made of teachers AND students within a few weeks (potentially sooner). Say 10-15 people, with whom the PO would work towards creating a highly valuable website. Though your team can surely build a good website (after all it's not an investment bank's risk management tool), since none of you are teachers/students, I argue the website would be better if you have a "stakeholders group" to work with.
• How about the unknowns/changes, technical difficulties, etc? What about funding - especially since it's public money?
• Sprint reviews are mandatory in Scrum; stakeholder participation is highly recommended in order to get direct feedback. If you decide against having reviews, you are missing on a key opportunity to inspect and adapt in your creation process - and you are outside of Scrum's rules
• You should work based on a Definion of Done. It's not really a matter of PO accepting/rejecting stories - are they "super" testers? It's up to the development team to create a done, potentially releasable, increment. So the DT works together, against DoD standards, to complete valuable user stories.

One thing I coach my teams on is that the Sprint Review is also for discussing anything that they uncovered during the execution of a sprint that could have impact on the Product Backlog.  It really doesn't matter how they uncovered that information but it needs to be discussed.  User feedback, stakeholder feedback, other technical team feedback is all valid feedback that needs to be considered.  

I have a couple of teams that work on "infrastructual" components and currently have one team whose primary focus is moving services off of locally housed hardware into the cloud.  Their stakeholders are a wide range of users.  In reality, they really have nothing to discuss with the users other than does it still work.  But we continue to have Reviews.  We have learned things from moving 1 service that impact what we know about moving other services.  It works really well to have an opportunity to discuss this stuff as a group including our Product Owner.

I do want to address one thing you said that most everyone is glossing over. 

Another motivation behind my question is that some people in the team have a profound dislike of `meetings`...,

These are not "meetings".  They are events or ceremonies.  They have specific purposes in the Scrum Framework related to the Agile principles of Transparency, Inspection, and Adaption.  We had problems with this bias when we went to Scrum. All of our Scrum Masters call them Events.  We do not refer to them as meetings.  For months, we started each event stating the reason that were there and made a concerted effort to keep the attendees focused on the purpose and not letting it stray into a meeting.  Once our team members started to appreciate and understand the purposes of the events, they embraced them. In fact, many of the "meeting haters" have mentioned how much they like the events because they are focused, on purpose and extremely useful.  It isn't easy but with some effort a good Scrum Master can change that "too many meetings" mentality.