Change the Scrum Guide
What is Scrum?
Definition of Done
Scrum and Agile Webcasts
Professional Scrum Foundations
Professional Scrum Master
Professional Scrum Product Owner
Professional Scrum Developer
Java - Topics Covered
.NET - Topics Covered
Scrum Open Assessment
Developer Open Assessment
Professional Scrum Master Assessments
PSM I Assessment
PSM II Assessment
Professional Scrum Product Owner Assessments
PSPO I Assessment
PSPO II Assessment
Professional Scrum Developer Assessments
PSD I Assessment
PSD Objective Domain
Work With Us
Logo & Links
By posting to our forums you are agreeing to the
Holidays and Illnes
Last Post 12 Nov 2012 04:23 AM by KetanDeshpande. 6 Replies.
Most Recent First
You are not authorized to post a reply.
07 Nov 2012 10:07 AM
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?
07 Nov 2012 10:52 AM
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?
07 Nov 2012 11:15 AM
"PBI Illness or Holidays"
How would this help?
Happy Holidays and get well are always welcome. Other than that, I like
"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:
Charles Bradley - Scrum Coach and Trainer
07 Nov 2012 11:45 AM
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.
11 Nov 2012 03:44 AM
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.
11 Nov 2012 12:20 PM
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?
12 Nov 2012 04:23 AM
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.
You are not authorized to post a reply.