Sprint Capacity, Velocity & Burndown Calculator

About the Sprint Capacity, Velocity & Burndown Calculator

Plan a sprint from what your team really has. Type each person’s hours, days off and share of time on the team, the time the Scrum events take and a focus factor, and the calculator gives the team’s capacity in hours for sprint work and, from your own past velocity, the points that fit when some people are away.

With the backlog left, a Monte Carlo forecast resamples your past velocities 10,000 times to give the number of sprints the work needs at P50 and P85, with the sprints’ end dates when you set a start date. During the sprint, type the work left each day for the burn-down against the ideal line and the burn-up against the scope. Velocity stays your team’s own planning number: it never compares teams or people. The free preview shows the capacity in hours and watermarked charts; the points, the forecast, the burn-down figures, the report and the chart file need a Pro pass.

How the capacity is worked out

For each person: days worked = sprint days − holidays − days off; hours available = days worked × hours a day × share of time on the team; event hours = planning + review + retrospective + the Daily Scrum on each day worked (never more than the hours available); hours for sprint work = (hours available − event hours) × focus factor. The team’s capacity is the sum.

Points that fit = your average velocity × this sprint’s capacity ÷ the usual capacity (the same team with nobody off), the usual “yesterday’s weather” adjusted for who is away. It assumes your past sprints had the team at its usual strength.

Event times from the Scrum Guide

The Scrum Guide gives upper limits for a Sprint of one month: Sprint Planning at most 8 hours, the Sprint Review at most 4 hours and the Sprint Retrospective at most 3 hours, “for shorter Sprints, the event is usually shorter”; the Daily Scrum is 15 minutes. The calculator starts from those limits scaled to your sprint (a two-week sprint: 4, 2 and 1.5 hours) and you set what your team really spends. A Sprint is a month or less.

The Monte Carlo forecast

Each of 10,000 runs plays future sprints: every sprint completes one of your past velocities drawn at random, and adds the work you expect to be added. The number of sprints until the backlog is done is counted; P50 is the count that half of the runs stay within, P85 the one that 85 of 100 do. The more sprints of history, the better: with only two or three, the forecast just repeats them. The Scrum Guide names burn-downs, burn-ups and cumulative flows among the practices to forecast progress, and adds that they do not replace empiricism.

Burn-down and burn-up

The burn-down shows the work left at the end of each day against the ideal line from the commitment to zero; the status says how far ahead or behind the ideal line the last recorded day is and the pace needed to finish. The burn-up shows the work done against the total scope, so work added during the sprint is visible instead of hiding in a flat burn-down.

Limitations

• Velocity depends on how a team sizes its work: never compare it between teams or use it to judge people.
• The focus factor and the event times are yours to set; the starting values are only a starting point.
• The forecast resamples your past sprints: it assumes the coming sprints are like them (the same team, the same way of sizing).
• At most 60 people and sprints of up to 60 working days.

Privacy

Everything is worked out in your browser. Your team, velocities and burn-down figures are kept in this browser on this device, so they are there next time, and are never uploaded. Reset deletes them.