Skip to main content

Handling absenteeism

Last post 09:31 pm April 21, 2021 by Thomas Owens
3 replies
09:44 am April 21, 2021

How a Scrum Master will manage where there are few "Must Have" stories are yet to be completed and on last day of sprint two team members took unplanned vacation. Other developers have already tasks in hand and have no bandwidth at all. How to take this issue to upper management?


07:08 pm April 21, 2021

Although temporarily losing developers could be seen as an impediment, it isnt something that the SM could easily remove unless they are able to acquire replacements from other development teams in house or from external sources. 

The best way this situation should be resolved is by the remaining developers having a discussion with the PO so that the sprints scope and be re-negotiated without jepardising the sprint goal. 

Another options would be to just ride the sprint out and then re-evaluate any non-Done PBIs before placing them back into the PB; however, this option could very well put the sprint goal at risk depending upon what the incomplete PBIs relate to.


07:41 pm April 21, 2021

How a Scrum Master will manage where there are few "Must Have" stories are yet to be completed and on last day of sprint two team members took unplanned vacation. Other developers have already tasks in hand and have no bandwidth at all. How to take this issue to upper management?

It doesn't sound like there is much of a team at all -- no teamwork is evidenced when planning for and accommodating vacation. Does upper management care enough about Sprint outcomes to communicate a sense of urgency for change?


09:31 pm April 21, 2021

I'm really sure that the Scrum Master should do anything.

The Developers are accountable for creating the Sprint Backlog and monitoring progress toward the Sprint Goal and adapting their plan to maximize the chances of achieving it. If this unplanned vacation will impact the ability to achieve the Sprint Goal, then the Developers should raise it as soon as they know.

Although it's in the context of work turning out being different than expected, the Developers are expected to collaborate with the Product Owner regarding the scope of the Sprint Backlog and the Sprint Goal. Members of the team being unavailable isn't the work being different, but the team's ability to do work is different. Ideally, there's room to figure out what changes can be made to the work to still achieve the Sprint Goal. In some cases, though, there may be opportunities to negotiate and redefine the Sprint Goal.

What I'm seeing isn't the sign of a healthy team. Although some things do come up outside of work that require a person's immediate attention, the use of "vacation" to describe what the team members are doing seems to imply that it's not illness, some kind of family emergency, a household problem, or a similarly urgent matter. The fact that this was sprung upon the team seems like there's poor collaboration and planning. It would be good if the team uses the Sprint Retrospective to talk about this and come to some kind of agreement, without escalating to "upper management".


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.