Sprint Velocity in Scrum: Complete Guide 2026

Q: How does sprint velocity relate to team happiness and sustainability?

Sustainable velocity - where the team works at a pace they can maintain indefinitely - is a core Agile principle. When velocity is used as a pressure tool or performance target, teams often push beyond sustainable capacity, leading to burnout, increased defects, and eventual velocity collapse. A team that maintains a moderate but consistent velocity over many sprints delivers more value than one that spikes high and then burns out. Tracking velocity alongside team health indicators (like mood scores in retrospectives) provides a more complete picture of sustainable performance.

Q: Should story points be re-estimated when a sprint has already started?

Story points should generally not be re-estimated during a sprint for the purposes of velocity tracking - only after fully meeting the Definition of Done do points count. However, if a team discovers during a sprint that a story is far more complex than estimated, they may split it into smaller stories and adjust the remaining work accordingly. This is different from re-estimating existing stories to inflate velocity. The key principle is that estimates should reflect genuine complexity, and changes should be transparent and discussed with the Product Owner.

Q: How do you handle velocity when team members work part-time on a Scrum team?

Part-time team membership is common but complicates velocity calculation. One approach is to normalize velocity by tracking 'team-days' available per sprint and calculating points per team-day. Another simpler approach is to treat the part-time member's contribution as a consistent factor in your planning (e.g., if one member is always at 50%, your average velocity already reflects their contribution). Avoid comparing velocities across sprints where part-time availability varied significantly without accounting for that difference.

Q: What happens to velocity when a team adopts continuous delivery?

Teams practicing continuous delivery often find that their velocity calculation changes because work is deployed multiple times per sprint rather than held until sprint end. In these contexts, throughput (count of features deployed) may be more meaningful than story point velocity. Some teams using continuous delivery abandon fixed-sprint velocity in favor of cycle time metrics (how long each item takes from start to done) and flow efficiency measures. Velocity remains useful for capacity planning even in continuous delivery contexts, as long as the team maintains sprint-based ceremonies.

Q: How does velocity factor into the SAFe (Scaled Agile Framework) program increment planning?

In SAFe, individual team velocities roll up into Program Increment (PI) planning. Each team provides their velocity as 'team capacity' to estimate how many features and enablers can be committed to in a PI (typically 5 sprints). Teams express capacity in story points, and feature estimates are sized relative to team velocity. Program-level velocity is the sum of all team velocities, used to forecast PI delivery. Teams new to SAFe should establish velocity data through at least 2-3 PIs before making high-confidence PI commitments.

Q: Can velocity be tracked in weeks instead of sprints?

Yes, particularly if your organization uses variable sprint lengths or a mix of sprint lengths. Tracking velocity per week (story points per week) normalizes across different sprint durations. Simply divide each sprint's velocity by the sprint length in weeks. This is especially useful when comparing across teams with different sprint lengths or when a sprint length changes. For most teams with consistent 2-week sprints, per-sprint tracking is simpler and equally effective.

Q: How should velocity change if the team improves their engineering practices (e.g., adds automated testing)?

Improved engineering practices like test automation, CI/CD, and pair programming often reduce defects and rework, freeing capacity. However, the initial implementation of these practices typically reduces velocity in the short term (sprints 1-4 of adoption) as the team learns and builds the infrastructure. Over time, teams with strong engineering practices achieve more stable velocity with fewer interruptions from production incidents and technical debt. Do not penalize teams for velocity dips during practice adoption - the long-term payoff is sustained delivery speed.

Q: How do you communicate sprint velocity to non-technical stakeholders?

Avoid presenting raw story point numbers to non-technical stakeholders, as they are meaningless without context. Instead, translate velocity into business outcomes: 'Based on our pace, we can complete the payment module in 4 weeks' or 'We have capacity to deliver 3 of the 5 requested features in this quarter.' Use release burndown charts or roadmap visualizations rather than velocity tables. When stakeholders ask for delivery dates, provide ranges (best case / likely case / worst case) derived from velocity data, not single-point commitments.

Q: What is the difference between capacity and velocity in sprint planning?

