Guenov Labs
More free tools

Free tool

Jira completion date estimator

Enter what’s left in the backlog and how fast the team has been moving, and this projects when it’ll likely be done — with an honest range, not a single falsely-precise date. Everything runs in your browser; nothing is sent anywhere.

Your backlog
Remaining work, velocity and sprint length.
Measure work in

Total story points left in the backlog for this piece of work.

Story points the team completes in a typical sprint.

±20%

How much your velocity typically swings sprint to sprint. Widen it if your velocity is unstable; narrow it if it’s consistent.

Projected completion

Enter a positive velocity and a sprint length up to 90 days to see a projection.

How this is estimated

Sprints remaining is remaining work divided by velocity, rounded up to a whole sprint. The likely date adds that many sprint lengths to your start date.

The optimistic and pessimistic dates redo that math with velocity nudged up or down by the variance percentage you set — a simple, transparent way to show a range instead of a single number that implies more certainty than any velocity-based forecast actually has.

Caveats worth knowing
  • This is a forecast, not a promise. Velocity fluctuates between sprints for reasons a simple average can’t see coming.
  • Scope changes aren’t modelled. If the backlog grows after you run this, the projection is stale — re-run it with the new total.
  • It assumes every future sprint runs at full length and full capacity. Holidays, team changes and partial sprints aren’t accounted for.
  • Story points and issue counts are only comparable to velocity measured in the same unit — make sure your velocity figure uses whichever unit you picked above.

Questions

How is the completion date calculated?
Remaining work is divided by your average velocity per sprint, rounded up to a whole number of sprints, then that many sprint lengths are added to your start date. It's simple arithmetic, not a simulation — the honesty comes from showing a range instead of one falsely precise date.
Why does it show a range instead of one date?
Velocity varies sprint to sprint — scope changes, people take leave, estimates are wrong. A single date implies certainty that doesn't exist. The optimistic date assumes velocity runs above your average by the variance percentage; the pessimistic date assumes it runs below. The likely date uses your average as entered.
What should I set the velocity variance to?
Default is ±20%, a reasonable starting point for a team with a few sprints of history. If your velocity has swung a lot recently, widen it. If it's been steady for many sprints, you can narrow it — but don't narrow it to 0%, since that puts back the false precision this tool is trying to avoid.
Does this account for holidays, scope creep, or team changes?
No. It only projects forward from the velocity and remaining work you enter right now. If your backlog grows, your team changes, or a sprint is shortened by holidays, re-run the estimate with updated numbers — that's the honest way to keep a forecast current.

A free tool by Guenov Labs.