Product Owner and Stakeholder are not available on Sprint Review date...

Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

That's from the Scrum Guide, so the official answer is certainly that you cannot extend the sprint.

Generally when a Product Owner cannot attend the Sprint Review, I would expect that they have made arrangements for someone to handle it in their place. It's not uncommon for the rest of the Scrum Team to fill in, in such a circumstance.

Be aware that moving the events to other times can have a cost in terms of focus, lost transparency, and missed opportunities to inspect and adapt. However, if it is the best chance to get valuable feedback, then it might be pragmatic to make an exception on this occasion, and hold the events on Monday evening.

Could it be that this kind of disruption would be any less likely if the sprint normally ends on a different day? Some teams choose to start/end sprints on a Wednesday or Tuesday, as that reduces the risk of holidays and weekend incidents impacting on availability.

Sprint Planning, Review, and Retrospective events should be held as closely as possible to the Sprint boundary in order to reduce waste. If that happens to be a Monday then it should be Monday.

Inspection and adaptation during a Sprint includes things like checking the weather forecast, so certain events can be replanned and brought forward if need be. Earlier is generally better than later and a Scrum Master ought to do as much as possible to help the team start each Sprint with no debt and a clean slate.

Seems to me that this was an isolated issue and not the norm, I mean sometimes stuff just happens; we all know that even the best laid plans are laid to waste.

I'll start with the obvious, I believe Friday evening is a HORRIBLE time to have any kind of event; especially one as important as the Review and/or Retro. People typically check out mentally Friday afternoon and are ready to be done with work. Not to mention, you have people that take off early on Fridays; I know I try to. So maybe the first step to prevent this would be to move these to Monday or Thursday, even Friday morning; but Friday evening is not a good plan in my opinion.

Now for the part that people will likely get their feathers ruffled...

Your PO and Stakeholders can't make it but the rest of the team are there? Have the Review and the SM can get back together with the PO and Stakeholders at the earliest possible time to run over what was discussed. The rest of the team proceeds as scheduled with their Retro and moves on with the next Sprint. If there needs to be an extra meeting the following week to circle back shortly about the Review, so be it; so long as it is not the norm and it's really something that you just cannot prevent.

With that said, say you look at the forecast and you do all that you can do to plan but a freakin tornado blows through the city and you're not able to have a Review; what are you to do? Schedule for the earliest possible time on the next day. Does it mean your Sprint is extended? Technically, yes, but what are your options in an emergency scenario like that; cancel the Review for the Sprint altogether? That's not a good plan at all. The SG doesn't talk about emergency or one-off scenarios like this, that's when inspection and adaptation comes in. Ultimately, live within the framework, deviate when it's not preventable or avoidable, inspect and adapt to prevent what caused the need to deviate for the future, and be flexible and agile in dealing with problems that arise.

I believe Friday evening is a HORRIBLE time to have any kind of event

+1

If this is an unexpected situation, too late to change to an earlier time, or development team development progress can not match, I share my practice.

We'll have the team hold the time as scheduled. If you can find someone else's representative, try to ask them to attend.

Sprint Review is usually in the form of features demo, based on the user stories one by one demonstration, so you can use the screen video tools to record the demo process, and then sent to the product owner and stakeholders.

In the next Sprint, the product owner can discuss with stakeholders as much as possible based on the content of the video. The product owner can also adjust the content of product backlog before or during the next Sprint planning meeting, depending on the content and feedback of the review video.

For me it would be more important than keeping the dates to get valuable feedback from the stakeholders. So I would prefer the Sprint Review once on Monday and then discuss in the Retrospective if Friday is still the best option and if everybody understands the importance of the events.

But sounds like the team is fine with Friday and only the weather was the reason.

Here is the question if it was bad weather and the stakeholder and the PO think it's not important or the weather is so extreme and they are not able to make it. If they are really not able to make it don't forget that Scrum based on the agile manifesto and if the team reschedules once it should be ok based on:

