Calculate Velocity Using Burndown Chart
Your comprehensive guide and tool to understand and quantify your team’s agile velocity based on burndown chart data.
Agile Velocity Calculator
Enter your initial remaining work and the total work completed during an iteration to calculate velocity. For more precise calculations, especially for multiple sprints, you can input historical data.
Results
Calculation Logic:
1. If ‘Number of Past Iterations’ is 1, Velocity = ‘Work Completed’.
2. If ‘Number of Past Iterations’ > 1, Velocity = Average of ‘Work Completed’ for those iterations.
3. Average Work Completed per Iteration = Total Work Completed / Number of Past Iterations.
4. Remaining Work Percentage = (Initial Remaining Work – Work Completed) / Initial Remaining Work * 100%.
5. Iteration Completion Rate = (Work Completed / Initial Remaining Work) * 100%.
Iteration Data Overview
| Iteration | Initial Remaining Work (SP) | Work Completed (SP) | Actual Velocity (SP) | Remaining % |
|---|
Iteration Velocity Trend
What is Agile Velocity?
Agile velocity is a metric used in Agile software development, particularly within Scrum and Kanban frameworks, to measure the amount of work a team can complete during a single iteration (or sprint). It’s fundamentally about quantifying a team’s capacity and predicting how much work they can take on in future iterations. Velocity is typically measured in abstract units like Story Points, Ideal Days, or sometimes even task counts. It’s crucial to understand that velocity is not a measure of individual performance, nor is it a tool for comparing teams. Instead, it’s an empirical data point that helps a team understand its own pace, identify impediments, and improve its planning and delivery process over time. The effective use of velocity helps teams become more predictable and sustainable.
Who should use it: Primarily, Agile development teams (Scrum Masters, Product Owners, Developers, Testers) use velocity for planning and forecasting. Project managers and stakeholders can also benefit by understanding team capacity for release planning. However, its effectiveness hinges on consistent use by a stable team.
Common misconceptions:
- Velocity is productivity: Velocity measures output (work completed), not necessarily outcome (business value delivered). A high velocity doesn’t automatically mean the team is delivering more valuable features.
- Velocity should increase constantly: While teams should strive for continuous improvement, expecting velocity to climb indefinitely is unrealistic. Stable velocity is often a sign of a healthy, predictable team.
- Comparing velocities between teams: Different teams estimate work differently and may have unique contexts (e.g., skill sets, complexity of work), making direct velocity comparisons meaningless and often counterproductive.
- Velocity is a performance metric for individuals: Velocity is a team metric. Attributing individual performance based on velocity leads to gaming the system and damages team morale.
Agile Velocity Formula and Mathematical Explanation
Calculating agile velocity is rooted in empirical data collected over iterations. While the most common method is averaging, the core components are the initial work estimate and the actual work completed.
Core Velocity Calculation (Single Iteration)
For a single iteration, the velocity is simply the amount of work the team successfully completed.
Formula:
Velocity = Work Completed
Where:
- Velocity: The measure of work a team can deliver in an iteration.
- Work Completed: The sum of effort (e.g., Story Points) for all fully completed and accepted backlog items within the iteration.
Average Velocity Calculation (Multiple Iterations)
To gain a more stable and predictive measure, velocity is often calculated as an average over several previous iterations. This smooths out variations caused by holidays, unforeseen issues, or scope changes.
Formula:
Average Velocity = SUM(Work Completed across N iterations) / N
Where:
- N: The number of previous iterations considered (commonly the last 3 to 5).
Related Calculations for Context:
While not direct velocity calculations, these provide context:
-
Remaining Work Percentage:
Remaining Work % = ((Initial Remaining Work - Work Completed) / Initial Remaining Work) * 100%This helps understand how much of the planned work for an iteration remains.
-
Iteration Completion Rate:
Completion Rate = (Work Completed / Initial Remaining Work) * 100%This measures the effectiveness of the team in completing the work they committed to.
Variables Table
| Variable | Meaning | Unit | Typical Range |
|---|---|---|---|
| Initial Remaining Work | Total estimated effort (e.g., Story Points) at the start of an iteration. | Story Points (SP) or similar effort unit | Depends on team’s scope |
| Work Completed | Total effort of items fully completed and accepted within an iteration. | Story Points (SP) or similar effort unit | ≥ 0 |
| N (Iterations) | Number of past iterations used for averaging velocity. | Count | Typically 3-5, but can be 1 for current |
| Velocity | Team’s average capacity to complete work per iteration. | Story Points (SP) or similar effort unit | ≥ 0 |
| Remaining Work % | Percentage of planned work left unfinished at the end of an iteration. | % | 0% to >100% (if scope increased) |
| Completion Rate | Percentage of committed work successfully finished within an iteration. | % | 0% to 100%+ |
Practical Examples (Real-World Use Cases)
Let’s illustrate how velocity is calculated and interpreted with practical examples.
Example 1: Single Iteration Focus
A development team starts a 2-week sprint. They estimate their sprint backlog at a total of 45 Story Points (SP). By the end of the sprint, they have successfully completed and accepted work totaling 38 SP.
- Input: Initial Remaining Work = 45 SP, Work Completed = 38 SP, Iterations = 1
- Calculation:
- Velocity = Work Completed = 38 SP
- Average Work Completed per Iteration = 38 SP / 1 = 38 SP
- Remaining Work % = ((45 – 38) / 45) * 100% = (7 / 45) * 100% ≈ 15.6%
- Completion Rate = (38 / 45) * 100% ≈ 84.4%
- Result Interpretation: The team’s velocity for this iteration is 38 SP. They completed approximately 84.4% of their committed work, with about 15.6% remaining. This gives them a data point for planning the next sprint.
Example 2: Averaging Velocity Over Three Iterations
A mature team wants to forecast their capacity for the upcoming sprint. They look at the last three sprints:
- Sprint 1: Completed 35 SP
- Sprint 2: Completed 42 SP
- Sprint 3: Completed 40 SP
- For planning purposes, they estimate the upcoming sprint’s backlog at 40 SP.
- Input: Work Completed (last 3 sprints) = [35, 42, 40] SP, Iterations = 3
- Calculation:
- Total Work Completed (last 3 sprints) = 35 + 42 + 40 = 117 SP
- Average Velocity = 117 SP / 3 = 39 SP
- Average Work Completed per Iteration = 39 SP
- (Note: Initial Remaining Work and Remaining/Completion % are specific to a single iteration and not directly averaged like velocity unless historical initial work is tracked precisely).
- Result Interpretation: The team’s average velocity is 39 SP. They can confidently plan to pull approximately 39 SP into their next sprint, knowing this is their historical average capacity. If they commit 40 SP, they might anticipate a slight overrun or completion rate just under 100%, based on historical data.
How to Use This Agile Velocity Calculator
This calculator is designed to be intuitive, helping you quickly understand your team’s velocity and related metrics. Follow these steps:
- Input Initial Remaining Work: Enter the total estimated effort (e.g., Story Points) for the iteration you are analyzing at the very beginning.
- Input Work Completed: Enter the total effort of all backlog items that were fully completed and accepted by the end of that iteration.
- Input Number of Past Iterations: If you want a more stable, predictive velocity, enter the number of previous iterations (e.g., 3 or 5) for which you have reliable ‘Work Completed’ data. For a single iteration’s velocity, enter ‘1’. The calculator will use this to compute the average.
- Click ‘Calculate Velocity’: The calculator will instantly display:
- Calculated Velocity: The primary metric, representing your team’s average capacity.
- Average Work Completed per Iteration: The average amount of work completed across the specified number of iterations.
- Remaining Work Percentage: How much of the initially planned work for the analyzed iteration was not completed.
- Iteration Completion Rate: The percentage of the iteration’s planned work that was successfully finished.
- Interpret the Results: Use the ‘Calculated Velocity’ to inform how much work the team should commit to in the next sprint. A stable velocity suggests predictability. Fluctuations might indicate process issues, external dependencies, or changes in team composition. The completion rate and remaining work percentage offer insights into the accuracy of planning and execution within a specific iteration.
- Use the ‘Reset’ Button: If you want to start over or clear the current inputs, click ‘Reset’. It will restore default values.
- Use the ‘Copy Results’ Button: Easily copy the calculated velocity, intermediate values, and key assumptions (like the number of iterations used) to your clipboard for documentation or reporting.
Decision-Making Guidance: A consistent velocity allows for more reliable long-term planning, like release forecasting. If velocity is too high or too low compared to commitment, investigate the reasons. Use the completion rate to refine estimation accuracy. A velocity that consistently hovers around the committed amount suggests good planning and execution.
Key Factors That Affect Agile Velocity Results
Several factors can influence a team’s velocity, making it a dynamic metric rather than a static one. Understanding these is key to interpreting velocity trends accurately.
-
Team Stability and Composition:
Changes in team members (new joiners, departures, vacation, illness) significantly impact velocity. A stable team develops better synergy, understanding, and estimation consistency, leading to more predictable velocity.
-
Estimation Consistency:
How consistently the team estimates effort (e.g., using Story Points) is critical. If estimation changes (e.g., using finer granularity, changing reference stories), velocity numbers become incomparable. Training and regular backlog refinement sessions help maintain consistency.
-
Definition of Done (DoD):
A robust DoD ensures that work is truly “complete” (tested, documented, integrated). If the DoD is weak, work might be marked as done prematurely, inflating velocity temporarily but leading to technical debt and rework later.
-
External Dependencies and Blockers:
Reliance on other teams, third-party services, or waiting for decisions/approvals can halt progress. Frequent blockers will reduce velocity and indicate systemic issues that need addressing outside the team’s direct control.
-
Scope Creep within an Iteration:
Adding new work to an iteration after it has started usually disrupts the planned flow and can lead to unfinished items. While the completed items contribute to velocity, the disruption might negatively impact future velocity if not managed.
-
Tooling and Environment Stability:
Issues with development environments, build servers, testing tools, or the overall IT infrastructure can cause significant delays. Unreliable tools lead to wasted time and reduced throughput, directly affecting velocity.
-
Complexity and Uncertainty of Work:
Some work items are inherently more complex or uncertain than others. If an iteration includes many high-uncertainty items, the team might complete fewer points than average, even if they worked diligently. This requires careful backlog management.
-
Team Morale and Motivation:
A demotivated or burnt-out team will naturally have lower capacity. Factors like workload, recognition, and work environment play a huge role. High morale often correlates with sustained or improved velocity.
Frequently Asked Questions (FAQ)
What is the ideal velocity for a team?
Should velocity increase every sprint?
How do I handle velocity when team members change?
What if my team’s velocity is very low?
Can I use velocity for performance reviews?
What’s the difference between velocity and throughput?
How should Story Points be estimated?
When should a team recalculate its velocity?