Lean Developer Weblog dedicated to lean and agile sofware development

Scrum Team availability

If you read XP or Scrum books or online sources you find that team is a stable group of developers who work full-time to accomplish the goal. The recommended way of estimating its capacity is to use historical velocity and team members report effort remaining in hours to have daily updates of the burn down charts.

In agile estimation the estimate of the complexity of the features, often expressed in story points, is the easy part though not trivial. In my thesis I have a small experience report about the variability of the feature sets, but I will leave that now. Instead I want to talk about the variability of the team’s capability to implement what they have promised.

In real life the organizations are not so lean that they have dedicated teams for the development. Instead, each developer has responsibilities in multiple projects and also critical maintenance work that must be done as soon as possible. An of course, they are also vacations, trainings, corporate administration and common meetings.

Some the capacity variation mentioned in the previous chapter is known or can be estimated in the Sprint planning. Using just velocity averages assumes that this variability is irrelevant and averages out in a large number of Sprints. But if we know that most of developers have their vacation in July, then it is just reasonable to take that into account and adjust the promises accordingly. In my own Sprints I have asked every developer individually how many person days is he/she available for Sprint work. That is best guess of the capacity at the moment. An then the team limits the work into that. Naturally, there is a mathematical relation between velocity in story points and capacity in person days. So you can still use story points as your unit if you want.

We could argue about the best guess of the capacity. In historical average velocity we take into account the average changes of the availability of the developers, because we count only the story points of realized features. It could be better estimate of the capacity if the developers have optimistic bias in the Sprint planning. But in averages we don’t have known capacity deviations as we have if we ask the capacity from the developers.

The real variability of the capacity occurs during the Sprint. It is not enough that team members report the effort remaining of each task. Suppose that I have promised to be available 15 person days in the Sprint and I get an urgent need to put 10 days to something else. Then it is quite natural that I tell that as an impediment in the daily Scrum as soon as I know about it. The consequence might be that a feature is taken away from the Sprint. Obviously the burn down chart would have told the same thing but not so early.

I think that it is relevant to take availability variations into account in Agile projects, because they have impact on the stress level of the developers with all of its consequences. The variability has also consequences in releases especially when we work in a project which has many teams that depend on each other. Realistic daily view of situation is needed.

That’s it today. A long story of a small but important detail.