Skip to main content

How to manage atypical non-working days during a specific sprint

Last post 07:49 pm April 13, 2020 by Marcelo Venturotti
6 replies
09:52 pm April 7, 2020

Hi guys!

I am working as a Scrum Master in a team and we have one problem with non-working days.

The situation is, we didn't prevent (before starting the last sprint) that we had 2 plus non-working days (holidays) at the final of the sprint. We start on Monday and end on Friday. So, we have realized about this situation during the actual sprint. I don't know what is the best solution for this situation. I have asked me, what is best to improve the teamwork? But I am really confused about how we should do.

About the options that we have managed are: 

- The first one is to maintain the original end date of the sprint and do the sprint review on the next working day (Monday after).

- The second is to change the ending date for this sprint to Wednesday and start a new sprint on Monday. 

So I will read you...

Thanks!


04:16 pm April 8, 2020

How do you handle the situation where you have gained new information during the Sprint that jeopardizes the Development Team's ability to meet the current Sprint Goal? Because in my opinion that is the exact situation you just described.  


04:53 pm April 8, 2020

Exactly what Daniel says.

Personally, looking at your options, there is one option which has effects on 1 sprint, and there is one option which effects 2 sprints. Going for consistency, I would go for the option with the least (side)effects. Next to that, changing sprint end date, and therefore changing the sprint length of the current sprint, is a big no no if you read the Scrum Guide. Even though the change might seem minimal, always stick to the SG. That said, you dont have to change the sprint end date, you can simply choose to have sprint ending events earlier.

In the end, the most important thing is: learn from it and move on ;)


06:47 pm April 8, 2020

Thank @Xander and @Daniel for your quick answers!!

I am at ease with 

How do you handle the situation where you have gained new information during the Sprint that jeopardizes the Development Team's ability to meet the current Sprint Goal?

Because the first thing that we have evaluated when we realized the new information, was thought about the Sprint Goal and made decisions to make it happen.

And I want to highlight this too

In the end, the most important thing is: learn from it and move on ;)

I really appreciate your opinion!


08:47 pm April 9, 2020

From the Scrum Guide in reference to the Sprint Planning event:

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. 

To me, there are two questions that jump out at me with this situation:

  • if team capacity was considered, were the 2 holidays simply missed?
  • if team capacity was not considered, why not?   It's right there in the Scrum Guide

In my opinion, this should not be treated like something that came out of nowhere mid-sprint.   Holidays are known well beforehand.

If there were truly an unanticipated impact to team capacity mid-sprint, that is a key benefit of the Daily Scrum.   The team should inspect and adapt based on their progress to date and their evaluation around meeting the Sprint Goal.


12:41 pm April 11, 2020

I generally agree with the advice you've received above, but to add some nuance about the Sprint Review, it is often worth considering the date and time that allows your key stakeholders to attend and participate.

Where I work, we run 2 week sprints from a Wednesday, with Sprint Reviews taking place on Tuesday afternoon. The time was chosen to allow our colleagues in New York  to participate (we're in Europe). We initially had them on Wednesday, but received feedback from our sales team that that particular day was their busiest time and they'd often struggle to attend.

In short, if it doesn't work for your stakeholders to attend a Sprint Review on Wednesday at particularly short notice, it might be more acceptable as an exception to have that event on a Monday.

Not that this is entirely down to the Development Team to have realized this, but perhaps it will help them anyway if they have a checklist of things to consider before forecasting what they can do. Known holidays would be an obvious thing to look at.


07:49 pm April 13, 2020

Thank you @Timothy and @Simon, I appreciate your opinion and highlights.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.