# What Is Sprint Velocity? Everything You Need to Know | LinearB Blog > Measuring and interpreting sprint velocity is an important part of leading sprint teams. Find out what velocity is and how to learn from it. _This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._ [Blog](https://linearb.io/blog) / What Is Sprint Velocity? Everything You Need to Know # What Is Sprint Velocity? Everything You Need to Know ![Photo of Eric Boersma](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/logo-mark-lg?_a=BAVMn6ID0) By [Eric Boersma](https://linearb.io/blog/sprint-velocity#eric-boersma) | January 15, 2021 ![velocity_4f76e10e3c](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/velocity_4f76e10e3c?_a=BAVMn6ID0) Every software team faces a big question: How do we measure success? Sure, your team writes some code. They review some pull requests. They might run some tests. Finally, they ship some software. All of that is great. To the software team dedicated to continuous improvement, that process still leaves questions: Were we successful? Could we have done a better job? How did this software deployment compare to others? One way that [agile software](https://www.atlassian.com/agile/scrum) teams measure their performance to answer some of these questions is by measuring their sprint velocity, which is what I’ll be detailing in this post. ## Table of Contents * [Sprint Velocity: What Is It?](#Sprint-Velocity-What-Is-It) * [Key Things to Know About Sprint Velocity](#Key-Things-to-Know-About-Sprint-Velocity) * [Don’t Abuse the Velocity Metric](#Don't-Abuse-the-Velocity-Metric) * [Conclusion](#Conclusion) ## Sprint Velocity: What Is It? To understand sprint velocity, it’s important to first discuss sprints. Software teams split their development cycles into discrete chunks of time that they call [sprints](https://www.atlassian.com/agile/scrum/sprints). Each sprint has a well-defined list of tasks to accomplish, and the team commits to finishing all of them within the sprint window. That’s usually two weeks, but some [scrum teams](https://linearb.io/blog/what-is-scrum-velocity-the-good-the-bad-and-the-ugly/) adopt sprint windows that are one week, others one month. There’s no specific time window. The key is that each sprint is exactly the same length so that you can compare them. Before the start of a sprint, a team estimates the complexity of each task in their product backlog. The mechanics of that estimation vary from team to team. Many teams use [story points](https://www.mountaingoatsoftware.com/blog/what-are-story-points), which are made-up numbers that represent nothing but one [user story’s](https://linearb.io/blog/story-points-definition-caution-on-estimating/) complexity relative to all the other stories in the backlog. A major advantage of using story points is that you can then leverage a tool like Jira to generate a [sprint burndown chart](https://linearb.io/blog/iteration-burndown-chart/), which succinctly captures a team’s progress during a sprint. Some teams skip abstract story points and directly estimate the number of hours they’ll need to complete a task. Other teams skip numbers completely and adopt a [T-shirt sizing ](https://www.c-sharpcorner.com/article/agile-story-point-estimation-techniques-t-shirt-sizing/)method of estimating complexity. No matter [the work estimation method](https://linearb.io/blog/planning-poker-estimation/), calculating velocity is straightforward: **Sprint velocity is the average number of _story points_ or _hours of development work_ or _T-shirt sizes_ the team completes in the average sprint.** ## Key Things to Know About Sprint Velocity If you’re just beginning to use sprint velocity as a metric for your software teams, there are several things to understand about it. ### Velocity Is Descriptive As a software developer, this is probably the #1 thing I wish more managers understood about sprint velocity. It’s a descriptive metric, not a prescriptive one. To put it a different way: measuring a team’s sprint velocity is like measuring the average height of your team members. Once you’ve calculated it, that average height is an innate attribute of the team. You wouldn’t come to your software team and tell them, “Our goal is for every person on this team to be 6’3″ tall.” That would be an absurd way to try to manage them. Sprint velocity is a similar measurement. It will tell you about how tall the team was at a given moment, and allow you to compare between sprints completed by the same team.By understanding how fast you went in previous sprints, you can then make more accurate predictions about how fast you’ll go in future sprints. With LinearB, you can get the insights you need to start planning better right away. For example, our Planning Accuracy metric tells you how much planned versus unplanned work your team completed during previous sprints. And with our [engineering metrics benchmarks](https://linearb.io/engineering-benchmarks/), we’ll also tell you how well you’re performing compared to other teams. A high amount of unplanned work suggests that your team is having to fix bugs or pay off technical debt in order to implement new features. Whatever the cause, LinearB makes it easy to investigate. ### Sprint Velocity Is Variable I recognize that this seems to contradict the idea that sprint velocity is an innate attribute of the team, but hear me out. The members of each sprint team are people. People have better and worse days, and better and worse weeks. They get sick, and they go on vacations (which you should encourage as a leader). To return to the height metaphor: not everyone stands as tall as they can all the time. Sometimes, a person needs to crawl around on the ground to try to find something they dropped. The key takeaway is that looking at one individual sprint’s velocity is often too small a picture. ![The key takeaway is that looking at one individual sprint's velocity is often too small a picture.](https://assets.linearb.io/uploads/velocity-PQ01-1.png) A team’s velocity will vary from sprint to sprint because the issues they’re working on vary. The team’s completion rate for an individual sprint isn’t necessarily a good barometer for how long they’ll take to complete a project. It’s the same as with a car: knowing how fast the car is going in any five-minute period isn’t a good way to figure out how long it’ll take you to drive cross-country. Instead, you want to find the average number of miles traveled per day or week to figure out how far away your goal is. The variance in velocity from sprint to sprint means that it’s always better to examine sprint velocity across multiple sprints (which is easy to do with a [velocity chart](https://www.agile-scrum.be/whats-great-scrum-methodology/velocity-chart/)) so that you’re thinking in averages, not fixating on individual data points. Another reason that relying only upon sprint velocity and a tool like the burndown chart is dangerous is that these only tell you how quickly your team went, but they don’t tell you whether your team was going in the right direction. With LinearB, you can not only see how much work your team completed during particular sprints, but you can see what kind of work they did. Our Investment Profile breaks down work by type so that you can see how much planned versus unplanned work they did or functional versus non-functional stories they completed. ![LinearB Investment Profile](https://assets.linearb.io/uploads/Investment-Profile.png) ### Increasing Velocity Is Difficult and Counterintuitive Every single agile team I’ve ever worked on has had a conversation about increasing velocity at some point. As a developer, this isn’t surprising. We understand that when managers see a metric, their first impulse is to try to optimize it. The natural impulse for the business as a whole is to want more features more quickly, with fewer bugs. So, the manager, responding to the pressures of the business, tells the team that they need to work faster. In my experience, this is usually a self-defeating goal, because the team switches focus from delivering software to figuring out why they aren’t delivering more software. Instead of writing and reviewing code, the team sits in meetings discussing why they’re not getting more work done. [![Oprah Winfrey Meeting GIF by MOODMAN Find & Share on GIPHY](https://media3.giphy.com/media/QXPdeQwJYXv6wKXy2G/giphy.gif)](https://giphy.com/gifs/moodman-meeting-oprah-you-get-a-QXPdeQwJYXv6wKXy2G) Counterintuitively, the best way to increase sprint velocity is often to spend less time thinking about it. Instead, spend more time focusing on writing quality software and ensuring the team encounters the fewest roadblocks possible. To return to our cross-country road trip analogy: spending time talking about how far you need to go isn’t productive while you’re stuck in traffic. Often, it’s going to do nothing but create stress, which leads to wrong turns, slowing the trip down even more. ### Sprint Velocity Is Arbitrary Most teams can tell you their velocity pretty quickly. For instance, the team I currently work on averages about 44 story points per sprint. That’s a stable velocity: we tend to be within three or four points of that number on either side every sprint, going back eight months. Having an accurate sense of our sprint velocity great improves the [sprint planning](https://linearb.io/blog/modern-sprint-planning-tools/) process. We can more confidently move items from our product backlog to construct our sprint backlog because we have few doubts that we will be able to finish what we commit to. Do you know what it would take to double our sprint velocity? We could do it overnight. All we’d have to do is double our pointing estimate for every story we take on. Instead of completing 44 points per sprint, we’d finish 88\. A team may be able to fool an executive this way but in reality the amount of work a team is completing isn’t changing – and soon enough that’ll be apparent. Just like if we started measuring our road trip in kilometers per hour instead of miles per hour so that it’d look like we were going faster initially, sprint velocity isn’t an absolute truth. Many teams, when pressed to increase velocity, will simply start padding estimates. They start meeting their sprint commitments more consistently and they see a bigger number on a dashboard, but they don’t ship any more software. This is why sprint velocity is a [dangerous metric](https://linearb.io/blog/why-agile-velocity-is-the-most-dangerous-metric-for-software-development-teams/) for a scrum team. ![This is why sprint velocity is a dangerous metric for a sprint team.](https://assets.linearb.io/uploads/velocity-PQ02.png) It’s a good idea to complement velocity with other measures of work completed. I recommend that the Scrum coordinator (formerly known as the Scrum master) or product owner goes over completed user stories during your sprint reviews. This helps the development team understand the user value of what they shipped, which is ultimately the most important thing. ## Don’t Abuse the Velocity Metric Sprint velocity is a useful metric. It gives context to the work done between individual sprints by a single team. But it’s important to remember not to abuse that metric. Don’t use it for things it isn’t made to measure, and don’t trust it as an absolute truth. Ben Matthews, Director of Engineering at Stack Overflow, learned through experience how pursuing higher velocity at the expense of everything else ended up being counterproductive. Remember that your goal isn’t to juice a metric. Your goal is to ship the best software you can, as consistently as you can. That’s why it’s helpful to leverage other metrics, like [software development cycle time](https://linearb.io/blog/cycle-time/), to ensure that you’re actually improving. LinearB makes it easy to use a suite of metrics to comprehensively and thoroughly measure your team’s productivity. [![Stop measuring teams by velocity only. There are 12 alternative metrics more suitable to measuring team productivity. Measure metrics with LinearB that improve both speed and quality instead, like cycle time, mean time to restore, and deployment frequency.](https://assets.linearb.io/uploads/AgileVelocity-1024x497.png)](https://linearb.io/get-started/) ## Conclusion Sprint velocity is a useful metric because it makes it easy to understand a key dimension of a development team: How much work are they getting done? But its succinctness also means that it doesn’t give you a full picture. It’s like trying to evaluate a person’s health by their temperature alone. A high temperature doesn’t tell you why someone is ill; you need more data. LinearB was built to provide the information that engineering leaders need to better manage their teams, deliver on their promises, and ship more features faster. To learn about how LinearB can help you to raise your team’s sprint velocity, and in prove in so many more ways, [reach out to set up a demo today](https://linearb.io/get-started/). Want to improve your engineering processes at every level? [Get started with a LinearB free-forever account today!](https://linearb.io/get-started/) ## Improve developer productivity with LinearB Find us on [](https://www.linkedin.com/company/linearb) [](https://devinterrupted.substack.com/) ## Your next read [![Cover image for AI ROI comes from measuring engineering outcomes on day one](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_AI_ROI_comes_from_measuring_engineering_software_security_2400x1256_2c5eae0862?_a=BAVMn6ID0)](https://linearb.io/blog/kraken-nik-sudan-measure-ai-roi-engineering-outcomes) Eng. Metrics [AI ROI comes from measuring engineering outcomes on day one](https://linearb.io/blog/kraken-nik-sudan-measure-ai-roi-engineering-outcomes) Kraken Engineering Operations Lead Nik Sudan details how to establish day-one data infrastructure to accurately measure AI ROI. Discover why raw token adoption... [![Cover image for AI is rebuilding software delivery from SDLC to ADLC](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_AI_rebuilding_software_delivery_2400x1256_3fd5887e75?_a=BAVMn6ID0)](https://linearb.io/blog/sdlc-to-adlc-agentic-software-delivery-transformation) Eng. Metrics [AI is rebuilding software delivery from SDLC to ADLC](https://linearb.io/blog/sdlc-to-adlc-agentic-software-delivery-transformation) Discover how engineering organizations are transitioning from the traditional SDLC to an Agentic Development Lifecycle (ADLC). Learn why rising token costs... [![Cover image for 8 million pull requests reveal where engineering productivity breaks down](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_8_million_pull_requests_2400x1256_03724bfbb2?_a=BAVMn6ID0)](https://linearb.io/blog/8-million-prs-engineering-productivity) Eng. Metrics [8 million pull requests reveal where engineering productivity breaks down](https://linearb.io/blog/8-million-prs-engineering-productivity) 8.1M pull requests reveal the gap between AI adoption and engineering impact, and why code review is the bottleneck blocking real productivity gains. ## Structured data _Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._ ```json { "@context": "https://schema.org", "@type": "Organization", "name": "LinearB", "url": "https://linearb.io", "logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg", "description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.", "sameAs": [ "https://www.linkedin.com/company/linearb" ], "award": [ { "@type": "Award", "name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms", "dateAwarded": "2026", "awardedBy": { "@type": "Organization", "name": "Gartner®" } }, { "@type": "Award", "name": "Great Place to Work Certification", "dateAwarded": "2025-2027", "awardedBy": { "@type": "Organization", "name": "Great Place to Work" } }, { "@type": "Award", "name": "America's Best Startup Employers 2025", "dateAwarded": "2025", "awardedBy": { "@type": "Organization", "name": "Forbes Magazine" } } ], "hasCertification": [ { "@type": "Certification", "name": "SOC 1 Type 2" }, { "@type": "Certification", "name": "SOC 2 Type 2" }, { "@type": "Certification", "name": "GDPR Compliance certification" }, { "@type": "Certification", "name": "ISO 27001" } ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "What Is Sprint Velocity? Everything You Need to Know", "url": "https://linearb.io/blog/sprint-velocity", "author": { "@type": "Person", "name": "Eric Boersma" }, "datePublished": "2021-01-15T16:36:16.000Z", "dateModified": "2021-01-15T16:36:16.000Z", "image": "https://assets.linearb.io/image/upload/v1720000000/velocity_4f76e10e3c.jpeg", "publisher": { "@type": "Organization", "name": "LinearB", "logo": "https://assets.linearb.io/image/upload/v1777485755/linearb-logo-2026.png" }, "description": "Measuring and interpreting sprint velocity is an important part of leading sprint teams. Find out what velocity is and how to learn from it.\n" } ``` ## More on linearb.io ### Top navigation - [Book a Demo](https://linearb.io/book-a-demo) - [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews) - [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights) - [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact) - [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server) - [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation) - [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization) - [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting) - [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance) - [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support) - [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience) - [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience) - [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys) - [Platform overview](https://linearb.io/platform/overview) - [Register now](https://linearb.io/event/engineering-productivity-gap) - [Customers](https://linearb.io/customers) - [Pricing](https://linearb.io/pricing) - [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb) - [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework) - [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq) - [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security) - [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy) - [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts) - [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources) - [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops) - [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report) - [Blog — Product updates and practical insights](https://linearb.io/blog) - [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io) - [API Docs](https://docs.linearb.io/api-overview) - [Status](https://www.linearbstatus.com/) - [Integrations](https://linearb.io/integrations) - [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026) - [Sign in](https://app.linearb.io/login) - [Enterprise](https://linearb.io/solutions/enterprise) - [Contact](https://linearb.io/contact-us) - [About us](https://linearb.io/about-us) - [Careers](https://linearb.io/careers) - [Service agreement](https://linearb.io/services-agreement) - [Privacy policy](https://linearb.io/privacy-policy) - [DPA](https://linearb.io/data-processing-agreement) - [Security FAQ](https://linearb.io/security-faq) - [Substack](https://devinterrupted.substack.com/) ### Footer _Additional links from the site footer, not repeated from the top navigation above._ - [GitHub](https://github.com/linear-b) - [LinkedIn](https://www.linkedin.com/company/linearb) - [Twitter](https://twitter.com/LinearB_Inc)