How to estimate sprint velocity with varying team capacity?

Question

We are a small team of 4 devs rather green in Scrum. Coming from all over the country, we often take odd days off or whole weeks off to go home. Therefore our team capacity changes dramatically from one iteration to another due to annual leaves, which leads to very different velocities from one iteration to another. How do we account for team capacity when estimating velocity at the Planning Meeting? Historical data will reflect very different capacities and we cannot wait one whole year to derive an average for our estimate velocity.

Answer 1

It might be a simple approach, but why don't you calculate your velocity as completed story points * capacity or completed story points / capacity, depending on how measure capacity. If you measure capacity in man-hours, use the second. If you measure capacity as a percentage of a 40-hour week, use the first. When you go to pull off story points, you should have a good idea about your capacity for a given sprint, and use your project's historical data to determine the story points completed for a given load.

However, this makes some potentially dangerous assumptions, such as treating all employees as equal - if your most junior developer takes a week off or the developer with the most experience in the domain and/or technologies takes a week off, your capacity will be the same numeric value, but the impact on velocity would probably be different.

Ultimately, use professional judgement based on historical data when planning a sprint. In this case, use previous velocity as an input into some other estimation scheme, involving the team. I would also err on the side of caution - it's easier to pull more work into a sprint than it is to remove a commitment to do a task.

Answer 2

Velocity can vary even if capacity remains same.

So just trust your velocity it will take care of varying capacity itself i.e. assuming you are into 3rd sprint, take average of the last two completed sprints to commit to the next sprint. do not worry about variance in capacity.

Answer 3

Velocity is a guide, not a measure. Just take the average of all your sprints (account for standard deviation) and the average of your worst three, the average of your best three and say "We'll definately get these done, we might get these done, we won't get these done." By drawing three lines through your (fully estimated) backlog using these three velocities and your rough deadline (pretend it's 12 sprints and 12x your worst velocity is 75, 12x your best is 120 and 12x your average is 90. In a backlog of 100 points, even at your worst, you could do three quarters of it, at your best you'd nail the whole thing and on average, you'd deliver most of it).

With this data, your PO can make all the decisions he needs in what he MUST have, we he would like to have and what he doesn't mind leaving out.

Ultimate, things change, requirements are emergent and, well, things will change again. Don't bust your chops on maths to get a specific figure, accurate ranges are enough for this kind of thing. Bust your chops on software problems, not on backlog maths.