What happens when the Product Owner or the stakeholders are not available on Sprint Review event?

Due to some reasons, if the PO (Product Owner) and stakeholders are unavailable to review the work done by the development team in the sprint, what will happen?

The Scrum Master will try to establish what those reasons are, given that Product Ownership and the team's implementation of Scrum is being compromised. Considerations include:

- Is there a problem which stops the PO from attending the Sprint Review?

- Is there a problem which stops the PO from collaborating with the team and reviewing work on an ongoing basis?

- Does the root cause indicate a systemic problem or a one-off?

Is there a problem which stops the PO from attending the Sprint Review?

A: The PO/stakeholders are not able to attend the Review meeting  because of some planned Workshops or unavailable due to some personal necessity or vacation.

 Is there a problem which stops the PO from collaborating with the team and reviewing work on an ongoing basis?

A: There is no problem with respect to collaboration of PO with the team and review activity happens regularly. The scenario mentioned here is uncommon, where both PO and stakeholders are not available.

Does the root cause indicate a systemic problem or a one-off?

A: It's a rare scenario and might happen once or twice a year.

What could be the possible options for the development team to get the work reviewed in this scenario?

I've had similar situations and the team handled it by making sure the PO and Stakeholders were consulted during the sprint as work was ready to be viewed.  In essence, we did the Sprint Review in iterations during the sprint.  When it came to the end of the sprint, anyone available from the Scrum Team and Stakeholders that were available came together and talked about any changes needed to the Product Backlog that had not already been done.  This protected the cadence and still accomplished the goal of the Review. It actually lead to this becoming a practice that was undertaken more often because everyone liked the information flow and interactions.

I would suggest that you don't go to extremes to accommodate rare occurrences.  Protect the team's cadence to help them with consistency.  Most situations can be handled well with transparency, inspection and adaption.  But as with everything, ask your team what they feel is best and protect them from making a bad decision.   :)

Daniel Wilhite + 1 !!!

Yes, stick to the principles when you find in hard spot with rules. The intention of the Sprint review is to review the work done and certify it as completed. The best solution to your situation like Daniel mentioned that has been proven successful is to iteratively review the completed items ASAP usually right after a daily scrum  (so the team is not disturbed from their focused effort for the rest of the day) or whenever is most feasible for both parties. 

Please keep in mind that ...

"..although implementing only parts of Scrum is possible, the result is not Scrum" - Scrum Guide

..and that you did your best to stick as close as possible to the agile principles. Also make sure to revisit this decision during your team Retrospectives to make sure it is still a valid approach and agreeable for all team members.

Uma, I would politely disagree with one statement that you made:

The intention of the Sprint review is to review the work done and certify it as completed.

The purpose of the Sprint Review is not to certify that items have met DoD.   This should have already taken place, and any items presented to the PO and stakeholders during this ceremony should have already met DoD.

Per the Scrum Guide, the purpose of the Sprint Review is to inspect the increment and elicit feedback that may be incorporated in future Product Backlog items.   

This is a collaborative ceremony to both confirm direction and value, and possibly identify additional value-based enhancements.   It is not a "tollgate" or checkpoint for items on their journey to meeting DoD.

 Timothy Baffa I agree with you. I wanted to correct my statement, but it wont let me :(. It's one of those non intended misdirections based on the misinformation I carried for a while that PO approves the backlog items as done but actually... 

"The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done" (no such thing as approval !)

 It is not a "tollgate" or checkpoint for items on their journey to meeting DoD.

True !