How do I create a velocity chart in agile project management

TL;DR: Most articles on velocity charts define the concept and move on. This one shows IT company owners how to build one sprint by sprint, read what the data actually says about team capacity, and recognize where velocity breaks down as a planning signal — so you stop treating it as a performance scorecard before it damages your team.

What is a velocity chart in agile

A velocity chart is a bar chart that plots the number of story points a scrum team completes across consecutive sprints, giving you a visual record of delivery capacity over time.

Each bar represents one sprint. The height of the bar equals the total story points accepted as "done" by the end of that sprint boundary — not started, not in review, but fully complete. That distinction matters. Partially finished work carries zero weight in the chart.

What the chart measures is story points velocity: how much validated scope a team ships per sprint cycle. Over several sprints, a pattern emerges. Most teams see that pattern stabilize after roughly four to six sprints, once the team has settled into a working rhythm and estimation habits have normalized.

What it does not measure is effort, hours worked, or individual output. Treating a velocity chart scrum teams use as a productivity scorecard is the most common misread — and the one that creates the most friction between engineering and management.

The chart also tells you nothing about whether the right work got done. For that, you pair it with other signals: burndown charts track remaining work within a sprint, while velocity and workload dashboards updated in real time show whether capacity is being allocated where it matters.

The velocity chart is a forecasting tool. That framing changes how you use it.

What a velocity chart actually measures

A velocity chart plots two things: the story points your team committed to completing and the story points they actually finished, measured across each sprint boundary. That's the full input set. Sprint velocity is the completed number, not the committed one, and that distinction matters more than most teams realize.

What the chart shows is a pattern over time. After several sprints, you get a band of completed story points that reflects your team's realistic throughput. That band is what you use for release planning and capacity decisions.

What it cannot show is why the numbers look the way they do. A sprint where the team delivered 32 points looks identical on the chart to one where they delivered 32 points after descoping half the work mid-sprint. The velocity number is the same; the story behind it is completely different. Treating story points velocity as a productivity score misses this entirely, and it's the most common misread teams make.

Two other things the chart doesn't capture: individual contribution and work quality. Agile velocity tracking was designed for forecasting, not performance reviews. Using it for the latter damages the metric itself, because teams start gaming point estimates to hit targets.

For context on what's happening inside those sprints, burndown charts track remaining work within a sprint and give you the day-by-day picture that velocity deliberately omits. The two charts answer different questions and work best read together.

How to create a velocity chart in agile project management

Building a velocity chart takes less than 30 minutes once your sprint data is organized. Here is the process, step by step.

1. Gather your completed story points per sprint: Pull the final accepted story points from each closed sprint, not the planned total. Only count work the team fully completed and the product owner accepted by the last day of the sprint. Partial work carries over and gets counted in the sprint it finishes.

2. Define your sprint boundaries: List each sprint in chronological order with its start and end dates. Consistent sprint length matters here. If your team switched from two-week to three-week sprints mid-project, note that break in the data. Mixing sprint lengths without flagging it will distort your agile velocity tracking.

3. Set up your chart axes: The X-axis is sprints, labeled in order (Sprint 1, Sprint 2, and so on). The Y-axis is completed story points. Keep the Y-axis scale consistent across updates so the visual trend reads accurately over time.

4. Plot one bar per sprint: Each bar height equals the story points completed in that sprint. Use a simple bar chart, not a line chart. A bar chart makes it easier to read individual sprint performance at a glance without implying a smooth trend that may not exist.

5. Add a rolling average line: Once you have three or more sprints, calculate the average completed points across those sprints and draw a horizontal reference line. This is your sprint velocity baseline. Most teams need four to six sprints before this number stabilizes enough to use for planning.

6. Label your outliers: If a sprint shows a sharp drop or spike, add a short annotation: team half-capacity, scope change, holiday week. Without context, stakeholders misread outliers as performance problems.

A velocity chart scrum teams find most useful is one that travels with the sprint review. Reviewing it alongside your agile burndown chart gives you two complementary views: how much the team completed versus how work burned down within a sprint.

How to read and use velocity data for sprint planning

Start with your three most recent completed sprints and calculate the average story points delivered across them. If you have five sprints of data, use all five — more data smooths out the one-off sprint where half the team was at a conference. That average becomes your planning velocity: the number you commit to when filling the next sprint backlog.

A common approach for a 5-to-10 person team is to treat that average as a ceiling, not a target. Pull in story points up to roughly 80-90% of it. That buffer absorbs the estimation variance that every team carries, and it stops you from overpromising to stakeholders in sprint review.

