How to Measure Team Velocity: A Step-by-Step Guide for Engineering Leaders

Velocity is one of the most talked-about metrics in software development, and one of the most misunderstood. For startup engineering teams, measuring it correctly can mean the difference between confident sprint planning and flying blind into every release cycle. Done wrong, velocity tracking becomes a vanity exercise: numbers that look good in a report but tell you nothing about whether your team is actually accelerating, stalling, or burning out.

This guide cuts through the noise. You'll walk away knowing exactly how to define velocity for your team's context, which data sources to pull from, how to establish a meaningful baseline, and how to interpret velocity trends in a way that drives real decisions, not just dashboard screenshots.

Whether you're a CTO trying to give leadership accurate delivery forecasts, an engineering manager trying to spot slowdowns before they become crises, or a dev lead trying to run healthier sprints, this process applies. We'll cover the full arc: from choosing the right metrics and connecting your tools, to reading the signals that separate a temporary dip from a systemic problem.

By the end, you'll have a repeatable system for tracking velocity that's honest, actionable, and built to scale with your team. No fake benchmarks. No one-size-fits-all story points. Just a clear, step-by-step process grounded in how engineering teams actually work.

Step 1: Define What Velocity Actually Means for Your Team

Before you measure anything, you need to agree on what you're measuring. This sounds obvious, but it's where most teams go wrong. Velocity is not a universal metric that means the same thing across every team, tool, or workflow. It's team-specific, context-dependent, and only meaningful when everyone is working from the same definition.

There are three primary ways to measure velocity, and each fits a different kind of team.

Story-point velocity: The classic agile approach. You estimate work in relative complexity units before the sprint, then count how many points your team completes by the end. This works well when your team has mature, consistent estimation practices. If your point estimates are all over the place from sprint to sprint, this number will be noisy from the start.

Ticket throughput: Count the number of issues or tasks completed per sprint, regardless of size. This is often more honest for teams that don't estimate consistently, or for teams where estimation overhead isn't worth the return. It's simpler, less gameable, and surprisingly useful as a baseline signal.

Cycle time: Measure how long it takes a piece of work to move from "started" to "done." This is the right lens for flow-based teams running Kanban or continuous delivery workflows where sprint boundaries don't apply. It tells you about efficiency, not just output.

You don't have to pick just one forever, but you do need to pick one to start. The goal is a single, agreed-upon unit that you'll track consistently over time.

Next, establish your measurement cadence. Are you tracking velocity per one-week sprint, two-week sprint, or four-week cycle? The cadence shapes everything downstream, so lock it in before you pull any data.

One pitfall to avoid immediately: comparing velocity across teams. A frontend team and a backend team using story points will almost never have comparable numbers, even if both teams are performing well. Velocity is a relative, internal signal. The moment you use it to rank teams against each other, you've broken it. Use it to understand a single team's trajectory over time, nothing more.

The success indicator for this step is simple: you can write a one-sentence definition of velocity that every member of your team agrees on. If you can't do that yet, don't move to step two.

Step 2: Connect Your Data Sources

Once you know what you're measuring, you need to know where the data lives. Velocity data comes from two distinct layers, and you need both to get an honest picture.

Project tracking data: This is your Linear, Jira, or equivalent. It shows you what was planned, what was completed, and when. From this layer, you want to pull completed issues per sprint, story points closed (if you estimate), and any tickets that were added or removed mid-sprint.

Code activity data: This is your GitHub or GitLab. It shows you actual work happening at the code level: pull request merge rate, commit frequency, PR review lag, and code churn. This layer tells you things your project tracker can't, like whether work is actually flowing or just sitting in review.

Here's why both layers matter. Project data alone tells you what got marked "done," but it doesn't tell you how work moved. A ticket can sit in "In Progress" for two weeks with zero commits attached to it. Code data alone tells you there's activity, but without planning context, you can't tell whether that activity maps to committed sprint work or is someone going deep on an unplanned refactor.

Together, these two layers give you a complete picture: what was planned, what was actually worked on, and how efficiently it moved from start to finish.