"Individuals and interactions over processes and tools" 

Don't risk peoples life in a snow storm etc. ;)

If they reschedule because they see the meetings as overhead and the weather is an excuse, you know what to do ...

+1 Niels.

We had similar situation - PO got ill just before the Sprint Review. We moved the meeting by one day. Our scrum team prefers him to be present during Review, Retrospective and Planning and as our Backlog is prioritized they usually know pretty well which items to pick up in case of such delay. 

Things can be considered for this kind of circumstances

1. Try to assess these circumstances well before the time 

2. See there is a backup plan for the resources

3. Avoid Fridays and Mondays for Starting/Ending sprints

4. Arrange an online session 

5. Record a review session before going into actual sprint review meeting.

I would like to state an excerpt by Ken Schwaber from the foreword "Mastering Professional Scrum"

Sometimes the Scrum professional may be torn between two alternatives. In these circumstances, the Agile Manifesto provides higher-level guidance:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

I think in this specific instance, the first and fourth points should be taken as general guidance. I also agree that Friday afternoon is probably not the best time for sprint review. 

Record a review session before going into actual sprint review meeting

One practice that several of my teams have adopted is recording the actual Sprint Review session, instead of creating one ahead of time (avoid duplication of effort).

One thing to consider is whether this situation (PO, some stakeholders unable to attend) is an exception or not.   Other tactics/changes may be required if this is not an outlier to normal Sprint Review attendance.

In my opinion, the recording of the Sprint Review helps facilitate delayed feedback from a PO or stakeholders unable to attend the event.   While it certainly is not the preferred feedback loop into the upcoming Sprint Review, it is still feedback that can potentially be addressed in a future sprint.

We are going to start with Scrum next month (2 weeks sprints), and one of the PO is not working on Fridays during the next 4 months... Our team is small, there is no option to have a Proxy PO or something similar. 

Maybe one option is:

