ForHosting KIT · Developer Utilities

Backlog completion sprint count calculator

The backlog completion sprint count calculator turns a remaining story-point total and an expected delivery velocity into a practical release forecast.

● BetaFree · in your browser

Run — free How it works & API

Use it from WebAPIEmailTelegramApp soon

It reports how many whole sprints the backlog requires and the numbered sprint in which work should finish. You can begin the sequence at sprint one or enter the next sprint number from an existing roadmap. The calculation is deterministic, transparent, and useful for planning conversations where a date-like sprint milestone is clearer than a raw points-to-velocity ratio.

Enter a backlog and a realistic expected velocity

Start with the story points that are genuinely left, not the original project estimate. Remove completed work and include newly accepted items if they are part of the commitment being forecast. Then enter the expected velocity in story points per sprint. This value should describe the team and sprint cadence that will perform the work. A recent stable average is often a useful baseline, while a deliberately conservative planning velocity may be better when the roadmap is being communicated outside the team. The calculator does not estimate velocity from historical data and does not assume that every team shares the same scale. It simply uses the two values you provide. If your organization numbers sprints continuously, set the starting sprint to the next planned sprint. For example, when sprint 18 is active and the forecast begins after it, enter 19. If sprint labels are local to this plan, leave the starting value at one. Keep units consistent: backlog points divided by points per sprint produces a sprint count; mixing hours, tickets, or differently calibrated team estimates makes the result misleading even when the arithmetic is correct.

Understand the sprint count and finishing sprint

The calculation divides points left by expected velocity and rounds upward to the next whole sprint. Rounding up matters because a fractional result still occupies a sprint. A 145-point backlog at 32 points per sprint is 4.53125 sprints mathematically, so the plan needs five whole sprints. When the first forecast sprint is 12, those five sprints are 12, 13, 14, 15, and 16; therefore the inclusive finishing sprint is 16. The output also reports the amount of backlog work expected in the finishing sprint. In this example, four full-velocity sprints cover 128 points, leaving 17 points for sprint 16. That remainder is not a promise about exact sprint scope. It is a clear way to show why the last sprint may have spare capacity or room for contingency. When points left is exactly divisible by velocity, the finishing sprint carries a full velocity allocation. When no points remain, the result says zero sprints are needed and does not invent a finishing sprint. The forecast uses no calendar, sprint duration, holidays, or current date; sprint numbering is purely based on the starting number supplied.

Use the forecast as a planning scenario, not a guarantee

Velocity is an expectation, while actual delivery varies because of interruptions, dependencies, estimation changes, staffing, and newly discovered work. Treat the result as a scenario with explicit assumptions rather than a guaranteed commitment. A useful planning practice is to run several cases: a conservative velocity for external commitments, a typical velocity for the working plan, and an optimistic velocity for understanding upside. Compare their finishing sprints and make the range visible to stakeholders. Recalculate when the backlog changes materially or when several completed sprints show that the velocity assumption is no longer credible. The tool intentionally does not add scope growth, risk buffers, or confidence intervals, because silently embedding those choices would make the result harder to audit. Add contingency by reducing the expected velocity or increasing the points-left estimate, and record that choice next to the forecast. The result can support release planning, milestone reviews, and capacity conversations, but it should not be used to pressure a team into matching an outdated number. For automated planning workflows, the API price is $0.002 per request, and the same deterministic calculation can be run free in the browser for individual scenarios.

What you can do with it

Forecast a release sprint

Convert the remaining release backlog and an agreed planning velocity into the sprint number where the scoped work is expected to finish.

Compare velocity scenarios

Run conservative, typical, and optimistic velocities to show how delivery assumptions change the required sprint count and completion milestone.

Refresh a roadmap after scope changes

Recalculate the finishing sprint after completed work, added stories, or a revised team velocity changes the current forecast.

FAQ

How is the number of sprints calculated?

The calculator divides points left by expected velocity and rounds upward, because any partial sprint requires another whole sprint in the plan.

What does finishing sprint mean?

It is the inclusive sprint number where the remaining backlog is forecast to finish. It is based on the starting sprint you enter, which defaults to 1.

What happens when no points are left?

The result reports zero sprints needed and marks the backlog already complete. It omits a finishing sprint because no future sprint is required.

Does this calculator predict calendar dates?

No. It forecasts sprint counts and sprint numbers only. Convert the result to dates using your team's sprint calendar, cadence, breaks, and holidays.

How much does the API request cost?

Each API request costs $0.002. Individual scenarios can also be calculated free in the browser.

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/biz/backlog-completion-sprints

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/biz/backlog-completion-sprints \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"points_left":145,"expected_velocity":32}'

const res = await fetch("https://api.kit.forhosting.com/biz/backlog-completion-sprints", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "points_left": 145,
    "expected_velocity": 32
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/biz/backlog-completion-sprints",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "points_left": 145,
    "expected_velocity": 32
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/biz/backlog-completion-sprints", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"points_left":145,"expected_velocity":32}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"points_left":145,"expected_velocity":32}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/biz/backlog-completion-sprints", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "points_left": 145,
  "expected_velocity": 32
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "biz.backlog_completion_sprints",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Limits

`max_points_left`	1000000000
`max_velocity`	1000000000
`max_starting_sprint`	1000000000

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Read the full KIT documentation →