Sprint capacity planner

A team of five in a two-week sprint does not have four hundred hours. Put in absence, ceremonies and your focus-factor assumption, and see how much of that number is really on the table. Built for teams with no delivery history yet - if you have a few sprints of finished-item counts, count instead.

Your sprint

Team members

Working days in sprint

Hours per person per day

Focus factor - your assumption

70%

What your last few sprints suggest, not what the next one will be. The share of the remaining time you expect to reach sprint work after support, interruptions and admin.

Ceremony hours per person Planning, refinement, review, retro and stand-ups, per person, per sprint.

Holiday / absence days Total across the whole team for this sprint.

Ceiling for sprint work

Sprint work
Focus-factor assumption
Ceremonies
Absence

Raw team hours-

Holiday / absence-

Ceremonies-

Focus-factor assumption-

Per person, on average-

Where the four hundred hours go

The four hundred usually arrives before the team has said a word. Five people, ten days, eight hours: someone has done that sum in their head, and it has quietly become the expectation. This page takes that number apart. It doesn't recommend planning in hours; it shows what the raw sum leaves out.

Ceremonies are real work time. Planning, refinement, review, retro and ten stand-ups add up to somewhere between five and eight hours per person per sprint. That's most of a day each, gone before anyone opens an editor.

Focus factor is an assumption, and it should look like one. It stands in for everything that isn't sprint work: production support, interruptions, hiring interviews, the incident on Tuesday and the twenty minutes it takes to get back into a task after each of those. A figure from your last sprints describes those sprints; it doesn't predict the next one. Use it to question a plan that quietly assumes 100%, not to promise a number. A plan that assumes 90% isn't planning, it's hoping.

Absence is lumpy. One person on holiday in a two-week sprint removes 10% of a five-person team's capacity, and if that person is the only one who knows the payment integration, it removes rather more than that.

A ceiling, not a target. The number is the most the arithmetic allows if the sprint runs normally. Plan well under it and let the team pull more in when there's room. Nobody should be measured against it.

The number bounds the conversation. The sprint goal is what the work is for. Capacity says roughly how much room there is; it says nothing about what's worth doing with it. Agree the goal first - the outcome the sprint exists to move - then pull in the smallest set of items that serves it. A sprint that meets its goal with room to spare is a good sprint, whatever the hours say.

Planning against the wrong number? Let's talk All free tools

Have a few sprints of history? Count instead.

This calculator is for a team with no delivery history yet, facing a stakeholder who has already done five times eighty in their head. Once you have a few sprints behind you, counting beats it.

Slice backlog items to roughly the same size. This is the hard part, and it takes most teams a couple of months before they do it without thinking.
Run the sprint. Count the items that actually met the definition of done.
Take no more than that count into the next sprint.
Repeat. After a few sprints the counts give you an average and a range - a forecast built from what the team actually finished, not from what the hours said.

The maths is counting. If you need dates, the release forecaster turns an average and its spread into best, likely and worst-case dates. It's a simple range, not a statistical forecast, so treat it as one.

Embed this tool on your site

Free to use. The line under the frame is the only thing I ask for - please keep it.

<iframe src="https://veljkobarnic.com/tools/sprint-capacity/embed/"
        width="100%" height="860" style="border:1px solid #e1dad9;border-radius:12px"
        title="Sprint capacity planner" loading="lazy"></iframe>
<p style="font:14px system-ui;color:#666">
  Sprint capacity planner by
  <a href="https://veljkobarnic.com/tools/sprint-capacity/">Veljko Barnić</a>
</p>

Optional - add this if you would rather the frame resize itself to the result:

<script>
window.addEventListener("message", function (e) {
  if (!e.data || !e.data.vbEmbed) return;
  var f = document.querySelector('iframe[src*="/tools/' + e.data.slug + '/embed/"]');
  if (f) f.style.height = e.data.height + "px";
});
</script>