Sickness

What is the best way to account for this missing time?

Why is there a need to account for it?

It seems unfair that our Sprint would be finished with a certain % of work incomplete

Regardless of the percentage of work completed, was the Sprint Goal met? If not, at which point did it become clear that it was unachievable?

I feel it needs to be accounted for because we will not be able to meet our Sprint Commitment Goal with 1/3 of our team missing as much as 32 points apiece. This is not due to anything within their control (i.e. poor planning, taking on unplanned tasks, or misprioritization) so it seems amiss for the Retro to reflect work incomplete that was impossible to complete due to the change in capacity.

In the past, when one person has been ill, there hasn't been such a need for this, as the effort is usually more than made up by the rest of the team. But with so much unplanned capacity change, it seems like there should be some way to document it. 

It has become clear this morning that a decent amount of our work is unachievable due to the third member of our team missing a day for illness. Our Sprint closes on Wednesday morning. 

there was no way to plan for something like this during our Planning Meeting.

Sure there is a way to plan for this in Sprint Planning.... You plan for people to get sick. Don't plan for 10 days (if you've got a 2 week sprint), plan for 6. This anticipates time devoted to events and other meetings, technical issues that may come up, and even unexpected sickness with team members. 

What is the best way to account for this missing time? I

Who's saying the need this? If you're talking about going into your Sprint Review and explaining to your stakeholders that days were lost due to sickness, simply state that. Then say that you'll be accounting for unexpected issues like this going forward in Sprint Planning.

I think what Ian is saying here is an important consideration. If your team has a Sprint Goal that can no longer be met due to the unforeseen illnesses then it's important to make that transparent as soon as it is known. 

There could be some re-negotiating of the work required to meet the Sprint Goal with the Product Owner or even carry over into a following Sprint depending on how bad things got. 

If you're working with leadership that is looking closely at 'work complete' (vs outcomes or achieving the Sprint Goal) it will still be important to have that transparency around the impact of the sick days to 'work complete'. 

Hi Holly, it’s a good question. 

I have the same issue with sick leave and leave in general, although our business replaces those on leave (i.e. extended Christmas leave) I still lose productivity in story points due to hand over. 

Right now, the way I deal with it is to do what Tony suggested and talk to the Product Owner/Stakeholders about expectations and the Human Factor when delivering story points each month - we're not machines, we break, and we need rest.

Unexpected leave is hard to plan for so by keeping the expected outcomes as transparent as possible as early as possible you have a standing chance of a satisfied outcome.

Instead of just looking at the amount of work completed in the Sprint, consider the amount of work completed at reduced capacity.

Consider a few things:

Assuming that all working hours are dedicated to the Sprint is dangerous. You shouldn't assume that a person is dedicating 40 hours per week (or whatever your company's standard work week is) to the effort - there are a number of reasons why this would be reduced. Unless I have a better idea, I like to start with the idea that a person can effectively use about 60-65% of their time on their work with the rest on various "overhead" activities. About 24-30 hours is about how much time a person will spend on your work. Extremely optimized organizations can achieve higher numbers.

Your Sprint Goal should never consume 100% of your capacity. Assume that everyone on your team is pretty efficient and effective and is able to put in 30 hours/week on the work. If you were sizing your Sprint against that, your Sprint Goal would be at risk the moment something unexpected happens. Someone gets sick. A critical issue arises and needs someone's attention. Having a small amount of buffer lets you have a body of work that is allocated to the Sprint Goal and a body of work that can be swapped out, yet still feasible to complete in the course of the Sprint.

You should never plan your Sprints at capacity. This is an extension of not allocating 100% of your capacity to the Sprint Goal. Not only do you not want to put your Sprint Goal at jeopardy, but it's ideal to try to have all of the started work done by the completion of the Sprint. Undone work means that it goes back on the backlog and shifting priorities may mean that it remains undone for a while, and undone work is wasteful.

I believe a point made by Ian is crucial here.   At what point in the sprint did the Development Team determine that the Sprint Goal (and/or their sprint forecast) was at risk due to their reduced capacity?

This should be readily apparent if the Scrum Team works in an inspect/adapt manner, and they've been using the Daily Scrum as a key inspect/adapt event.

One principle to keep in mind regarding situations like the one you described is to be as pro-active as possible, and to avoid "reacting" to change.   It is far better to renegotiate scope based on reduced capacity, and to be creative around meeting the Sprint Goal, instead of letting circumstances outside of the team's control dictate how the sprint will play out.

Agree with Thomas, we should not be accounting 100% of the time that our teams are doing development work.

And you cannot account unplanned leaves, same as you do not know when you are going to get sick for the next week.

I feel it needs to be accounted for because we will not be able to meet our Sprint Commitment Goal with 1/3 of our team missing as much as 32 points apiece. 

Perhaps this is a time to also coach internal/external folks that the commitment is not to the Sprint "Plan". Since the plan is not a deliverable, success is about achieving a predictable outcome instead of being able to accurately predict what total work will be completed by Sprint end.

I'm still teaching folks at my current job about this misinterpretation. The Scrum Value of commitment lives internal as a piece of the recipe for success, saying that it is essential the team commits to the achieving the goals of the Scrum Team. The purpose of Sprint Planning is to create the Sprint Goal, representing the expected functionality of the Increment.