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

Last post 03:52 pm October 11, 2019
by Timothy Baffa
10 replies
Author
Messages
12:13 am July 23, 2018

Hi,

I would like to ask a question... we are doing 2-week sprints and our scheduled sprint review is on a Friday evening. However, due to bad weather, the product owner and the stakeholder is not available on that day. They are available on Monday evening. As a Scrum Master, should I extend the sprint to accommodate their availability? What should the development team do while waiting for the Sprint Review?

Thanks,

Harley

03:29 pm July 23, 2018

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.

05:27 pm July 23, 2018

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.

09:08 pm July 23, 2018

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.

01:50 am July 24, 2018

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.

06:12 am July 24, 2018

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

 

02:25 pm July 24, 2018

+1 Niels.

10:37 am October 8, 2019

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. 

07:00 pm October 9, 2019

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.

 

 

02:42 pm October 11, 2019

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. 

03:52 pm October 11, 2019

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.