For the manual approach, you're exporting data from both sources and aggregating in a spreadsheet. This works, but it's time-consuming and prone to gaps, especially if your team is moving fast. A more sustainable approach is using an engineering intelligence platform that ingests both sources automatically. Progress, for example, connects directly to Linear and GitHub, continuously pulling and analyzing activity data so you're not rebuilding the same spreadsheet every sprint.

Regardless of your approach, the output of this step should be a simple table: sprint number, completed tickets or points, and PR merge count for each of the last four to six sprints. That table is your raw material for everything that follows.

The success indicator: you can produce that table from a single source of truth, without having to manually reconcile two separate exports. If you're still copying and pasting between tabs every week, that's a process worth fixing before you go further.

Step 3: Establish Your Baseline

A single sprint's velocity number tells you almost nothing on its own. Velocity is only meaningful as a trend, and a trend requires a baseline. This step is non-negotiable.

The standard recommendation is to use four to six completed sprints of historical data as your starting baseline. This gives you enough data points to see a pattern without going so far back that team composition or workflow changes make the data irrelevant.

Calculating your baseline average is straightforward. Sum the completed story points or tickets across your baseline sprints, then divide by the number of sprints. If your team completed 38, 42, 35, 41, and 44 points over five sprints, your baseline average is 40 points per sprint.

But here's what most teams skip: variance matters just as much as the average. A team averaging 40 points with a sprint-to-sprint range of 37 to 43 is highly predictable. A team averaging 40 points with a range of 20 to 60 is not, even though the average looks identical. High variance means unreliable delivery, which makes planning much harder. Calculate your variance range and document it alongside the average.

Before you lock in your baseline, audit your historical sprints for contaminants. Sprints with major holidays, team members out for extended periods, significant production incidents, or large team changes will skew your numbers. You have two options: exclude those sprints from the baseline calculation, or include them with an annotation explaining the context. Either approach is valid. What's not valid is including a sprint where half your team was at a conference without flagging it, because that will pull your baseline down artificially.

If your team size has changed during the baseline period, consider calculating an adjusted baseline that accounts for capacity. Dividing total completed work by team size each sprint gives you a per-person throughput rate that's more comparable across periods of headcount change.

The success indicator for this step: you have a documented baseline number and a variance range. Not just "our velocity is around 40 points," but "our baseline average is 40 points with a typical sprint range of 35 to 45." That documented range is what you'll use to evaluate whether future sprints are within normal bounds or worth investigating.

Step 4: Track Velocity Trends Over Time

With a baseline in place, you can start doing the actual work of velocity measurement: watching how it moves over time. This is where the shift from snapshot thinking to trend thinking becomes essential.

A single sprint's velocity is almost always misleading. One sprint goes great, the next has an unexpected incident, the next someone takes vacation. If you're reacting to each individual data point, you'll be constantly chasing noise. The solution is a rolling average.

A three-sprint or four-sprint rolling average smooths out the week-to-week fluctuation and gives you a much cleaner signal. Calculate it by averaging the most recent three or four sprints at any given point in time, then updating it each sprint. This is the number you should be tracking on your velocity chart, not the raw per-sprint number.

As you track the rolling average over time, you'll start to see one of three patterns emerge.

Sustained decline: The rolling average trends downward over multiple sprints. This is a systemic signal, not noise. Something is dragging on the team's capacity or efficiency, and it warrants investigation. Common causes include accumulating tech debt, unclear requirements, or team morale issues.

Sudden drop: A sharp, single-sprint dip that doesn't persist into subsequent sprints. This is typically an acute event: an incident, a key team member out sick, a sprint that got derailed by an urgent escalation. Investigate the cause, annotate the chart, and watch whether it recovers.

Gradual acceleration: The rolling average trends upward over several sprints. This is a positive signal, but it should be reviewed alongside team health data before being celebrated uncritically. We'll come back to this in step six.

It's also worth understanding where velocity sits in the leading versus lagging indicator spectrum. Velocity is a lagging indicator: it tells you what already happened. By the time your velocity drops, the underlying problem has usually been present for a while. Leading indicators like work-in-progress count, PR review lag, and blocked ticket count give you earlier warning. Track these alongside velocity so you're not always reading signals in the rearview mirror.

