About

A burndown chart plots W (remaining work) against t (elapsed time) to expose the gap between plan and reality. The ideal line assumes constant velocity: W_ideal = S × (1 − t ÷ T), where S is total scope and T is sprint length. When the actual line drifts above ideal, the team is behind. When remaining work increases between days, scope creep has occurred. Misreading this chart costs sprints: teams commit to the next iteration based on flawed velocity data, compounding estimation error across the release plan.

This calculator generates a publication-ready burndown from raw daily data. It computes average velocity, detects scope additions, and projects a completion day if the sprint is at risk. The projection assumes current average velocity holds constant. That assumption breaks down when teams hit integration phases or holidays. Account for those manually. The tool approximates effort distribution as uniform across working days. Non-uniform distributions (e.g., front-loaded testing) will show as deceptive early progress followed by plateau.

Formulas

The ideal burndown is a linear function from total scope to zero over the sprint duration:

W_ideal(d) = S × (1 − dT)

The actual remaining work on day d is computed cumulatively:

W_actual(d) = S − d∑i=1 c_i

where c_i is points completed (or added, if negative) on day i. Average velocity after d elapsed days:

v_avg = S − W_actual(d)d

Projected completion day (if behind schedule):

t_proj = d + W_actual(d)v_avg

Where S = total story points (scope), T = sprint length in days, d = current day index, c_i = points completed on day i (negative value indicates scope addition), v_avg = average velocity in points per day, t_proj = projected day of completion. Scope creep is detected when W_actual(d) > W_actual(d − 1).

Reference Data

Metric	Formula / Definition	Healthy Range	Warning Sign
Sprint Velocity	v = S_completed ÷ T	80% - 110% of planned	< 70% or > 130%
Scope Creep	Days where W_d > W_d−1	0 - 1 occurrences	≥ 3 occurrences per sprint
Burndown Slope	ΔWΔt	Matches or exceeds ideal slope	Flattening in final 30% of sprint
Points Remaining at End	W_T	0	> 10% of S
Projected Completion Day	t_proj = t_now + W_nowv_avg	≤ T	> T (sprint will overrun)
Focus Factor	VelocityTeam Capacity	0.6 - 0.8	< 0.5
Standard Sprint Length	Scrum Guide recommendation	5 - 10 working days	> 20 days (not a sprint)
Ideal Daily Burn Rate	S ÷ T	Consistent day-over-day	Zero-burn days mid-sprint
Effort Variance	stdev(daily burned)	Low variance	High variance signals blocking
Commitment Reliability	Sprints completed on timeTotal sprints	≥ 0.8	< 0.6
Typical Team Velocity	20 - 40 SP/sprint (5-person team)	Stable over 3+ sprints	Varies > 30% sprint-to-sprint
Plateau Detection	2+ consecutive days with 0 burn	No plateaus	Indicates blockers or dependencies

Frequently Asked Questions

When story points are added mid-sprint, the remaining work W_actual increases, causing the actual line to jump upward. The calculator detects this by comparing consecutive days. Each scope addition reduces average velocity v_avg because the denominator (elapsed days) stays the same while less net progress occurred. The projected completion day shifts further out proportionally. If scope is added late in the sprint, the projection becomes unreliable because v_avg is diluted by early-sprint work that may not reflect current capacity.

The projection divides remaining work by average velocity: t_proj = d + W_now ÷ v_avg. This assumes the team burns at a constant rate, which rarely holds. Teams often have slow starts (sprint planning, context switching) and fast finishes (pressure, smaller remaining tasks). For sprints longer than 10 days, the linear assumption degrades. Weight recent days more heavily if you need a tighter estimate.

A healthy actual line tracks slightly above or below the ideal line, converging to zero by day T. Flat segments (plateaus of 2+ days) indicate blockers. A concave curve (fast start, slow finish) suggests the team cherry-picked easy stories. A convex curve (slow start, fast finish) often means large stories were completed late. The ideal pattern shows daily decrements within 1 standard deviation of S ÷ T.

In Scrum orthodoxy, partial credit is not counted. A story is either done or not done. This calculator accepts fractional inputs for teams that track sub-task completion or use decimal point estimates. However, counting partial work inflates perceived velocity and creates a misleadingly smooth burndown. If your actual line looks perfect but sprint goals are missed, partial tracking is likely the cause. Enter only fully completed points for accurate projection.

Yes. Entering a negative value for completed points on a given day increases remaining work, modeling scope additions. Conversely, if scope is intentionally removed (stories de-scoped), you can enter a completed value larger than what was actually done to reduce W_actual accordingly. The chart will show a steeper drop on that day. The scope creep counter only flags days where remaining work increased, not the reason.

Sprints of 5 to 10 working days produce the best signal. Shorter sprints (3 days) have too few data points for meaningful trend analysis. Longer sprints (15+ days) introduce too many variables (absences, priority shifts) that distort velocity averaging. The Scrum Guide caps sprints at 4 weeks (20 working days). Most high-performing teams use 2-week (10-day) sprints as a balance between planning overhead and feedback frequency.