Team Velocity – My Go-To Method for Understanding Where the Team’s Time Really Goes (and a template)
When I started managing product teams, I kept hearing about velocity.
"Track your velocity."
"Improve your team's velocity."
"Velocity tells you if you're on track."
But no one told me what it actually meant — or how to use it.
Over the years, I learned that team velocity is less about speed, and more about visibility.
It’s about seeing how much work your team can realistically handle — and where their time is going.
Let me break down what I’ve learned, what worked (and didn’t), and share a simple template I now use.
What is team velocity?
At its core, team velocity is a measure of how much work a team completes in a given period — usually a sprint or a month.
It’s not just a number for reports. It’s a way to answer key questions:
How much can we commit to next sprint?
Are we improving or slowing down?
Is something draining our capacity?
Velocity helps you make realistic plans, not just ambitious ones.
Why bother tracking velocity?
Because assumptions lie.
You might think your team is spending 80% of their time on new features — but in reality, maintenance and unexpected tasks are eating half the sprint.
Without velocity, planning becomes guesswork.
With velocity, you get:
Predictability in delivery
Early warning signs when things drift
A better way to say "no" (or "not yet") to stakeholders
How do you calculate velocity?
This is where it gets messy.
There are two popular ways:
1. Story points-based velocity
Add up the story points completed in a sprint.
Average them over time to see your team's typical capacity.
Pros:
Works well with Agile teams using points already.
Helps normalize across tasks of different sizes.
Cons:
Story points are subjective.
They require consistency, or they lose meaning.
2. Days-based velocity (my preference)
Look at the actual number of working days per person.
Factor in their focus (% time really spent on product work).
Split it between new features and maintenance.
Story points vs. days: my take
I've used both. But here’s why I lean toward days-based velocity:
It's grounded in reality.
It highlights when people are dragged into meetings or firefighting.
It’s easier to explain to non-technical stakeholders.
Story points are great — if your team uses them consistently.
But when I need a fast, practical view of what’s going on? I look at days.
My simple velocity tracking template
Here’s what I track for each team member:
Working days in the period
% Focus — are they really at 100%, or more like 70%?
% New features vs. Maintenance
Velocity — how many days are effectively contributing to the product?
Split — how much of that is on building new vs. maintaining old?
It gives me a quick view like this:
Examples: How I use velocity in real planning
Example 1: Deciding if we can take on a new initiative
I once had a stakeholder ask if we could start a new feature mid-quarter.
Thanks to our velocity tracking, I could show that 45% of the team's time was spent on maintenance, and we were already at 90% capacity.
We didn’t kill the idea — we delayed it. But with real data, not gut feeling.
Example 2: Spotting burnout risk early
In another case, one team’s velocity dipped sharply.
Instead of blaming performance, we checked the focus %.
Turns out, a key dev was stuck in cross-team meetings 50% of the time.
We fixed the process, not the person.
Example 3: Proving we need more resources
When pushing for extra hires, I used our velocity trends to show that growth was stalling because maintenance kept increasing.
It wasn’t a vague “we’re too busy.”
It was: “We spend 55% of our time just keeping things running.”
Final thoughts
Velocity isn’t just a metric. It’s a conversation starter.
Track it just enough to spot patterns, but don’t obsess over it. The goal isn’t to make the team faster — it’s to make better decisions with the capacity you do have.
And if you want a simple template to get started, just reach out — happy to share.
Template for measuring team velocity
You can copy it here.