What Is Velocity in Scrum?
Velocity is a key Scrum metric that measures the amount of work a team can deliver during a sprint. Before explaining how velocity is calculated, let’s discuss how the metric is used.
During Sprint planning, a team’s velocity is used to determine the number of product backlog items to tackle. Based on this, both the amount of work and a delivery date can be estimated. At the end of the sprint, the actual velocity will be used in the calculator for the next one.
Key Takeaways:
- Scrum velocity measures team capacity, not speed. It reflects the average amount of work a Scrum team can complete in a sprint — expressed in story points — helping to guide planning and forecasting.
- The Scrum velocity formula is simple yet powerful. Divide the total number of completed story points by the number of sprints measured to get an average that informs future sprint capacity.
- Velocity fluctuations are normal. Factors like team absences, unclear priorities, or system issues can impact results. Understanding these drivers helps maintain consistency.
- Improving velocity starts with process, not pressure. Refining backlogs, enhancing communication, and adopting better estimation and automation practices all lead to more stable delivery.
- Smarter tools make smarter sprints. Platforms like Wrike, with real-time dashboards, backlog tracking, and reporting features help teams analyze trends and continuously improve their Scrum velocity.
How to calculate velocity in Scrum
Scrum velocity measures the amount of work a team completes during a sprint, expressed in story points. It helps teams forecast how much work they can take on in future sprints.
Scrum velocity formula:
Velocity = Total story points completed / number of sprints
Example:
If a team completes 25, 28, and 30 story points in three sprints, their average Scrum velocity is: (25 + 28 + 30) ÷ 3 = 27.6 story points per sprint.
This benchmark helps teams plan future sprints more accurately and set realistic goals for upcoming iterations.
Tip: Teams can use Wrike’s sprint boards and reporting widgets to automatically calculate completed story points, making velocity measurement consistent across sprints.
Steps for calculating velocity in Scrum
First, each user story must be assigned a number of story points. This is an abstract measure of the effort needed to implement any given user story. Estimation improves as a project progresses and as teams are able to provide feedback on the difficulty of what they’re working on.
Next, the velocity of the first sprint is calculated by getting the total story points for all completed user stories:
Sprint 1 Scrum velocity calculation
This will be the same again for the following two sprints:
Sprint 2 Scrum velocity calculation
Sprint 3 Scrum velocity calculation
Three sprints give the Scrum master enough data to calculate sprint velocity, which is calculated by taking the average story points of completed user stories for the last three sprints:
Scrum velocity trend across sprints
If a Scrum development team recognizes that they can handle 12 story points on average, estimation during sprint planning becomes easier.
Velocity charts allow teams to quickly understand discrepancies between committed and delivered work.
In short, to calculate Scrum velocity, you should:
- Track the total number of story points completed in each sprint.
- Add those totals together.
- Divide the result by the number of sprints measured (typically three to five).
- Use that average to estimate future sprint capacity.
Scrum velocity naturally fluctuates from sprint to sprint — and that’s normal. Changes in team size, scope, or external factors can affect how much work gets completed. The key isn’t to eliminate fluctuations altogether, but to understand what’s causing them so teams can plan more accurately and maintain steady delivery over time.
Many factors can influence velocity, including:
- Lack of engagement by team members and stakeholders
- System outages or technical issues
- Team member absences
Lack of engagement by team members or stakeholders
When team members or stakeholders lose engagement, productivity and collaboration suffer. Missing input from product owners or inconsistent participation in sprint ceremonies can create unclear priorities and wasted effort. Maintaining open communication, ensuring every team member understands sprint goals, and promoting ownership of outcomes all help stabilize velocity.
How Wrike can help: Centralized communication in Wrike, including shared boards, @mentions, and live task updates, helps keep stakeholders engaged and aligned, reducing confusion that can negatively impact velocity.
System outages or technical Issues
Unexpected downtime from tools, servers, or development environments can stall progress mid-sprint. Even brief outages can ripple through a team’s schedule, leading to fewer completed story points.
Proactive monitoring and automated alerts can help minimize downtime and prevent velocity dips caused by technical disruptions.
Team member absences
Vacations, illnesses, or unplanned absences reduce capacity and directly affect sprint output. Even losing one key contributor for part of a sprint can have a measurable impact on velocity. Teams can mitigate this by tracking capacity during sprint planning, redistributing tasks early, and maintaining clear documentation so others can step in when needed.
How Wrike can help: With Wrike’s task histories and contextual documentation, teams can redistribute work quickly and keep velocity stable when someone is unavailable.
How to improve Scrum velocityTo improve Scrum velocity, teams must first understand the factors that affect it. Scrum velocity is influenced by team experience, sprint scope stability, backlog clarity, and communication flow.
Here are the key factors to consider when improving Scrum velocity:
- Reduce sprint interruptions
- Refine the product backlog regularly
- Improve communication and collaboration
- Focus on estimation accuracy
- Enhance technical practices
- Conduct effective sprint retrospectives
- Use velocity as a planning guide, not a performance metric
Reduce sprint interruptions
Unplanned work is one of the biggest threats to consistent velocity. Last-minute requests, shifting priorities, or production issues can derail even the best sprint plans.
How to fix it: Create a buffer in sprint planning for high-priority interruptions and use clear prioritization rules to protect focus. Wrike’s real-time task tracking tools help teams visualize capacity so interruptions are managed, not chaotic.
Refine the product backlog regularly
A well-prepared backlog makes estimating and completing work easier. Poorly defined stories or outdated priorities often cause slowdowns during sprint execution.
How to fix it: Wrike’s custom fields, prioritization tags, and backlog-refinement views help product owners keep stories clear, current, and easy to estimate.
Improve communication and collaboration
Velocity suffers when teams work in silos or blockers go unreported. Agile thrives on transparency, so effective communication directly improves throughput.
How to fix it: Hold concise daily stand-ups, encourage open discussion of obstacles, and centralize updates in one workspace. Wrike’s shared boards and comments can help consolidate updates and reduce delays caused by scattered communication.
Focus on estimation accuracy
Inconsistent estimation leads to unstable velocity trends. Overestimating makes sprints look slow, while underestimating can burn out the team.
How to fix it: Historical story point data stored in Wrike helps teams compare estimated vs. actual complexity and refine their velocity over time.
Enhance technical practices
Technical debt, outdated tooling, and manual processes can quietly drag down sprint performance. Investing in automation and clean-code practices pays off through higher, more predictable velocity.
How to fix it: Automate testing, code reviews, and deployment steps where possible. Use workflow automation features to streamline repetitive tasks, so developers can focus on delivery.
Conduct effective sprint retrospectives
Scrum velocity improves when teams learn from every sprint. Retrospectives help identify what’s working and what needs to change before the next iteration.
How to fix it: Track recurring themes across retrospectives and assign clear action items to address them. Use shared templates or reports to document insights and monitor progress toward improvement goals.
Use velocity as a planning guide, not a performance metric
Velocity is best used for forecasting and capacity planning, not as a measure of individual performance. Treating it as a scoreboard creates pressure and leads to inflated estimates.
How to fix it: Emphasize that velocity reflects team predictability, not speed. Use velocity trends to balance workload and ensure sustainable delivery. Dashboards that visualize long-term velocity trends help reinforce this team-oriented view.
From tracking to improving: Strengthen Scrum velocity with WrikeScrum velocity isn’t about speed; it’s about consistency, collaboration, and continuous improvement. By understanding what drives fluctuations, applying clear estimation practices, and refining team processes, Scrum teams can achieve more predictable and efficient delivery.
With a platform like Wrike, teams can take that improvement even further. Real-time dashboards, shared backlogs, and automated reporting make it easy to visualize velocity trends, adjust workloads, and keep every sprint on track. When everyone works from a single source of truth, maintaining steady velocity becomes less about managing uncertainty and more about delivering lasting results.
Sprint velocity measures how much work the team completes in a sprint, expressed in story points. A burndown chart, on the other hand, visualizes the remaining work as the sprint progresses. Velocity is a metric, while burndown charts are a visualization tool used to track that metric over time.
You can’t accurately calculate Scrum velocity before completing at least one sprint. However, teams can make an initial estimate by referencing past projects or similar teams. After the first few sprints, refine the estimate using actual story-point averages to set realistic baselines.
Fluctuations in Scrum velocity often point to changes in team composition, task complexity, or sprint interruptions. Tracking these variations over multiple sprints helps teams identify patterns and address root causes — for example, improving backlog refinement or reducing external dependencies.
There’s no universal “good” Scrum velocity. The goal is consistency, not speed. A stable velocity, one that remains steady over several sprints, indicates that the team’s estimation, process, and scope management are working effectively.
