Backlog points, average velocity, and sprint length in. A realistic finish date out — with a P50 best-guess and a P90 conservative date so you can talk to stakeholders honestly.
Std dev measures how much your velocity swings sprint to sprint. Lower = more predictable. Healthy teams sit under 25% of mean.
—
—
SprintFlint recomputes velocity, remaining points, and finish date on every closed ticket. No re-pasting numbers, no stale roadmap.
Start FreeP50 is the midpoint — half the time you'll ship before this date, half the time after. P90 is the conservative date — there's only a 10% chance you'll slip past it. Use P50 for internal planning; share P90 with stakeholders if you don't want to constantly re-negotiate the deadline.
Take your last 5-6 sprints' completed points. Calculate the mean. For each sprint, subtract the mean and square the result. Average those squares, then take the square root. Or paste them into a spreadsheet and use STDEV. If your velocity swings widely (std dev > 25% of mean), the forecast becomes much less reliable — fix the variability before trusting the date.
This calculator assumes velocity stays roughly constant. If you're hiring, ramp 10–20% over 2-3 sprints, not on day one. If you're losing people, drop velocity proportionally. Re-run the forecast after every change — agile forecasts decay fast.
After every sprint. Velocity, scope, and team shape all change. A forecast made 4 sprints ago and never updated will be wrong by sprint 5. Tools like SprintFlint update this automatically as work moves.
Long-runway forecasts (10+ sprints) are mostly noise. Either slice the scope into a smaller MVP, raise the team size, or commit to the date as a "ballpark, not promise". Anything else is wishful thinking.