4

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?

7

How to Plan for Unplanned Absences

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.

Focus on 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.

How This is Reflected in a Burn-Down Chart

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.

  • I don't understand: how can a range be used as an upper bound? – onedaywhen Aug 20 '18 at 12:45
  • @onedaywhen you use the upper bound of your range as the upper bound of the selected work. The bigger your velocity range, the more uncertainty in what your team can accomplish, and the more they need some extra slack to learn how to become more predictable. – Erik Aug 21 '18 at 5:32
3

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:

  • Can we complete the work partially finished by this developer?
  • Will we make the Sprint goal, if not do we need to adapt to maximize value delivery with the new capacity?
  • Do we need to communicate which stories of the forecast we won't finish, if so to whom? (e.g. clients, product owners, other teams depending on stories, etc.)

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.

  • "Can we complete the work partially finished by this developer?" - Yes and something for the Retro might be, "Shall we increase pair programming to mitigate this impediment reoccurring?" – onedaywhen Aug 20 '18 at 11:33
1

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.

0

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?

  • unless the Dev Team agrees to absorb the work,
    • the work will not be completed.
    • inform the PO & other interested parties of the impact

Should I add this to the burndown, like when there is change of scope by adding tasks in the middle of the Sprint?

  • Once the Sprint is started, new work should not be added or removed from the Sprint. The Dev Team has committed to delivery.
  • 3
    This is not true: "new work should not be added or removed from the Sprint." New Product Backlog Items should not be added, but the Sprint Backlog is the team's to manage within the Sprint. Sprint Backlog Items can be added or removed at the Development Team's sole discretion. In addition, scope changes that don't endanger the Sprint Goal can be negotiated with the Product Owner at any time. – Todd A. Jacobs Aug 14 '18 at 14:05
  • 2
    In Scrum teams do not commit to delivery, they forecast delivery. This was a official Scrum guide change in 2011: scrum.org/resources/commitment-vs-forecast – Niels van Reijmersdal Aug 14 '18 at 14:05
  • Also, the PO doesn't have to be at the Daily Scrum. (Neither does the SM). And the SM doesn't have to "determine with the team" either, unless the team asks them to. It's the team's own responsibility to manage this. – Erik Aug 21 '18 at 5:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.