Forums

What should I do if one of my Team-Members is Ill or in Holidays.

- Should I handle it as a PBI Illness or Holidays?

- Should I do nothing?

- Should I include it in the velocity calculation (how?)

- Extending the Sprint length is probably against the rules.

- Other solutions?

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.