Handling Absence in Scrum Teams

We don’t use scrum as such, but we still face the issue of team-member absence during fixed iterations. It’s a tricky one to deal with, especially as absence comes in both predictable and unpredictable forms.

InfoQ has a nice summary of some of these issues and some solutions. There is till no “silver bullet” for this, though. Losing staff will almost always mean losing productivity, which in turn means that iteration (“sprint”) commitments will need to be renegotiated, which works best if stakeholders are informed as soon as possible.

InfoQ: Handling Absence in Scrum Teams

2 Comments

  1. Besides informing about absence (hence risk to sprint commitments ), what is the recommended process for giving a a regular progress update to stakeholders? As stakeholders aren’t part of daily stand-up meetings, everything gets postponed to further offline action items. When every action items get postponed daily scrum meetings become life-less and hence boring. Will you suggest a way out?

  2. Interesting question. I guess the strict Scrum answer is that every sprint has a product owner, who is actively involved in answering question, ad-hoc prioritisation, and monitoring progress (using artefacts such as burn-down charts.) The point of the daily stand-up meeting is primarily to share information between team members, and to highlight problems and potential blockers rather than to report progress.

    In practice I have often found that it is hard to get real stakeholders that involved on a day-to-day basis. It’s particularly tricky in our situation where the development team acts on behalf of several different stakeholders and customer managers, often with very different priorities.

    My practical answer is probably that all of these things are a judgement call within the team. If information transfer to and from stakeholders is a problem, then find out a bit more about where the real problems lie (what information is actually needed, where does it originate, etc.) and build some process or some system to solve it.

    Such a solution could be as simple as a BVC (“Big Visible Chart”) – we use one whole wall of our engineering office as a huge interactive display showing the status of all work that we know about, for example. For more distributed teams a software solution might be more appropriate – we are also experimenting with a small change to the format of check-in comments and some software to extract and summarise development activity from that data.

    We don’t currently deal with absence in an explicit manner, although we do check in everyone’s actual and planned leave details into subversion so they may be read by anyone who needs to know.

    Do you have any ideas?

Comments are closed.