What it measures

Sprint velocity measures the volume of estimated work a team completes per sprint. Teams sum the story points (or counted tickets) of items that met the definition of done by the end of the sprint, then track that total across sprints to get a running average.

It is a capacity and forecasting signal. A team averaging 40 points over its last few sprints uses that figure to decide how much to commit to next, and to project a rough completion date for a backlog. Velocity is relative to a single team and its own estimation scale: it is meaningful within that team over time, and close to meaningless when compared across teams.

How to measure it

Sprint velocity comes from your planning tool, not your git history. At sprint close, sum the estimates of every work item that reached done, and record that number against the sprint. The simplest practical formula is the rolling average of the last three to five sprints, which smooths out the noise of any single sprint.

If you want to ground velocity in delivery rather than ceremony, pair the planning-tool total with what actually shipped. Cross-reference closed tickets against the commits, pull requests, and deployments that landed in the same window. A sprint that burned down its points but produced few merged PRs or no deploy tells you the points moved without the work shipping.

Decide up front how to handle carryover and partial work. Counting partially done items inflates velocity and corrupts the forecast, so most teams count only fully completed items and let unfinished work roll into the next sprint at its full estimate.

What it does not tell you

Sprint velocity tells you how many points a team closed. It does not tell you whether those points were worth closing. A team can post a steady 45 points every sprint while shipping work that no customer asked for, that advances no active initiative, or that quietly adds technical debt the next sprint will pay for. The number measures motion through the board, not progress toward anything that matters.

It is also trivially gameable and easy to misread. Estimates are made by the same team being measured, so velocity inflates the moment points are used as a target. Comparing velocity across teams is meaningless because each team's scale is its own. And because the metric stops at the definition of done, it is silent on rework, on whether shipped work held up in production, and on which strategic bet the sprint actually served.

This is the gap Execution Intelligence is built to close. Velocity reports speed and volume. It cannot read what is being built or why. Reading direction means connecting the work that closed to the initiative it belongs to, the people who did it, and the cost it carried, so a steady velocity that is drifting away from strategy becomes visible instead of reassuring.

How InteliG uses it

InteliG does not ask your team to instrument anything or maintain a points spreadsheet. Cognis reads real git and deployment history directly, so the volume and cadence of completed work are derived from commits, pull requests, and deploys that actually landed rather than from tickets a team marked done. That removes the estimation game from the signal.

More to the point, InteliG connects that throughput to the initiative the work belongs to, the contributors who did it, and the cost it consumed. So instead of a velocity number floating on its own, you see whether a sprint's output advanced an active initiative, who carried it, and what it cost to produce, which is the difference between knowing a team is busy and knowing it is building the right thing.

Related terms

Story Points — The relative effort estimates that velocity sums per sprint.
Cycle Time — How long a single work item takes from start to done, a flow measure velocity hides.
Execution Intelligence — Reading what an engineering org is actually building and why, not just how fast.