Velocity and release forecasting

01The problem

The Surulere pilot is planned for the end of sprint 8, on 19 June 2026. The commercial director asks the BA a direct question on 22 May: "Will the app be ready?"

The team has finished six sprints. A quick glance at the board suggests yes: most of the original plan is done. But the board also shows a stream of stories added since March: card payments, part-payments, delivery photos, three languages. Nobody has added them up. Answering "will it be ready?" honestly means using the team's actual delivery rate and the actual remaining scope, not hope.

02The concept

Velocity

Velocity is the number of story points a team completes per sprint, counting only items that meet the definition of done. Use the average of recent sprints, and look at the range too: velocity varies from sprint to sprint.

Forecasting a release

Sprints needed = remaining points ÷ average velocity

Give it as a range, using the team's lowest and highest recent velocities, not a single date: "between 2.2 and 3 sprints". Remember that bugs and unplanned work also use capacity even when they carry no points.

The burn-up chart

A burn-up chart has two lines over the sprints:

• Work done (cumulative points completed), which rises with each sprint.
• Total scope (all points in the release), which rises whenever stories are added.

The release is finished where the two lines meet. If scope keeps rising as fast as work is done, the lines never meet. A burn-down chart hides that; a burn-up chart makes it obvious, which is why BAs prefer it for conversations with stakeholders.

Options when the date is at risk

There are only three levers, and the product owner chooses between them with stakeholders:

1. Reduce scope: move lower-value stories out of the release (using WSJF from lesson 6).
2. Move the date: release a sprint later.
3. Change capacity: rarely works quickly (adding people to a late project usually slows it down at first).

"Work harder" is not an option. It produces bugs, as sprints 4 to 6 already showed.

03Example

The kiosk app's MVP, from backlog.csv and sprints.csv:

Two sprints remain before the pilot. At the team's average velocity, they'll complete roughly 39 more points, leaving about 12 points undone. And that's before allowing for bugs. Without the stories added since March, the original MVP would already be nearly finished. The date isn't at risk because the team is slow; it's at risk because scope grew by 30%.

04Walkthrough

1. Calculate velocity for each closed sprint: total points of Done items by sprint. Then the average and the range.
2. Calculate the remaining MVP points (stories not Done).
3. Draw a burn-up chart: cumulative points done by sprint, and total MVP scope by sprint (from the created dates).
4. Forecast the sprints needed as a range.
5. Write a recommendation for the commercial director with options (the task below).

05Practice

06Check your understanding