The previous day of the review and retro (Thursday) that PO can share his feedback about the sprint with me (I'm the SM) or to the other PO (they are used to work together) and I can share this information on Friday in that events with the rest of the team. 

Moving the review and retro to Monday, and after that, the same Monday, start with the planning of the following sprint, maybe is not a good option.

What do you think in this case?

Thanks!

As always we can provide you all kinds of suggestions but in the end, the real decision is your team's decision and not yours alone.  Bring this up with the team and let them decide what they feel is best. But since you asked for our opinions, I'll give you mine.

one of the PO is not working on Fridays during the next 4 months.

share his feedback about the sprint with me (I'm the SM) or to the other PO 

So a single Scrum Team has 2 Product Owners?  In my experience that has never worked well because both Product Owners will want things in the same Sprint which leads to the Developers being split in their focus. This might be something that you want to focus on before you start Scrum.

Personally I would not use your first suggestion.  If the developers will be working on the code on Friday, the feedback given by the PO could be wasted. It will also be difficult to have the discussions needed to adjust the Product Backlog, which is the intended outcome of the Sprint Review. I would instead recommend that the Product Owner give feedback continuously during the Sprint.  That way the Developers have time to adjust and there will be no surprises on the day of the Review.  But if the Product Owner is not able to attend the Review, who will be coordinating the involvement of the stakeholders? In reality they are more important in the Review than any of the Scrum Team. It is their feedback that will influence the Product Backlog and any changes that are identified for the Product.

But given the situation, have you thought about having your Sprints start on another day?  I frequently suggest starting on Wednesday.  This allows for deployments to Production to happen during the week instead of doing them on Friday. Friday deploys that have problems can often extend past normal working hours.  Having this occur during the week is a little better to accommodate and less of an inconvenience for the staff.

Moving the review and retro to Monday, and after that, the same Monday, start with the planning of the following sprint, maybe is not a good option.

I've had all of the ceremonies on the same day. It makes for a long day but it is possible. It fits into the framework since a new Sprint begins when the previous ends.  

Hi Daniel Wilhite, thanks for your comments!

So a single Scrum Team has 2 Product Owners?

It's a small team, only 4 developers and two of them are also PO, is not the ideal situation, but now it's our reality. 

Personally I would not use your first suggestion.  If the developers will be working on the code on Friday,

Well, Friday morning the team will be at Review and Retro

 I would instead recommend that the Product Owner give feedback continuously during the Sprint. 

Yes, that is the idea, the PO should never wait till the Reveiw to check the work done. In any case, not only in this particular situation.

But if the Product Owner is not able to attend the Review, who will be coordinating the involvement of the stakeholders?

Now, the only stakeholders are from our company. We are not working yet with Scrum, we will start next month, and we will be fully involved on it, and we will learn step by step, due to the team's characteristics.

I frequently suggest starting on Wednesday

Why not?! ;) So, Review and Retro will be on Tuesday. This should work. And maybe Refinement on Monday or Friday.

Thanks again.

Adding my two centavos to the situation. The PO and stakeholders in our org, are highly important, so if I were in this situation I'd have the review when the PO is available on Monday. 

Regardless of how you look at it there will be some kind of waste. 

Example:

-The team can plan ahead for the next review, but may need to rework again plan once the PO is back

-Team can hold a retrospective but will have to do another retrospective once the PO is back

-Team can even hold their own review without the PO and Stakeholder, but may need to set aside more time once the PO/stakeholder is back to get his or her input on the review 

- I'd probably opt to have the team look at adapting it's DOD and other internal processes to later share with the PO

It's a small team, only 4 developers and two of them are also PO, is not the ideal situation, but now it's our reality. 

I'd suggest that it might not be. The claim to have two Product Owners sugar-coats and thereby obfuscates a deeper problem. Two Product Owners means there is no Product Owner who is truly accountable at all.

Juan Cruz Thanks  for your comment.

Ian Mitchell they will be PO of different products, as I said, it's not the best situation (this 4 developers team and two of them also PO) but it's our reality now.

Thanks!

I am facing some challenges as a scrum master which I'll love to hear if anyone is facing the same and how you addressed it.

Background:

My team composition is somehow complex. I have business analyst (BA's), data analyst, developers and a project delivery manager(just another term my manager decided to call the PO)

Now the Ba's look after different departments within the company which means they work on different projects all the time. We have two backlogs. One for all BA work and another for all technical work.

We have one scrum team and we operate in two week sprints

Challenges:

1. Estimation is a real struggle as estimating BA's work isn't really working given they all worked on different projects. This leads to planning sessions taking too long and people coming out feeling drained as they have to do a lot of explaining to get everyone understand what they're trying to achieve for their respective projects so the whole team can collaborate with estimating. it's gotten to a point where we have decided to drop estimation for BA's work.
2. we barely have review sessions with stakeholders present and again this is because each BA collaborates individually with their stakeholders and collect feedback. 
3. In the one instance where we had the opportunity to have a stakeholder attend a review session, The BA involved expresses concern she doesn't think her stakeholder will be comfortable having the whole team present at the review as they aren't working on the project.

4. BA work can take a couple of sprints to materialize into technical work and most times it doesn't which means the developers have no sprint work each sprint but they are busy with other things like system support which isn't capture as part of our sprint work

   Just so I don't go on and on with a whole lot, these are a few challenges I am not sure as a scrum master how to address them and will appreciate input from anyone on how to navigate these without going against the scrum guide

The team should try to hold sprint meetings (Planning, Review, and Retrospective) within sprint boundaries as much as possible. But in order to reduce the risk of having unavailable stakeholders, I'd suggest:

1. Organize the sprint meetings in a way that participants can connect remotely
2. Record your meetings so that stakeholders can review them later
3. Don't schedule sprint meetings on Fridays and Mondays. People tend to take long weekends. Besides, statutory holidays often fall on those days which disrupts sprints' schedule and consistency