Capacity is a forward-looking estimate of how much work a team can do in the upcoming sprint, calculated from available team-days and historical productivity. Velocity is a backward-looking measure of how many story points the team actually completed in past sprints. During sprint planning, teams use historical velocity as input to determine capacity (adjusted for holidays, leave, and known sprint disruptions). Capacity is then used to determine how many story points to pull from the Product Backlog. Understanding both concepts prevents over-commitment.

Q: Is velocity relevant for teams doing research, design, or discovery work rather than software delivery?

Story point velocity is designed for incremental delivery work and fits less naturally with pure discovery or design work, where outputs are less predictable. Teams doing research can adapt by using velocity to track 'units of learning' completed per sprint (e.g., user interviews conducted, prototypes validated). Some design teams use 'design sprints' with specific deliverables that can be estimated and tracked. The core principle - empirical, transparent progress tracking - applies to any kind of work, even if the specific metric needs adaptation.

By Abhay Talreja

2/23/2026

My latest article - Empirical Process Control - The Key to Agile Success

Sprint Velocity in Scrum - Complete Guide

Sprint velocity is a metric used in Agile software development, particularly in Scrum, to measure the amount of work a development team can complete in a single sprint.

Velocity is typically measured in story points - relative units of measurement used to estimate the complexity and effort required to complete a user story.

At the end of each sprint, the team calculates their sprint velocity by summing up the story points of all user stories they successfully completed during that sprint.

By understanding and using velocity effectively, teams can improve their planning and deliver better results.

Quick Answer: Sprint Velocity at a Glance

Aspect	Details
What it measures	Story points completed by a team per sprint
How to calculate	Sum of story points for all fully Done user stories in a sprint
When to use it	Sprint planning, release forecasting, retrospective analysis
When NOT to use it	Comparing teams, evaluating individual performance, as a target to maximize
Stabilizes after	3-5 sprints for new teams
Related metric	Throughput (count of items completed, regardless of size)

Table Of Contents-

What is Sprint Velocity in Agile?

Sprint Velocity, often simply referred to as "velocity," represents the quantity of story points completed by a team within a single Sprint.

While some teams might prefer using different measurements, such as hours or completed stories, the fundamental concept remains unchanged - velocity quantifies the amount of work a team accomplishes during a Sprint.

To calculate sprint velocity, two essential variables come into play: the amount of work accomplished by the Agile team and the time it takes to complete that work.

It is crucial to recognize that sprint velocity is a descriptive metric, not a success metric. It serves to gauge your team's capacity rather than aiming to enhance that capacity for its own sake.

⚠️

Velocity is a planning tool, not a performance target. Pressure to "increase velocity" leads to inflated estimates, rushed work, and technical debt - none of which deliver real value.

How to Calculate Sprint Velocity

The measurement of Sprint Velocity is straightforward.

At the conclusion of each Sprint, tally the total story points associated with each completed user story.

This sum constitutes your team's velocity metric for that Sprint.

Example calculation:

If your team estimates and completes three user stories:

Story A (4 points) - fully Done
Story B (2 points) - fully Done
Story C (3 points) - fully Done

Your velocity for that Sprint is 9 story points.

However, any incomplete user stories should not be included in the calculation, even if they are 90% complete. This serves as a reminder to break down tasks into manageable pieces that can be fully completed within a sprint.

Remember: only those PBIs that fulfill the Definition of Done count.

Calculating Average Velocity

To determine your average sprint velocity, sum the story points completed in each of the past 3-5 sprints and divide by the number of sprints.

Example:

Sprint 1: 28 points
Sprint 2: 32 points
Sprint 3: 36 points

Average velocity = (28 + 32 + 36) / 3 = 32 story points per sprint

This average provides a reliable baseline for future sprint planning.

Why Teams Measure Sprint Velocity

Sprint Velocity offers several advantages for Agile teams:

1. Enhanced Sprint Planning

Velocity empowers teams to make more precise Sprint plans by providing insights into how many story points they can realistically accomplish within a Sprint.

It serves as a foundation for productive discussions during Sprint Planning sessions, helping teams set reasonable objectives based on empirical data.

2. Visualizing Progress

Visualizing Sprint Velocity over time, often combined with a Burn Down Chart, provides teams with valuable insights into their progress throughout the Sprint.

Teams can assess whether story points are consistently completed over the duration of the Sprint or if there is a tendency to rush toward the end.