When presenting sprint velocity to stakeholders, frame it as a forecast range, not a fixed number. "Based on the last four sprints, we expect to complete 34 to 42 points" is more honest than "we'll deliver 38." Ranges hold up better when scope shifts mid-sprint.

Pair your velocity chart with burndown charts that track remaining work within a sprint — velocity tells you how much to plan; burndown tells you whether execution is on track. They answer different questions and work best together.

For teams tracking agile team performance metrics across multiple sprints, a dashboard that updates velocity in real time removes the manual recalculation step and surfaces capacity trends before planning meetings start.

One concrete check: if your last sprint delivered 20% fewer points than the three-sprint average, investigate before committing to the same load next sprint. Treat that drop as a signal, not noise.

Limitations of using a velocity chart for project planning

Velocity charts are useful planning tools, but they mislead teams in four specific ways.

Team composition changes invalidate historical data: If two engineers leave and three join mid-project, your average velocity from the last five sprints no longer reflects what this team can deliver. Treat any roster change as a reset point and recalculate from the sprints that follow it.

Scope inflation distorts the numbers: When story point estimates drift upward over time because the team has learned to pad estimates, velocity appears to rise while actual output stays flat. Watch for this pattern by tracking story count alongside points.

Cross-team comparison is a trap: A team averaging 60 points per sprint is not twice as productive as one averaging 30. Each team calibrates its own scale. Using velocity as an agile team performance metric across teams produces misleading conclusions and creates pressure to inflate estimates.

Treating velocity as a target breaks it: Once the number becomes a goal, teams split stories thinner, rush testing, or carry incomplete work into the next sprint. Identifying where sprint work actually stalls matters more than hitting a point total.

Velocity tells you what a stable, consistent team has delivered. It says nothing about quality, team health, or whether the right work got done. For those signals, you need additional metrics, which the next section covers.

Using a velocity chart alongside other agile metrics

A velocity chart answers one question well: how much can this team deliver per sprint? But it can't tell you whether the team is on track within a sprint, or where work is slowing down before it reaches done.

That's where pairing metrics earns its value. Burndown charts track remaining work within a sprint, so when velocity looks healthy but burndowns keep going flat mid-sprint, you have a pacing problem, not a capacity problem. Cycle time adds a third dimension: if story points per sprint hold steady but cycle time creeps up, your team is completing the same volume with more friction, usually a sign of growing technical debt or unclear acceptance criteria.

Used together, these three agile team performance metrics form a short diagnostic loop:

• Velocity tells you what the team delivered across sprints

• Burndown tells you how smoothly work moved within a sprint

• Cycle time tells you where individual items stalled in the workflow

For agile velocity tracking to be actionable, you need all three visible at once. Velocity and workload dashboards updated in real time make that comparison straightforward, without manually pulling data from separate tools after each sprint ends.

How AI-assisted tools are changing velocity tracking in 2026

Manual velocity tracking in 2026 looks increasingly like a liability. Copying story point totals into spreadsheets after each sprint introduces transcription errors, delays the chart by days, and gives you a snapshot instead of a signal.

AI-assisted tools now handle the mechanical work: automated story point rollups, sprint-over-sprint trend lines, and anomaly detection that flags when sprint velocity drops sharply before you notice it yourself. Predictive forecasting takes that further, projecting future sprint velocity based on team capacity, historical patterns, and planned absences rather than forcing you to guess.

Taro's velocity and workload dashboards updated in real time remove the manual update step entirely, and its bottleneck analysis surfaces where sprint work stalls so you can act before velocity erodes. For scrum teams tracking agile velocity across multiple squads, that kind of automatic aggregation matters more than any single velocity chart view.

The chart becomes less of a reporting artifact and more of a live planning input.

Closing

Velocity charts only work when they're treated as forecasting tools, not performance scorecards. The chart itself is straightforward to build — six steps, thirty minutes — but the real value comes from reading it correctly: using the stabilized average to plan realistic sprint loads, pairing it with burndown data to catch execution issues early, and flagging outliers with context so stakeholders don't misinterpret a dip as a team problem.

Teams that track velocity manually in spreadsheets spend cycles on data collection instead of sprint planning — Taro captures story points and plots velocity automatically so the chart is always current without a dedicated owner. Start by pulling your last three to five completed sprints into a simple bar chart this week. What patterns do you see in your team's delivery rhythm?

FAQ