The story points you can safely commit — after PTO, holidays & focus factor
Default day per member is overridden in the roster below. Use ~6 "ideal" hours or 8 clock-hours × a real focus factor — not both at full value.
FTE % = availability (50 = half-time). Mtg hrs = ceremony/meeting hours per person this sprint — leave 0 if you've folded meetings into the focus factor (recommended) to avoid double-counting.
Velocity is averaged across the sprints you enter. Leave baseline blank to assume past sprints had this sprint's staffing.
Scrum teams over-commit when they pull story points off a backlog without checking who is actually available. PTO, a public holiday, a part-time member, and the real meeting/interruption overhead all quietly shrink the hours left for delivery. This planner computes realistic capacity per person, sums it across the team, applies your focus factor, and then scales your rolling velocity by how this sprint's capacity compares to your normal — landing on the story points you can safely commit. Everything runs privately in your browser, free.
avail_days(i) = max(0, sprint_days − holidays − PTO(i))
gross_hours(i) = avail_days(i) × hours/day(i) × (FTE%/100)
member_hours(i) = max(0, gross_hours(i) − meeting_hours(i))
RAW = Σ member_hours(i) (raw available hours)
NET = RAW × focus_factor (net productive hours)
V_avg = average of entered sprints (rolling velocity)
BASE = entered baseline, else NET
R = clamp(NET / BASE, 0.1, 2.0) (capacity ratio)
FORECAST = round(V_avg × R) (points that fit at full capacity)
COMMIT = round(FORECAST × buffer) (default buffer 0.85)A team of 4 runs a 10-day sprint, 8 h/day, focus factor 0.70, with 1 public holiday. One developer is half-time (50% FTE) and another has 2 PTO days; the rest are full-time with no time off. Per-member available days are 9 each (10 − 1 holiday), minus PTO where applicable:
RAW = 72 + 56 + 36 + 72 = 236 h. NET = 236 × 0.70 ≈ 165 productive h. Their last four sprints completed 30, 34, 28, 32 points → V_avg = 31 pts. With the Baseline capacity left blank, the tool assumes past sprints had this sprint's staffing — so BASE = NET and the capacity ratio R = 165 ÷ 165 = 1.00. Forecast = round(31 × 1.00) = 31 pts, and at an 85% buffer the recommended commitment = round(31 × 0.85) ≈ 26 points — with a stretch ceiling of 31. That gap between 31 and 26 is the slack that absorbs the unknown.
Want the ratio to reflect a fuller "normal" sprint? Enter that team's full-staff productive hours in Baseline capacity. Here, a baseline of 190 h would give R = 165 ÷ 190 ≈ 0.87, a forecast of ≈ 27 pts, and a recommended commit of ≈ 23 pts. The tool never fabricates a baseline on its own.
Per person: (sprint days − holidays − PTO) × hours/day × FTE%, summed across the team for raw available hours, then multiplied by your focus factor (typically 0.70) for net productive capacity. Computing it per person is what makes part-time members and individual time off accurate.
Average completed points over the last 3–5 sprints (rolling velocity), scale by this sprint's capacity ratio to get the points that fit, then take ~85% of that as the recommended commitment. The full figure is your stretch ceiling.
Start at 0.70 (industry range 0.6–0.8). After a few sprints, derive your own by dividing average velocity by raw available hours. Don't subtract meeting hours and use a low focus factor at the same time.
Velocity reflects the staffing of the sprints it was measured on. If this sprint has more PTO or a holiday, the capacity ratio scales it down to match who's actually available. One sprint is also noisy — average 3–5.
No. Without recent completed points there's nothing to scale, so the tool shows hours-only capacity and asks for 1–5 sprints. It won't invent a points number.
Yes — 100% free. Everything is calculated privately in your browser; nothing is stored or sold.
Everything is calculated in your browser. We don't store or sell your data.