By comparing actual progress to the "ideal burndown" line, teams can gauge whether they are on track or falling behind, allowing for necessary adjustments.

3. Focus During Retrospectives

Sprint Retrospectives are an ideal opportunity to leverage Sprint Velocity. It can serve as a focal point at the beginning of a retrospective, enabling teams to identify potential issues or assess the effectiveness of recent process changes.

For instance, if a team's velocity fluctuates significantly between Sprints, it could signal that user stories are too large, there are recurring blockers, or team composition is unstable.

4. Optimization Opportunities

Improving Sprint Velocity is a goal for many Agile teams. Several strategies can help:

Mastering Backlog Refinement: Thoroughly refined backlogs with detailed information enable team members to start tasks with all necessary information, enhancing their ability to execute efficiently.
Automation: Automating aspects of the work process, such as tests and code generation, can lead to significant improvements in velocity.
Awareness of Team Dynamics: Keeping an eye on changes within the team helps identify improvement opportunities. Whether it is shifting requirements, missing skills, or personal challenges, addressing these factors can positively impact velocity.
Managing External Dependencies: Sometimes, velocity issues lie outside the team. Delays caused by external factors, such as slow customer feedback or complex approval processes, can hinder velocity.
Dedicated Retrospectives: Holding retrospectives focused solely on optimizing velocity can provide valuable insights.

Using Velocity for Release Planning and Forecasting

One of the most powerful applications of sprint velocity is release forecasting.

Step-by-Step Release Forecasting

Count total story points remaining in the Product Backlog for your planned release
Calculate your average velocity over the last 3-5 sprints
Divide remaining points by average velocity to estimate sprints needed
Multiply by sprint length to get calendar time

Example:

Remaining release scope: 160 story points
Average velocity: 32 points per sprint
Estimated sprints needed: 160 / 32 = 5 sprints
Sprint length: 2 weeks
Estimated release date: 10 weeks from now

Always provide a range rather than a single date. Use minimum velocity (worst recent sprint) and maximum velocity (best recent sprint) to give stakeholders a realistic range: "We expect to release between 8 and 13 weeks from now."

Velocity-Based Capacity Planning

During Sprint Planning, use velocity to determine sprint capacity:

If average velocity is 32 points and the upcoming sprint has one day less due to a holiday, adjust the target accordingly (e.g., 32 * 9/10 = ~29 points)
If a team member will be absent for half the sprint, reduce the target proportionally
Account for sprint planning, retrospective, review, and refinement meetings consuming a portion of capacity

Velocity Stabilization: What to Expect Over Time

During the initial Sprints of a team, velocity may fluctuate significantly. This period is characterized by:

Calibration of story point estimates
Longer meetings as the team learns Scrum
Team members becoming acclimated to the codebase and domain
Evolving Definition of Done

Relying on and expecting a stable velocity is advisable only after three to five Sprints when sufficient data becomes available to make meaningful assessments.

Velocity Stability Signals

Stable velocity (good): Velocity varies by less than 20% sprint to sprint. Team has consistent membership and a well-understood Definition of Done.

Unstable velocity (needs attention): Velocity swings by 30%+ sprint to sprint. Common causes include team membership changes, inconsistent estimation, unclear Definition of Done, recurring blockers, or technical debt slowing the team down.

Improving Sprint Velocity

Achieving and maintaining a stable sprint velocity is essential for Agile success. To stabilize and enhance your team's velocity, consider these practices:

Write clear and concise user stories with agreed acceptance criteria before sprint planning
Maintain consistent team membership and size
Use sprint retrospectives to identify and address areas for improvement
Eliminate dependencies that can hinder progress
Develop a robust Definition of Done for tasks
Prioritize quality over speed - rushing creates technical debt that slows future velocity
Allocate sufficient time for thorough testing and code review
Seek additional expertise when needed
Ensure ongoing training to keep team members up to date with new technologies

Limitations of Velocity

While Velocity is a helpful planning tool, it is crucial to recognize its limitations:

