TL;DR: Most articles on sprint velocity define the term and move on. This one shows IT team leads how to calculate it correctly, identify the inputs that distort it, and use a rolling average to make sprint planning more predictable — not just to report on what already shipped.
What sprint velocity actually means
Professional 3D dashboard visualization of sprint velocity metrics with upward trending chart and geometric data elements
Sprint velocity is the number of story points your team completes in a single sprint, counted only from work that meets your Definition of Done by the sprint's end. Partially finished items don't count, no matter how close they were.
That distinction matters more than most teams realize. Velocity measures output at the team level, not individual throughput. It tells you how much work a stable, specific group can reliably finish under normal conditions. Using it to evaluate individual engineers is the wrong application and produces the wrong behavior: people stop taking on complex work to protect their numbers.
Velocity in Scrum is also sprint-length dependent. A team running two-week sprints will show a different story points per sprint figure than the same team running three-week sprints, even if their actual pace hasn't changed. If your sprint length affects your velocity baseline, recalibrate before comparing across periods.
One more thing to anchor before the calculation: a single sprint's number is noisy. Holidays, onboarding, production incidents, all of it shifts the figure. That's why the sprint planning process relies on a rolling average, not a single data point. The next section walks through exactly how to build that average.
How sprint velocity is calculated in agile development
To calculate sprint velocity, count only the story points from user stories marked done by the end of the sprint. Partially completed stories count as zero, regardless of how much work went in.
Here is the step-by-step method:
Record completed points after each sprint. At the sprint review, note the total story points accepted by the product owner. For example: Sprint 1 = 34 points, Sprint 2 = 28 points, Sprint 3 = 36 points, Sprint 4 = 32 points.
Calculate the rolling average. Add the four sprint totals and divide by four: (34 + 28 + 36 + 32) ÷ 4 = 32.5 story points per sprint. That number is your agile velocity baseline.
Use that baseline for the next sprint's capacity. If your team averaged 32.5 points over four sprints, plan the next sprint to roughly that volume. Don't inflate it because one sprint hit 36.
Update the average each sprint. Drop the oldest sprint, add the newest, recalculate. A rolling four-sprint window smooths out outliers like a team member being out sick or a sprint cut short by a holiday.
Why four sprints? A single sprint is too noisy to trust. Two is better, but still swings wide. Four two-week sprints gives you two months of signal, which is enough to reflect the team's real throughput without burying recent changes in stale data.
One thing to watch: if your team's story point estimates shift significantly between sprints, your velocity number becomes harder to compare across time. Consistent estimation practices matter as much as the math. Good sprint planning practices keep your point scale stable, which makes your velocity calculation reliable.
This is how to calculate sprint velocity in a way that actually informs planning, rather than just filling a metric dashboard.
What counts as a good sprint velocity for your team size
There is no universal "good" sprint velocity number. A team of three engineers completing 20 points per sprint is not underperforming compared to a team of eight completing 60. Velocity in Scrum is a self-referential metric: it only means something relative to your own historical baseline.
A practical calibration method for teams of 3 to 10 engineers:
Run three to four sprints without changing your story point scale or team composition.
Calculate your rolling average (the previous section covers the exact formula).
Set your expected range at plus or minus 20% of that average. For a team averaging 40 points, a healthy sprint lands between 32 and 48.
Flag anything outside that band for a brief retrospective discussion, not a performance review.
That 20% buffer reflects the typical variance stable teams see across a quarter. Tighter than that and you're chasing noise. Wider and you've lost the signal that makes sprint capacity planning reliable.
One important variable: sprint length affects your velocity baseline directly. A team running two-week sprints will show a different number than the same team on three-week sprints, even if output is identical.
Once your baseline is stable, build velocity review into your sprint planning agenda as a standing five-minute check, not an afterthought.
Factors that affect sprint velocity in Scrum
Five variables explain most of the noise in sprint velocity tracking, and knowing which one is active in a given sprint saves you from drawing the wrong conclusions.
Team composition changes hit velocity hardest. Adding a new engineer typically drops output for two to four sprints while onboarding and knowledge transfer absorb capacity. Losing someone mid-sprint has an immediate effect. Neither shows up as a process failure, but both will distort your rolling average if you don't flag them.
Unplanned work is the second biggest factor. Production incidents, urgent bug fixes, and last-minute stakeholder requests pull engineers off committed stories without adjusting the sprint goal. A sprint that absorbs 15 to 20 percent unplanned work will consistently underperform against its estimate, which skews your velocity in Scrum baseline downward over time.
Inconsistent story point sizing inflates or deflates velocity without changing actual output. If your team sizes a "3" in March differently than a "3" in June, the number becomes meaningless. Regular calibration sessions, especially after team changes, keep the scale honest.
Holidays and reduced capacity are predictable but often ignored during planning. A sprint with two engineers on leave is not a data point worth averaging against full-capacity sprints. Sprint length affects your velocity baseline in the same way: a three-week sprint will naturally produce a higher raw number than a two-week one.
When you build velocity review into your sprint planning agenda, you can annotate outlier sprints before they corrupt your forecast.
How to use sprint velocity to predict project timelines
The math is straightforward. Take the total story points remaining in your backlog, divide by your team's rolling average velocity, and you get an estimated sprint count to completion. If 240 points remain and your team consistently completes 40 points per sprint, you're looking at roughly six sprints out.
The rolling average is the key phrase. A single sprint's output is too noisy to plan around. Most stable teams see velocity variance of 20–30% across a quarter, so a three-to-five sprint rolling average smooths out the outliers you identified in the previous section: the holiday sprint, the sprint where onboarding ate two engineers' bandwidth, the one where scope crept in mid-cycle.
Here's the calculation in practice:
Pull completed story points from your last four sprints: 38, 42, 35, 41.
Calculate the average: (38 + 42 + 35 + 41) / 4 = 39 points.
Count remaining backlog points: 195.
Divide: 195 / 39 = 5 sprints to completion.
That's your baseline forecast. For sprint capacity planning, add a buffer sprint if your backlog has unestimated epics or known dependency risk. For agile velocity to mean anything as a planning tool, your story point sizing needs to stay consistent across the backlog, not just within a sprint.
Sprint length affects your velocity baseline too. A team switching from two-week to three-week sprints will see velocity numbers jump without any real productivity gain, which breaks the forecast model.
Once you have your sprint-count estimate, build velocity review into your sprint planning agenda so the forecast updates every cycle rather than sitting stale in a spreadsheet.
How to improve your team's sprint velocity over time
Consistent story point sizing is the fastest lever most teams ignore. When one engineer calls a task a 3 and another calls the same task an 8, your velocity number becomes noise. Run a calibration session at the start of each quarter where the team sizes three or four reference stories together. That single habit tightens your rolling average and makes your sprint planning process far more predictable.
Mid-sprint scope changes are the second culprit. Every unplanned item added after sprint kickoff displaces committed work and distorts your agile velocity baseline. Set a simple rule: new requests go to the backlog and get sized in the next planning session, not dropped into the current sprint. Teams that hold this boundary typically see velocity variance drop within two or three sprints.
Capping work in progress (WIP) keeps the team finishing stories rather than starting them. A common ceiling is 1.5 open items per developer at any time. Finished stories count toward velocity; half-done ones don't.
Retrospectives are where improvement actually compounds. A 30-minute retro focused on one specific velocity blocker, such as unclear acceptance criteria or late design handoffs, produces more change than a general discussion. Build velocity review into your sprint planning agenda so the team sees the trend before committing to the next sprint, not after.
Note that sprint length affects your velocity baseline directly. Switching from two-week to three-week sprints mid-quarter resets your comparison window and makes sprint velocity tracking unreliable until you accumulate at least three sprints at the new cadence.
Track velocity where your sprints actually live
Spreadsheets break sprint velocity tracking the moment someone forgets to update them after a sprint review. You end up with stale numbers feeding your sprint planning process, and sprint capacity planning decisions made on data that's already two weeks behind.
The fix is keeping story point data, sprint history, and velocity calculations inside the same system where sprints actually run. When your board updates automatically, your velocity trend updates with it. No manual exports, no reconciliation.
Taro handles this by connecting sprint and backlog management directly to velocity tracking. Completed story points roll into your history automatically at sprint close. Your rolling average stays current without anyone maintaining a separate file.
That matters most when you're managing your sprint backlog and velocity in one place across multiple teams, where a single missed update in a spreadsheet can skew the capacity numbers every team plans against.
Closing
Sprint velocity only works as a planning tool when you calculate it consistently and treat it as a team baseline, not an individual metric. The rolling average method—tracking four sprints, updating each cycle, and flagging outliers—turns velocity from a vanity number into actionable capacity data. Your next step: pull your last four sprint totals, calculate the average, and use that figure to plan your next sprint instead of guessing. If you're manually tracking story points across sprints, Taro's sprint and backlog management features do this calculation automatically, so your team spends time acting on velocity insights rather than collecting the data.
FAQ
How is sprint velocity calculated in agile development?
Count only story points from user stories marked done by sprint end. Add four sprint totals and divide by four to get your rolling average. Partially completed stories count as zero.
What is a good sprint velocity for a team of our size?
There's no universal benchmark—velocity is self-referential. Calculate your rolling average, then set your healthy range at plus or minus 20% of that number. Anything outside flags a need for retrospective discussion.
How can we improve our team's sprint velocity?
Stabilize team composition, reduce unplanned work interruptions, keep story point sizing consistent, and account for holidays during planning. Velocity rises when capacity is predictable, not when teams are pushed harder.
What factors can affect sprint velocity in Scrum?
Team changes, unplanned work, inconsistent point sizing, holidays, and sprint length all distort velocity. Annotate outlier sprints during planning so they don't corrupt your forecast.
How do we use sprint velocity to predict future project timelines?
Divide remaining story points by your rolling average velocity to estimate sprint count to completion. Use a three-to-five sprint average, not a single sprint, to smooth out noise.
Get tactical playbooks every Tueday
One email. 5-min read. Tactical reads for B2B operators who actually run the business.
Join 48,000+ B2B operators · Unsubscribe anytime
Ashley Carter is a B2B Sales Strategist & Lead Growth Consultant who has spent over a decade helping sales teams turn cold pipelines into consistent revenue engines. With a background in outbound sales and CRM optimization, she writes about smarter lead capture, follow-up systems, and why most businesses are sitting on more opportunities than they realize