For teams that want this analysis without building it manually, Progress surfaces pre-computed momentum signals that show whether work is accelerating or slowing, updated continuously as new data comes in. That means you're looking at trend analysis without having to rebuild your rolling average spreadsheet every sprint.

The success indicator: you can look at a three-month velocity chart and describe the trend in plain language. Not just "the numbers went up and down," but "we had a steady baseline through July, a dip in early August that looks like the incident week, and we've been recovering since." That kind of narrative is what makes velocity data actionable.

Step 5: Separate Signal from Noise

Even with a rolling average, velocity charts contain noise. Knowing how to separate meaningful signals from routine fluctuation is one of the most practically valuable skills in engineering leadership.

The most common sources of velocity noise are estimation inconsistency, scope creep mid-sprint, unplanned work, and team member absence. None of these are performance problems, but they all affect your numbers. If you treat every dip as a team performance issue, you'll erode trust and make your retrospectives adversarial.

One useful metric to track alongside velocity is your unplanned work ratio: what percentage of completed work in a given sprint was not in the original sprint plan? If your team regularly completes ten tickets but four of them were added after sprint kickoff, that tells you something important about how your planning process is working, and it explains a lot of velocity variance without pointing fingers at anyone.

Annotating your velocity chart with context markers is another high-value practice. Every time something significant happens, add a note directly on the chart: "production incident," "two team members at conference," "major release week," "new hire onboarding." This transforms a confusing chart into an interpretable record. When you look back at a dip three months later, you'll know whether it was noise or something worth revisiting.

The more nuanced skill is distinguishing between a velocity dip caused by external factors versus one caused by internal friction. External factors include incidents, holidays, and capacity changes. These are expected and recoverable. Internal friction includes blocked pull requests sitting in review for days, unclear requirements causing rework, or tech debt slowing down every feature that touches a certain part of the codebase. These require different responses.

Stalled pull request detection is a concrete signal that helps make this distinction. If velocity is down but your PR merge rate is also down and average PR age is climbing, that points to review bottlenecks or blocked work, not capacity issues. If velocity is down but PR activity looks normal, the problem is more likely in planning or scoping. Progress flags stalled PRs as part of its operational signals, which means you can often pinpoint the friction source without manually auditing your GitHub queue.

The common pitfall here is reacting before investigating. A velocity dip triggers a meeting, the meeting generates pressure, and the pressure creates exactly the kind of environment where good work stops happening. The better rule: when velocity drops, spend twenty-four to forty-eight hours looking at the supporting data before drawing any conclusions. In most cases, the cause is identifiable and the appropriate response is much calmer than an emergency retrospective.

The success indicator: when velocity drops, you can identify within twenty-four to forty-eight hours whether it's noise requiring no action, or a signal requiring investigation. That speed of diagnosis is what separates teams that manage well from teams that constantly react.

Step 6: Connect Velocity to Team Health

Here's a scenario worth thinking through. Your team's velocity has been climbing for six weeks. The rolling average is up, sprint commitments are being met, and leadership is happy. Everything looks good on the chart.

But look closer. Your engineers are merging PRs at 9pm. Code churn is climbing. The same few people are picking up work while others are waiting to be assigned. This team is hitting its velocity targets while quietly accumulating pressure that will eventually show up as burnout, attrition, or a quality crisis.

Velocity in isolation is an incomplete signal. It tells you how much work is getting done, but not what that work is costing the people doing it. That's why velocity measurement needs to be paired with team health data.

The health signals worth tracking alongside velocity include PR review lag (are reviews getting done promptly or are they piling up?), after-hours commit patterns (is work increasingly happening outside normal hours?), and work-in-progress overload (are team members juggling too many open tasks simultaneously?). None of these require invasive monitoring. They're all derivable from the same GitHub and Linear data you're already pulling.