Velocity is specific to a team: Comparing the Velocity of different teams is not productive, as each team's context, skills, and experience are unique. A "40-point team" is not necessarily more productive than a "20-point team."
Velocity may vary due to changes in team composition: If a team member leaves or joins the team, velocity will likely change significantly for several sprints while the team re-calibrates.
Velocity is not a measure of value: A high Velocity does not necessarily mean the team is delivering high-value features. The focus should always be on delivering the most valuable PBIs first, not maximizing points.
Velocity can be gamed: If velocity is used as a performance metric, teams will inflate story point estimates to appear more productive without actually delivering more value.
Velocity does not show work quality: High velocity with high technical debt may actually slow the team down in subsequent sprints.

Velocity Anti-Patterns to Avoid

Anti-Pattern 1: Using Velocity as a Target

Problem: Management sets velocity targets ("You must achieve 50 points per sprint").

Why It's Harmful: Teams inflate story point estimates to hit targets without increasing actual output. Velocity numbers go up, but real productivity and value delivery stay the same or decline.

Solution: Use velocity as a planning input, never as a performance goal. Focus on outcomes (features shipped, customer problems solved) rather than velocity numbers.

Anti-Pattern 2: Comparing Velocity Across Teams

Problem: "Team A delivers 60 points per sprint. Team B only delivers 30. Team B needs to improve."

Why It's Harmful: Story point scales are team-specific. A 5-point story in Team A may take the same effort as a 10-point story in Team B. The comparison is meaningless and demoralizing.

Solution: Compare each team's velocity trend over time (is it stable and improving?) rather than comparing absolute numbers across teams.

Anti-Pattern 3: Partial Credit for Incomplete Stories

Problem: Teams give partial velocity credit for stories that are 80% complete at sprint end.

Why It's Harmful: Partial stories create false velocity data, carry hidden risks (that remaining 20% often takes far longer than expected), and undermine the Definition of Done.

Solution: Apply an all-or-nothing rule. If a story does not fully meet the Definition of Done, it contributes zero velocity to that sprint.

Anti-Pattern 4: Velocity Inflation Through Estimate Creep

Problem: Each sprint, the team gradually gives higher story point estimates for similar work, making velocity appear to increase without actual productivity gains.

Why It's Harmful: Release forecasts become inaccurate and stakeholders lose trust in the team's estimates.

Solution: Periodically re-calibrate estimates by reviewing past stories. Compare current 5-point stories to stories that were 5 points six months ago to check for estimate drift.

Anti-Pattern 5: Ignoring Velocity Drops

Problem: When velocity drops significantly, teams say "it's just natural variation" and do not investigate.

Why It's Harmful: Velocity drops often signal real problems: technical debt, team conflict, unclear requirements, or loss of key team members. Ignoring them allows problems to compound.

Solution: Investigate any sprint where velocity drops more than 25% from the recent average. Use the retrospective to surface root causes.

Velocity vs. Throughput: Which Should You Track?

Both velocity and throughput are useful metrics, but they measure different things:

Aspect	Velocity	Throughput
What it counts	Story points completed	Number of items completed
Estimation required	Yes (story points)	No
Best for	Planning sprint capacity, release forecasting	Flow efficiency, cycle time analysis
Team-specific	Yes (scale varies by team)	Yes (but more comparable across teams)
Manipulation risk	Higher (inflate point values)	Lower (count of items is harder to game)
Works with Kanban	Less naturally	Yes, very well

Many mature Agile teams track both: velocity for sprint planning and release forecasting, and throughput for flow analysis and identifying process bottlenecks.

Regulating Your Team's Sprint Velocity

Consistency in sprint velocity is pivotal for effective project management. Here are tips to maintain consistent sprint velocity:

Clarify User Stories: Ensure that user stories are clear and understandable before the sprint commences. A well-defined user story reduces ambiguity and allows team members to focus on the task at hand.
Maintain Consistency: Avoid frequent changes in variables, such as team composition, sprint length, or processes. Keeping these factors stable promotes steady performance.
Establish a Uniform Definition of Done: A clear understanding of what constitutes a "done" user story enhances estimation accuracy. Define done criteria to standardize work assessment.
Host Sprint Retrospectives: Leverage the Agile methodology's iterative nature by conducting sprint retrospectives. These meetings provide a platform to reflect on past sprints and implement improvements.
Track the Trend, Not the Number: Do not fixate on individual sprint velocity numbers. Track the rolling average over 5-10 sprints to see the true trend.

Common Velocity Mistakes

Mistake 1: Starting Release Forecasts Too Early

