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.

3 Answers 3


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.

  • Exemplifying the rationale with numbers, say at the end of Sprint n we have: 17 completed story points * 0.97 (1 dev's day out) = 16.49 velocity; using the other formula, 17 sp / 0.97 = 17.52. Now, comes the question. On the Planning Meeting of the follow Sprint (n+1), with a current capacity of 0.875 (5 days off among devs), what is our expected velocity? How do we estimate what we can accomplish with the reduced capacity?
    – Pomario
    Feb 7, 2012 at 10:55
  • @Pomario I'm assuming 2 week, 40 hour/week, 8 hour day sprints. Assuming one person took one day off, the capacity should be 0.99 for the first formula or 72 for the second. This gives you a computed velocity of either 16.66 or 0.24. Your capacity for the next sprint would be either 0.5 or 40. Plug the previous velocity and expected load into the equations. This means that you should bring in between 8 and 10 story points, since you multiple the completed velocity by your expected load. I'd err closer to 8 or 9. (Someone might also want to double check my math - I'm a bit sick today.)
    – Thomas Owens
    Feb 7, 2012 at 18:15
  • I just realized I made a mistake - the first capacity would be 0.90, not 0.99, as 8 hours is 10% of an 80 hour work week. That means the computed velocity for the first sprint would 15.3. However, the analysis of the data doesn't change.
    – Thomas Owens
    Feb 13, 2012 at 11:24

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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