Flocci Projects

Home › Agile answers › How do I calculate sprint capacity?

How do I calculate sprint capacity?

Start with your average velocity over the last three completed sprints, then adjust for this sprint's reality: subtract proportionally for leave, holidays, on-call load and known interruptions. If velocity is 21 and one of three engineers is away half the sprint, plan for roughly 17, not 21.

Step by step

  1. Take the velocity average. Average the Done points from your last three completed sprints. This is your baseline and it already includes normal overhead like meetings and code review.
  2. Subtract known absence. Count person-days lost to leave, holidays and training as a fraction of total person-days, and reduce the baseline by that fraction.
  3. Reserve for unplanned work. If bugs and support routinely consume capacity, reserve a percentage rather than pretending they will not arrive. Ten to twenty percent is typical for a team that also runs production.
  4. Commit below the number. Plan to the adjusted figure and stop pulling there. A sprint that finishes early is a gift; a sprint that finishes at eighty percent is a demoralising failure with the same amount of work done.

Why hour-based capacity maths misleads

Multiplying headcount by working hours produces a number nobody achieves, because it ignores meetings, review, context-switching and the fact that nobody writes code for eight uninterrupted hours. Velocity already has all of that baked in, which is exactly why it is the better starting point.

The unplanned-work reserve

Teams that also run production consistently lose capacity to interruptions and then treat it as a surprise every sprint. Naming a reserve turns a recurring failure into a planned allocation, and if the reserve goes unused the team pulls one more item — a far better problem to have.

Doing it in Flocci Projects

The sprint insights panel shows average velocity across completed sprints and the per-sprint trend, and the sprint planner sums points live as you scope. Workload by assignee catches the second failure mode — a sprint that fits in total but is entirely stacked on one person.

Try it on a free Flocci Projects board

Related questions

What if we have no velocity history yet?

Plan the first sprint deliberately small — roughly half of what feels right — and treat the result as data rather than a failure. Two or three sprints in, the average becomes usable and guesswork ends.

Should new joiners count toward capacity?

Not at full weight for the first sprint or two, and remember they also consume an existing member's time. Many teams count a new engineer at zero for their first sprint and are pleasantly surprised.

How do I handle a sprint with a holiday week?

Reduce proportionally by person-days lost, not by calendar days. A festival week where three of five people are away is roughly a sixty percent sprint, and pretending otherwise just relocates the failure to sprint end.

More agile answers