Measuring Sprint Velocity

What is Velocity?

Velocity is the amount of work a team completes in a sprint, usually measured in story points. If a team finishes tickets worth 23 points in a two-week sprint, its velocity for that sprint is 23. Track velocity across several sprints and you get a reliable planning tool: a team with an average velocity of 20-25 points can commit to roughly that much work next sprint, instead of guessing.

Velocity is not a productivity score, and it is dangerous to use it that way. It is a team-specific unit of measurement — a "20" for one squad at Flutterwave means something completely different from a "20" for a squad at Spotify, because point scales are relative to each team's own estimation habits. Comparing velocity across teams, or using it to rank engineers, destroys the metric's usefulness because people start inflating estimates to look more "productive."

---

Burndown Charts

A burndown chart plots remaining work (in story points or hours) against time left in the sprint. The x-axis is days in the sprint; the y-axis is points remaining. An ideal burndown is a straight diagonal line from the total sprint scope down to zero.

• Line above the ideal diagonal — the team is behind pace; either work is harder than estimated or something is blocking progress.
• Line matches or tracks below the diagonal — the team is on pace or ahead.
• Flat line for several days, then a cliff at the end — a warning sign that tickets are being marked "done" all at once near the deadline rather than incrementally, which often hides integration problems until it's too late.

A PM at Moniepoint watching a burndown chart flatten by day 6 of a 10-day sprint would use that signal to check in with the team immediately, rather than waiting for the sprint review to discover the sprint goal will be missed.

---

When to Change Scope Mid-Sprint

Sprints are meant to give the team a stable, protected window to focus — constantly changing scope defeats the purpose. Even so, there are legitimate reasons to adjust:

The rule of thumb: protect the sprint from scope creep, but never protect it at the cost of ignoring a genuine emergency.

---

Using Velocity for Roadmap Planning

Once a team's velocity stabilizes (usually after 3-4 sprints), a PM can use it to forecast delivery dates. If a roadmap initiative is estimated at 80 story points and the team's average velocity is 20 points per sprint, that's roughly 4 sprints — 8 weeks for two-week sprints. This is far more credible than a gut-feel estimate, and it gives PMs a defensible way to tell leadership at a company like Konga or Access Bank why a feature will take the time it takes, backed by the team's own historical data rather than optimism.

Velocity should always be treated as a rough forecasting tool, not a promise. Sprints vary — holidays, sick leave, and unexpected complexity all shift the number. Smart PMs communicate forecasts as ranges ("roughly 7-9 weeks") rather than single dates.