Sustained high velocity combined with increasing code churn is a particularly important pattern to watch. High churn means code is being written and rewritten frequently, which can indicate rushed work, unclear requirements, or deployment pressure that's pushing incomplete solutions out the door. That combination, high velocity plus high churn, can look like productivity while actually indicating deployment risk.

Progress reads morale and momentum signals as part of its core analysis, giving technical leaders a read on team health that goes beyond throughput numbers. Are team members proactively picking up work, or waiting to be assigned? Is the team's pace building or flattening? These behavioral signals often surface before problems show up in velocity data.

A practical rule worth adopting: any sustained velocity increase should be reviewed alongside burnout signals before it's celebrated in a leadership meeting. This isn't pessimism. It's the kind of systems thinking that keeps high-performing teams high-performing over the long run.

The success indicator: your velocity review meetings include at least one team health data point alongside the throughput numbers. If you're only talking about points and tickets, you're only seeing half the picture.

Step 7: Turn Velocity Data Into Decisions

All of this work, the definition, the data connections, the baseline, the trend tracking, the noise filtering, the health context, only matters if it drives actual decisions. Velocity data that lives in a dashboard and gets referenced in a weekly standup but never changes how you plan or act is just expensive wallpaper.

Here are three concrete scenarios where velocity data should directly inform decisions.

Sprint capacity planning: Use your rolling average as the primary input for sprint commitment decisions, not gut feel, not what leadership wants to see, and not last sprint's number in isolation. If your four-sprint rolling average is 38 points and your team is being asked to commit to 55, that's a data-backed conversation you can have with confidence. The rolling average is your honest capacity signal.

Roadmap forecasting: Use your velocity trend to project delivery dates with appropriate confidence intervals. If you need to deliver a feature set that represents roughly 200 points of work and your rolling average is 40 points per sprint, you're looking at approximately five sprints, but factor in your variance range. A team with low variance can give tighter estimates. A team with high variance should build buffer into any external commitment.

Investigating versus acting: Use velocity signals to decide when to dig deeper and when to intervene. A single-sprint dip with a clear annotation? Watch and wait. A sustained three-sprint decline with rising PR review lag? That's worth a structured conversation about what's blocking the team.

Communicating velocity to non-engineering stakeholders requires translation. Most executives don't think in story points. Convert your velocity data into delivery confidence language: "Based on our current pace and the work remaining, we have high confidence in hitting the Q4 milestone" or "We're tracking about one sprint behind our original projection, and here's why." Progress generates executive summaries on demand that translate raw velocity and momentum data into plain-language assessments, which means you're not spending your Friday afternoon manually writing the same briefing document every week.

Finally, treat velocity as a conversation starter, not a performance score. The best use of velocity data in a retrospective is to ask better questions: "Our velocity dropped in sprint twelve, what was different about how we planned that sprint?" That kind of inquiry builds team intelligence over time. Using it as a scorecard does the opposite.

The success indicator: your next sprint planning session uses the rolling velocity average as the primary input for commitment decisions. Not the number someone remembers from last sprint. Not what fits on the roadmap slide. The actual, documented rolling average from your data.

Putting It All Together

Measuring team velocity well is not about finding a magic number. It's about building a system that gives you consistent, honest signals over time. The seven steps here give you that system: a clear definition, connected data sources, a documented baseline, trend tracking, noise filtering, health context, and a direct line to decisions.

Start with steps one and two this week. Get your definition locked and your data sources connected. Everything else builds from there. The whole framework is only useful if the foundation is solid, and the foundation is knowing what you're measuring and where the data comes from.

If you want to skip the manual aggregation and get to the insights faster, Progress does the heavy lifting. It ingests your Linear and GitHub data, computes momentum and health signals automatically, and surfaces answers to questions like "is our velocity actually improving or just fluctuating?" without requiring you to build and maintain a spreadsheet. Its MCP server and Claude integration mean you can ask plain-language questions and get answers grounded in real activity data, not vanity metrics.

The goal isn't a prettier dashboard. It's engineering leadership that acts on real signals instead of digging through noise. That's what a well-implemented velocity measurement system makes possible, and it's well within reach for any startup team willing to put in the groundwork.

Learn more about our services