nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to account vacations during sprint planning ?

Sharon Sahar

Hi,

What is the best practice to apply during sprint planning for employee's vacations?

I can think of 2 options:

1. Create a vacation task with the right amount of sp.

2. Create a sprint with smaller velocity.

The reason I think about option1 is because i want to have a velocity for that sprint that could later be used in the average calculation with other sprints to discover the average velocity for full week.

What do you think?

Accepted answers

Scott Theus

Hi Sharon,

I would suggest that you create a sprint with a smaller velocity to adjust for the person that will be out of the office. I'm assuming, based on your other post, that the team has not been running sprints for more than a year so you don't have sick days, other vacations, or have had the team perform above or below the typical capacity from time to time. If you do, then your velocity should already have those values built in. If not, then use an estimated fudge factor to reduce the number of story points and provide an attainable goal.

And...don't forget to ask the team what they think during sprint planning!

-Scott

All comments

Scott Theus

Hi Sharon,

And...don't forget to ask the team what they think during sprint planning!

-Scott

Sharon Sahar

You assume correctly.

So we started scrum 3 weeks ago and have an average velocity of 100 for a full work week. I was sure the idea was to run few sprints and then average the velocity in order to find the correct value for full work week, and for this, it seems that I need to create "vacations tasks".

Isn't running for a year and including vacation is a completely different manner and another velocity calculation?

Scott Theus

I think at this stage of your scrum team development adding in vacation stories could create an artificial velocity that, over time, would impact your ability to plant the work the team is able to accomplish over the long term. Instead, keep the velocity based on the true work done over the last three sprints and add a risk contingency plan for vacations, unplanned leaves, sick time, etc.

When planning the number of sprints for the project you can write a risk for unplanned time off, vacations, etc. and use that to estimate a risk reserve for either points or the number of sprints. When the sprints are completed the velocity will naturally adjust for the work the team is able to complete when fully staffed, short a person for a day or two, or if someone goes on vacation. You can then use that velocity as a reliable measure of how much work the team is able to accomplish over a longer period of time. Meanwhile, you have the contingency reserve (perhaps as an extra sprint for risk mitigation) that covers you for shorted sprints.

Don't get me wrong, you can certainly use a vacation task to adjust the velocity of the team when someone is out of the office, I've just found that engagement tends to be more receptive to a risk contingency that may or may not be needed than the are for a vacation task that adds story points for work that isn't really work.

Hope this helps...

-Scott

Menaka

Vacation time is easy to be accounted in Sprint Planning -either we could modify velocity or adjust the sprint goal but what about the sick leave ?

Scott Thurston_22s9a2

My teams have lowered the goal for the sprint due to known vacation, out of office, training classes etc. We look at the past average velocity and reduce it by a point amount for the number of vacation days, and other non-development work.

I think this allows your team's velocity to reflect the amount of delivered business work and does have include fake vacation points in the velocity.

Scott Theus

Sick leave is an unplanned for event that occurs during the sprint and impacts the amount of work the team is able to accomplish. I recommend closing the sprint sort of complete, moving the unfinished stories to the backlog or to the next sprint, and addressing the shortage in the retrospective. Over time that allows the team's velocity to adjust naturally.

For example, imagine a team with 4 sprints under their belt, with story points of 35, 38,40, and 33. This gives a velocity of 37 points based on the last three sprints, and 36 points overall.

For the 5th sprint a team member misses two days of work and the team completes 25 of the planned 36 points. The velocity drops to 32 points for the last 3 sprints, 34 points overall.

In sprint 6 the team plans for 32 points based on the current velocity, but with the sick team member back at full force they complete 36. Velocity is 31, overall it is still 34.

For sprints 7-9 they complete 35, 37, and 40 points. At the end of these three velocity is back to 37 points, overall it is 35. This is right in range with the initial velocity of 37 points.

During sprint planning a team member says they are going to take a day off, so you can estimate that you will lose 5 points of work (half of the 10 points lost in sprint 5) and make your sprint 32 points. The team should be able to complete this amount of work in the sprint, based on prior history.

-Scott

(BTW...Apologies for the late response...I didn't see your question until @Scott Thurston posted his response today)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

scrum

sprint