Holidays and Illnes

Hi Marco,

I like to let the team decide. They are asked to forecast a certain amount of work for their Sprint and should take holiday and sick time in to account. As a Scrum Master you can remind them of these obstacles, but it is ultimately up to the team. If they feel they can do just as much work, then let them rise to the occasion. But the odds are that it will impact your velocity, but so will a lot of other things along the way.
I would certainly avoid extending the Sprint or creating sicktime/holiday PBIs.

Does that make sense?

Don

"PBI Illness or Holidays"
How would this help?

"Do nothing?"
Happy Holidays and get well are always welcome. Other than that, I like
this option.

"include it in the velocity calculation"
How would you do this? If someone is sick or there is a holiday, can we
presume you have done less as a result? By summing the features you *actually
complete* doesn't that reflect your *actual *velocity?

"Extending the Sprint length"
This is evil. The timebox is, among other things, a tool for inspection.
If you have a two week sprint and then go to a three week sprint, you
can't assume you'll do 2/3 of the work in your next two week sprint.


On Wed, Nov 7, 2012 at 11:07 AM, <ScrumForum@scrum.org> wrote:

>

Marco,

When you said:
"- Should I include it in the velocity calculation (how?) "

Did you really mean this?
"The team sometimes uses historical velocity as one of many tools for forecasting the amount of work possible in an upcoming sprint. Once the team has estimated velocity(based on historical values, aka "yesterday's weather), should the team adjust it down for planned time off or holidays?"

If you did, then my answer would be this:
That seems fine, so long as you remember that 'commitment based estimating' is also a very useful tool for forecasting the amount of work possible in an upcoming sprint. Commitment based estimating is along the lines of "gut feel" or "team consensus" -- though there's more to it than that. See "commitment based planning" in Cohn's _Agile Estimating and Planning_ for more details. I coach most teams to do *both* velocity based and commitment based planning, but to, in the end, make a team consensus decision. I should also mention that using historical velocity to forecast the amount of work in a single sprint is probably not as useful as using it for longer term milestones like releases. Using it for longer term milestones is really what the concept of velocity was designed for.

Hello,

In our project, we estimate/plan for some buffer time (sufficient to absorb 1-2 unplanned leaves) and that is visible to the product owner as well. This is to ensure any unplanned/sick leaves don't impact the sprint outcome.

Also, we have something called 'stretch tasks' which are extra few (low priority) tasks and are only accommodated into the sprint when there is a smooth sailing without any leaves/impediments.

Don't you feel like buffers decrease transparency? The progress of the Sprint will naturally show what is and is not possible. The outcome of the Sprint is a forecast and every day the Development Team checks on their forecast to update it via the Sprint Backlog, not?

Well, we are currently still adapting to the Agile/Scrum way of project execution, and haven't reached a point where we have confirmed the team's velocity and are able to navigate around unplanned leaves, etc. We have been executing the project in a traditional model for so long, that the timelines/deliverables are considered to be rigid.. hence the idea of buffer to maintain everyone's confidence levels..

But in the true sense of scrum, I agree we should learn from previous forecasts and take it from there. Hopefully in next 1-2 sprints, we will be there.

Two aspects: General holidays and individual vacation/sick leave

Individual vaction:



I kinda like the idea of random vacation: Let the team members take vacations even on short notice (maybe a sprint in advance). A solid scrum team should be able to handle it. If they can't handle it, it will uncover problems the team might need to tackle during the next retrospective. It's similar to how a strong pull for a Kanban system uncovers problematic spots in the value chain. I admit that this is a bit radical though :D.

In general, the team should handle that amongst themselves without anyone from outside needing to interfere (or even know). A responsible and respectful team member will inform their colleagues about planned vacation and the team should be cross-functional enough to handle their work. Of course the team will reduce the workload they forecast for the sprint.



Illness:

This is mostly unplanned and can happen anytime. The team will adapt and maybe they get less done. But that shouldn't be a problem. Do not extend the sprint though: The sprint is the rhythm – like in a song you wouldn't extend a bar of music and interrupt people's dance moves just because you couldn't play all the notes; just play the notes in the next bar.



General holidays:

If it's 1-2 public holidays, simply remind the team so they can adjust their forecast in the sprint planning. If it's more days, I like to think about the sprint in terms of net (working) days: A two week sprint has 10 net days to work. That 10 net day sprint could easily take three calendar weeks around New Year's. I try to always keep it aligned to aligned to weeks, so that the scrum events still continue on the same weekday. If you have 7 workdays days off over New Year's, either a) plan to finish a sprint before holidays and start the next after or b) plan a 8 workdays sprint over 3 calendar weeks (15 days - 7 holidays).

This is a very interesting topic and I think every team approaches the issue in its own way. For our team I try to stabilize our velocity, so we calculate planned PTOs and holidays and adjust our capacity correspondingly. Also, we track unexpected off hours. At the end of the sprint we adjust the amount of completed points as if we had 100% availability.

E.g. our input is - 2w sprint(10 working days), average velocity = 50, 10 devs in the team.

If one of devs will be on vacation for 5 days, it means that planned working days will be 95(10 devs * 10 days - 5 days for vacations). Therefore sprint capacity will be 47.5 (50 velocity * 95 planned working days / 100 avg working days). Let's round this to 48.

In the end of the sprint team completes all work, which is 48 points, but for calculating avg. velocity for the next sprint we'll use value 51 (48 * 100 / 95 = 50.53. I round this to 51) instead of 48.

This way our velocity doesn't fluctuate a lot because of team inavailability and the team always have relatively the same amount of work.

The con of my approach is that calculations are linear, so every developer is assumed to have the same performance as other devs. But for now we're satisfied with what we have and we don't plan to change our approach.