New teams often start making release commitments based on velocity after just 1-2 sprints. With so little data, the estimates are highly unreliable.

Fix: Wait for at least 5 consecutive sprints with stable team membership before making release commitments based on velocity.

Mistake 2: Not Adjusting for Holidays and Planned Absence

Teams forget to reduce sprint commitment when holidays, training, or planned leave will reduce available capacity.

Fix: During sprint planning, explicitly calculate available team-days and adjust the velocity target proportionally.

Mistake 3: Using Velocity to Evaluate Individual Developers

Managers attempt to assess individual productivity by tracking which developers' stories contributed to velocity.

Fix: Velocity is a team metric. Individual contribution to velocity is not meaningful because Scrum teams collaborate on work - one developer may write code while another reviews it, and both are equally essential.

Mistake 4: Resetting to Zero Every Sprint Planning

Teams ignore all previous velocity data and start fresh each sprint planning session.

Fix: Always reference the last 3-5 sprint velocities during planning. Historical data is the most reliable predictor of future capacity.

Velocity Maturity Model

Stage 1: Awareness (Sprints 1-6)

Characteristics:

Team is learning story points and estimation
Velocity varies significantly sprint to sprint (range of 50%+ is normal)
Story point calibration is ongoing

Focus: Establish a shared understanding of story points and Definition of Done. Do not use velocity for external forecasting yet.

Stage 2: Predictability (Sprints 7-15)

Characteristics:

Velocity begins to stabilize (variation within 20-25%)
Team uses velocity for sprint planning confidently
Average velocity is tracked and reviewed in retrospectives

Focus: Use rolling average velocity for sprint planning. Begin using velocity for internal release forecasting with appropriate ranges.

Stage 3: Optimization (Sprint 16+)

Characteristics:

Velocity is stable and predictable
Team uses velocity for stakeholder-facing release forecasting
Throughput is tracked alongside velocity for flow analysis
Velocity trends are used to measure process improvement impact

Focus: Optimize the value delivered per sprint, not the velocity number itself. Track whether velocity improvements correspond to faster delivery of valuable features.

Industry-Specific Velocity Considerations

SaaS/Cloud Services

Velocity should account for on-call and incident response time
Planned maintenance windows reduce sprint capacity
Feature flagging and gradual rollouts may split stories across sprints - count only when fully enabled

Healthcare Software

Compliance review and sign-off cycles may extend story completion beyond a single sprint
Plan for clinical stakeholder review time in estimation
Regulatory submissions may be tracked on a separate release burndown

Financial Services

Audit trail and compliance testing add significant effort to story estimates
Regulatory change requests may interrupt sprint velocity unpredictably
Use velocity ranges rather than single-point estimates for regulatory-driven releases

E-commerce

Seasonal traffic spikes (Black Friday, holiday) should inform sprint planning
Performance testing under load should be included in story estimates
A/B test setup and analysis may span multiple sprints

Mobile Apps

App store review cycles add unpredictable delays - track separately from velocity
Device compatibility testing across iOS/Android versions adds overhead
Plan for additional time in stories touching core navigation or system APIs

Enterprise/Government

Procurement and approval cycles may block sprint work unpredictably
Change advisory board reviews should be factored into story estimates
Cross-team dependencies require extra buffer in velocity-based forecasts

Conclusion

Sprint Velocity is a valuable instrument in the Agile toolkit, but its effective use requires a nuanced understanding.

By leveraging it as a means to enhance planning, visualize progress, focus retrospectives, and identify optimization opportunities, teams can navigate their Agile journeys more effectively.

Key takeaways:

Calculate velocity as sum of story points for fully Done stories only
Use velocity for sprint planning and release forecasting, never as a performance target
Wait for 3-5 sprints before treating velocity as reliable
Track throughput alongside velocity for a complete picture of flow health
Never compare velocity across teams
Investigate drops of 25%+ promptly - they signal real problems

Agile success ultimately hinges on the team's ability to adapt and align their practices with the overarching goal of delivering value to customers.

Quiz on Sprint Velocity

Your Score: 0/15

Question: What does sprint velocity measure in a Scrum team?

The number of hours worked by the team per sprintThe total story points of user stories fully completed in a sprintThe number of bugs fixed during a sprintThe percentage of the Product Backlog completed