A developer had to take unplanned days off in the middle of the Sprint, causing an impact of less hours in the original capacity. It is possible to measure this in hours (e.g. 2 days = 16 hours).
So, where and how can I use this figure to improve my insights about the sprint progress? How can I identify the likelihood of the sprint being still completed using this new information? Should I add this to the burndown, like when there is change of scope by adding tasks in the middle of the Sprint?
People get sick, scope changes, and stuff happens. That's why velocity should always be measured as an average or a range, and primarily used as an upper bound on work selected for a Sprint rather than a target.
If you have sufficient slack in your Sprint Planning, a couple of sick days will not put your Sprint at risk. However, if you've stuffed your Sprint to the gills with work, you may or may not have a problem depending on whether the team has sufficient remaining capacity to meet the Sprint Goal.
Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.
The question is whether the team can still meet the Sprint Goal. The only way to find out is to ask them, and then track progress toward the Sprint Goal in your burn-down chart, Kanban board, Sprint Backlog, or other artifacts.
With sufficient slack and a cross-functional team, a well-planned Sprint will still be able to reach the Sprint Goal. However, if the team is not confident about reaching the goal with an absent team mate, then the Product Owner should be consulted. The Product Owner has the ability to renegotiate scope for the Sprint, or to cancel the Sprint and return to Sprint Planning, whenever the current Sprint Goal is at risk.
Your burn-down shouldn't change, because the Sprint Goal doesn't change just because the team's capacity does. What will change is your burn-down's trend line, which is as it should be. This is transparency in action!
Only change your burn-down chart to reflect Sprint Backlog Items added or removed from the Sprint Backlog. If the team determines that Sprint Backlog Items can be removed from the Sprint without endangering the Sprint Goal, then the work remaining in the Sprint will change accordingly.
In practice, you don't revise the entire burn-down chart. The removed work shows as a sudden drop in the x-axis at the time the work is removed from the backlog, but you wouldn't retcon the chart. Changes in the x-axis are normal in Sprints, as work may be added or removed from the Sprint Backlog throughout the iteration as tasks are uncovered through just-in-time planning, or as efficiencies are discovered or implemented.
How can I identify the likelihood of the sprint being still completed using this new information?
The team should handle this during the first stand-up, or a soon as they notice someone is sick, but let them self-organise. Maybe assist them with questions like:
It is always a good idea to make the Sprint smaller than the full Sprint forecast, so the team does not need to worry less about finishing the last couple of stories of the Sprint backlog.
Should I add this to the burndown, like when there is change of scope by adding tasks in the middle of the Sprint?
Does it help the team? If not don't do it. Don't administrate things for the sake of administration.
When the whole team is planning their next sprint, slack should be built in for sick leave, meetings, fixing live incidents etc. Over the course of a year, assume most people will take around half of their sick leave, do meetings and have to work on unplanned incidents. Your velocity should tell you how much the team can achieve in a sprint.
I would not try to quantify sickness as it might create a negative feeling within the team, like they are been punished for being ill etc.
What I would make known is planned time away. So in planning meetings ask the team who is on holiday, who is on training and who has planned absences from the sprint. The team should then take this information into account when committing to the sprint backlog i.e. selecting how many of the stories in the Product Backlog will be pulled into the next sprint and delivered.
You can certainly keep a history of notable events for each sprint and how it may or may not have impacted the velocity.
If unplanned days (6hrs = 1 day) are taken during the Sprint: - SM determines with the Dev Team the impact of the loss of the member. - SM determines with the Dev team if someone else can help complete the work. - Inform the PO of the impact (who should already know because they attend the daily scrum).
How can I identify the likelihood of the sprint being still completed using this new information?
Should I add this to the burndown, like when there is change of scope by adding tasks in the middle of the Sprint?
