What is engineering velocity? Metrics and examples

An engineering team completes most of its sprint work on schedule, yet the release keeps slipping. Code waits for review, testing reveals unexpected issues, and deployment moves to the following week. The sprint board shows steady progress, but the software takes longer to reach users.

Engineering velocity helps teams understand the pace and consistency of software delivery, from completing development work to releasing changes. This guide explains how to measure engineering velocity, which metrics matter, how to interpret practical examples, and what teams can do to improve delivery performance.

What is engineering velocity?

Engineering velocity measures the pace at which a software engineering team completes development work and delivers working software. It helps teams understand how efficiently work moves through planning, implementation, testing, and release, providing insight into delivery speed, consistency, and potential bottlenecks.

The term is commonly used in two related contexts:

• Sprint velocity: Measures the amount of estimated work completed during a sprint, typically expressed in story points. Teams use it to assess their capacity and plan future iterations.
• Engineering delivery velocity: Describes the broader pace of software delivery, considering metrics such as throughput, cycle time, change lead time, and deployment frequency.

Unlike sprint velocity, broader engineering velocity has no universally accepted formula. Teams select metrics based on their development practices, delivery process, and the questions they need to answer.

Engineering velocity is also closely related to developer velocity, although both terms can encompass different aspects of development performance depending on how an organization defines them. Developer productivity is broader still, considering factors such as work quality, collaboration, problem-solving, and the value produced.

Consider a team that completes six development tasks by Wednesday, but the associated changes reach production the following Tuesday. Its sprint progress may appear healthy, while review delays, testing requirements, or release scheduling extend the actual delivery timeline.

Examining both completion and delivery provides a more useful picture of how engineering work progresses.

Why is engineering velocity important for software development teams?

Engineering velocity gives managers and technical leads a clearer basis for understanding delivery capacity, planning releases, and improving development workflows. Its value comes from identifying patterns in how work progresses and using those patterns to make more informed decisions.

Here are six reasons engineering teams measure velocity.

1. Improves delivery predictability

Historical engineering velocity helps teams understand how consistently they complete and release work. Reviewing several iterations reveals the range of delivery outcomes a team can reasonably expect.

For example, an engineering manager can use previous sprint results alongside delivery timelines to evaluate whether a planned release date is achievable or whether the scope needs adjustment.

2. Supports better sprint and capacity planning

Engineering team velocity provides a reference for matching planned work with available capacity. Teams can examine previous completion rates, account for upcoming absences or maintenance responsibilities, and make more realistic sprint commitments.

This is especially useful when balancing feature development with bug fixes, infrastructure improvements, and other engineering responsibilities that compete for the same capacity.

3. Identifies development bottlenecks

Delivery delays can occur even when developers finish implementation on time. Code reviews may accumulate, tests may require repeated execution, or work may remain blocked by another team.

Tracking how long work spends in different stages helps engineering managers locate these delays and determine where improvements would have the greatest effect.

4. Enables faster feedback cycles

Shorter delivery timelines allow product teams to observe how released changes perform and incorporate feedback into subsequent development decisions.

For products that depend on frequent experimentation, faster feedback can help teams evaluate assumptions sooner and make informed adjustments to the product roadmap.

5. Improves cross-functional alignment

Product managers often plan around feature readiness, while engineering managers account for technical dependencies, testing, and deployment requirements.

Shared visibility into delivery progress helps both functions discuss timelines using the same underlying information. It also makes trade-offs clearer when stakeholders request additional scope or changes in priority.

6. Supports continuous engineering improvement

Tracking velocity over time helps teams evaluate whether changes to their development practices are producing meaningful improvements.

For instance, a team introducing automated regression testing can compare delivery timelines, testing delays, and production failures before and after implementation. These measurements provide a basis for deciding whether the change is effective.

What are the key metrics used to measure engineering velocity?

Engineering velocity metrics cover different stages of software development. Some describe how much planned work teams complete, others measure how quickly changes move through development and deployment, and several help assess delivery reliability.

Understanding these categories is essential because a team can perform well against one metric while experiencing problems elsewhere.

Sprint planning and workflow metrics

These metrics help engineering teams measure work completion, monitor development flow, and identify delays within their day-to-day workflows.

1. Sprint velocity

Sprint velocity measures the amount of estimated work a team completes during a sprint. It is commonly expressed in story points, although some teams use completed work item counts.

A team completing 28 story points in a two-week sprint has a sprint velocity of 28 points for that iteration.

The metric is most useful for planning future work within the same team, provided the estimation approach and sprint duration remain reasonably consistent.

2. Throughput

Throughput measures the number of work items completed within a defined period, such as a week or sprint.

For example, a team completing 16 development tasks in one week has a throughput of 16 tasks per week.

Throughput provides visibility into completion rates without requiring story-point estimates. However, differences in task complexity mean that completed work item counts should be interpreted alongside work size and delivery context.

3. Cycle time

Cycle time measures the elapsed time between actively starting a work item and completing it.

If development begins on Monday and the work item satisfies its definition of done on Thursday, its cycle time is approximately three days.

Teams typically include time spent waiting for review or testing after work has started. This makes cycle time useful for identifying delays within the active development workflow.

4. Work item lead time

Work item lead time measures the total elapsed time between an agreed starting point in the workflow, such as request submission or backlog commitment, and the item's completion.

For example, a feature request may spend five days waiting for prioritization and another four days moving through development and testing. With request submission as the starting point, its lead time is nine days.

The starting point should remain consistent across measurements. This metric helps teams understand the time stakeholders or requesters wait for work to be completed.

5. Work in progress (WIP)

Work in progress measures the number of work items that have started but remain unfinished.

A team with 14 active tasks has a WIP count of 14, regardless of how many tasks it completed during the previous sprint.

High WIP can indicate that work is accumulating across development stages, particularly when completion rates remain unchanged. Monitoring WIP alongside cycle time helps teams understand how concurrent work affects delivery flow.

Software delivery throughput metrics

Software delivery metrics extend measurement beyond work item completion to examine how changes reach production.

The DORA software delivery performance framework identifies five metrics grouped into software delivery throughput and instability. Three belong to the throughput category.

1. Change lead time

Change lead time measures the elapsed time from committing a code change to version control until that change is successfully deployed to production.

If code is committed on Tuesday and reaches production on Thursday, the change lead time is approximately two days.

This differs from work item lead time, which may include discovery, prioritization, design, and development before a code commit occurs.

2. Deployment frequency

Deployment frequency measures how frequently an application or service is successfully deployed to production.

A team deploying changes three times per week has a higher deployment frequency than one releasing the same application every two weeks.

This metric helps engineering teams understand their release cadence and identify opportunities to deliver changes in smaller, more frequent increments.

3. Failed deployment recovery time

Failed deployment recovery time measures how long it takes to restore service after a deployment causes a failure requiring immediate intervention.

If a production deployment causes an outage at 11:00 AM and service is restored at 11:45 AM, the recovery time is 45 minutes.

DORA includes this metric in software delivery throughput because recovering from failed changes is part of moving software through the delivery system.

Software delivery quality and stability metrics

Frequent deployments and shorter delivery timelines are useful only when teams can maintain acceptable reliability. DORA's remaining two metrics help evaluate deployment instability.

1. Change fail rate

Change fail rate measures the proportion of deployments that cause a production failure requiring immediate remediation, such as a rollback or hotfix.

For example, if two out of 40 deployments require immediate intervention, the change fail rate is 5%.

Tracking this metric helps teams understand how frequently releases introduce production problems.

2. Deployment rework rate

Deployment rework rate measures the proportion of deployments that are unplanned and performed in response to production incidents or user-facing bugs.

For instance, a team may release an urgent fix after discovering that a previous change broke an important workflow. Such corrective deployments contribute to the rework rate.

The distinction matters: change fail rate measures how frequently deployments cause failures, while deployment rework rate measures how much deployment activity is consumed by unplanned corrective work.

Engineering velocity metrics comparison

Teams can begin with a small set of metrics that addresses their most pressing delivery questions. Sprint velocity and throughput may be sufficient for initial planning discussions, while cycle time and DORA metrics provide additional insight into workflow efficiency and release performance.

How do you calculate engineering velocity?

The engineering velocity formula depends on what the team intends to measure. Scrum teams typically calculate velocity using completed story points per sprint. Teams evaluating broader engineering performance use several measurements rather than combining every delivery indicator into one score.

The following calculations provide a practical starting point.

Sprint velocity formula

Sprint velocity is calculated by adding the story points associated with work items completed during a sprint.

Sprint velocity = Total story points completed during the sprint

Suppose an engineering team completes the following work:

• User authentication improvements: 8 story points
• API validation updates: 5 story points
• Dashboard filtering: 8 story points
• Automated test improvements: 5 story points

The sprint velocity is:

8 + 5 + 8 + 5 = 26 story points

For accurate measurement, teams should apply three rules:

1. Count only work that meets the agreed definition of done by the sprint's end.
2. Apply a consistent approach to story-point estimation.
3. Exclude unfinished work, even when implementation is nearly complete.

The calculation represents completed estimated scope, rather than actual engineering hours or individual effort.

Average engineering team velocity across sprints

A single sprint provides limited information because delivery capacity can vary due to incidents, leave, dependencies, or changing requirements.

Calculating average velocity across multiple sprints provides a more useful planning reference.

Average sprint velocity = Total completed story points across sprints ÷ Number of sprints

Consider an engineering team with the following results:

The average velocity is: (26 + 30 + 25) ÷ 3 = 27 story points per sprint

The team can use 27 story points as an initial planning baseline for upcoming iterations.

However, capacity changes, carryover work, and uncertainty should still influence sprint commitments. The average becomes more useful when interpreted alongside the variation between sprints.

For a deeper explanation of Agile calculations, see What is project velocity? How to measure and improve it.

Measuring engineering velocity without story points

Teams using Kanban or continuous delivery workflows may prefer measuring completed work items instead of estimating story points.

A basic throughput calculation is: Throughput = Number of completed work items ÷ Measurement period

If a team completes 48 work items over four weeks, its average throughput is 12 work items per week.

For meaningful measurement:

• Use consistent workflow definitions for when work is considered complete.
• Separate significantly different work categories when their complexity varies.
• Compare throughput across equivalent measurement periods.
• Track cycle time to understand how long individual items take to finish.

A team may complete more work items after splitting large tasks into smaller ones, even when its underlying delivery capacity has changed little. Reviewing throughput alongside cycle time and work item size helps prevent misleading conclusions.

What are some examples of engineering velocity in practice?

Engineering velocity metrics become more useful when teams examine them together. The following hypothetical scenarios illustrate how engineering managers can interpret delivery patterns and make decisions based on the underlying workflow.

Example 1. Measuring sprint velocity for release planning

An engineering team developing a customer reporting feature works in two-week sprints. The team tracks estimated story points and compares planned scope with completed work.

The team's average completed velocity is 27 story points per sprint.

Suppose approximately 81 story points remain in the release backlog. At the observed average, the remaining work represents roughly three sprints of effort.

The engineering manager can use this estimate as a starting point for release planning, while allowing for dependencies, changes in scope, and variation in sprint outcomes.

What the team learns: Historical velocity provides a useful planning baseline, but the differences between planned and completed work also deserve attention. Repeated overcommitment may indicate that sprint scope needs adjustment or that unplanned engineering responsibilities are consuming capacity.

Example 2. Identifying delivery bottlenecks using cycle time

A platform engineering team consistently completes around 20 development tasks per week. Despite this steady throughput, developers report that work is increasingly delayed during code review.

The team compares two measurement periods.

Throughput remains unchanged, but work is spending substantially longer in the development workflow. The increase in WIP also suggests that more work is accumulating before completion.

The team investigates its review process and discovers that several pull requests frequently wait for the same senior engineers. It decides to distribute review responsibilities more evenly and introduce clearer expectations for review turnaround.

What the team learns: Stable completion rates can conceal worsening workflow efficiency. Cycle time, review waiting time, and WIP help identify where work is accumulating so the team can address the constraint directly.

Example 3. Improving deployment frequency while maintaining software quality

A product engineering team wants to release smaller changes more frequently. Its existing process relies on scheduled releases and extensive manual checks before deployment.

The team introduces automated regression tests, simplifies deployment approval steps, and begins releasing smaller changes as they become ready.

Its illustrative performance comparison looks like this:

The team now deploys more frequently, while changes spend less time waiting to reach production. The lower change fail rate and recovery time also provide encouraging reliability signals.

However, deployment failures can be relatively infrequent, so the team continues monitoring these measures across a longer period before drawing strong conclusions.

What the team learns: Faster delivery is most meaningful when improvements in release cadence are evaluated alongside deployment quality and recovery capability.

These engineering velocity metrics and examples illustrate why interpreting several related measurements gives engineering leaders a more complete understanding of delivery performance than relying on a single number.

What factors affect engineering velocity?

Engineering velocity depends on how effectively work moves through a team's development environment. Requirements, technical architecture, collaboration patterns, and operational responsibilities all influence how much time engineers spend progressing work toward completion.

Seven factors commonly affect delivery speed and predictability.

1. Requirements clarity and backlog readiness

Engineers spend additional time clarifying implementation details when work begins without well-defined requirements or acceptance criteria.

For example, a payment integration task may remain blocked while the team confirms expected error-handling behavior. Repeated clarification during implementation creates waiting periods and makes completion dates harder to predict.

2. Technical debt and codebase complexity

Complex dependencies, duplicated logic, insufficient test coverage, and outdated architecture can increase the effort required to make otherwise straightforward changes.

A team modifying a tightly coupled service may need to update several unrelated components and perform extensive regression testing. As these constraints accumulate, development work becomes more difficult to estimate and complete.

3. Cross-team dependencies and blockers

Many engineering tasks depend on work owned by another team, such as an API change, security approval, infrastructure configuration, or shared component.

Even when developers have sufficient capacity, unresolved dependencies can prevent progress. The resulting delays may extend work item lead time and disrupt planned delivery sequences.

4. Work in progress and context switching

When developers handle too many tasks simultaneously, unfinished work can accumulate across the workflow.

Frequent switching between features, incidents, and reviews also requires engineers to repeatedly rebuild context. This can increase completion time, particularly for work that demands sustained technical concentration.

5. Code review and testing workflows

Review and testing stages often involve waiting for available reviewers, test environments, or validation results.

Large pull requests may require more review effort, while unstable automated tests can trigger repeated investigation and reruns. These delays can extend cycle time even when the implementation itself is complete.

6. Development tools and CI/CD reliability

Build performance, development environment setup, test automation, and deployment infrastructure influence how quickly teams can validate and release changes.

For example, a consistently slow build pipeline extends the feedback loop for every change passing through it. Intermittent pipeline failures can create additional investigation and rework.

7. Unplanned work and team capacity

Production incidents, customer escalations, urgent fixes, and operational responsibilities compete with planned development work.

When an engineering team spends substantial time responding to incidents, its sprint velocity may decline despite engineers remaining fully occupied. Changes in staffing, onboarding needs, and specialist availability can also affect the team's ability to complete work consistently.

These factors often interact. Technical debt may increase testing effort, while excessive WIP can amplify code review delays. Understanding how these constraints combine helps teams prioritize improvements more effectively.

How can engineering teams improve velocity?

Improving engineering velocity requires identifying the activities and delays that consume delivery capacity, then making targeted changes to the development process. The most useful improvements reduce unnecessary waiting, rework, and coordination overhead while preserving software quality.

The following seven strategies provide a practical approach.

1. Refine requirements and break work into smaller deliverables

Before implementation, clarify the expected behavior, acceptance criteria, technical dependencies, and boundaries of each work item.

Break larger features into independently testable deliverables wherever practical. For example, an extensive reporting feature could be divided into data retrieval, filtering, visualization, and export functionality.

Smaller, well-defined work items are easier to review, estimate, and move through development. Teams can assess the impact by monitoring carryover work, cycle time, and the frequency of blocked tasks.

2. Limit work in progress and reduce context switching

Establish reasonable limits on how many work items can be active simultaneously, particularly in stages where tasks regularly accumulate.

Teams can also reserve focused development periods and clarify how urgent requests should interrupt planned work.

A useful starting point is reviewing the number of unfinished items at each workflow stage and prioritizing completion of existing work before accepting additional tasks.

Monitor WIP and cycle time to evaluate whether these changes improve delivery flow.

3. Identify and resolve delivery bottlenecks

Examine where work spends the most time waiting rather than assuming that implementation is always the slowest stage.

For instance, if changes move through development quickly but remain in testing for several days, the team should investigate test environment availability, validation requirements, or review capacity.

Record the time work spends in different workflow states, identify recurring delays, and address the most significant constraint first.

4. Streamline code reviews and testing

Establish clear review ownership and expectations for responding to pull requests. Encourage smaller changes that reviewers can understand without extensive context reconstruction.

Automated unit and integration tests can reduce repetitive validation effort, while dependable test environments make failures easier to investigate.

Review turnaround, test execution time, and defect trends can help determine whether these improvements are effective.

5. Automate development and deployment workflows

Identify repetitive tasks that consume engineering time without requiring substantial human judgment.

Common candidates include build execution, automated testing, environment provisioning, code quality checks, and repeatable deployment steps.

Teams can begin with the tasks responsible for the greatest delays and gradually expand automation after validating its reliability.

Change lead time, deployment frequency, and pipeline failure rates provide useful evidence of whether automation improves delivery performance.

6. Allocate capacity for technical debt and unplanned work

Include maintenance, infrastructure improvements, bug fixes, and operational responsibilities in capacity planning.

Engineering teams with frequent production incidents may need to adjust feature commitments or reserve dedicated capacity for reliability work.

Reviewing historical incident volume and maintenance demand helps managers build more realistic plans instead of treating every unexpected request as an exception.

7. Review engineering metrics and improve continuously

Establish a regular review cadence for the metrics most relevant to the team's current challenges.

During these reviews, engineering managers and technical leads can examine:

• Changes in throughput and cycle time.
• Work items that remained blocked or carried over.
• Delivery stages with increasing waiting times.
• Deployment reliability and recovery trends.
• Whether recent process changes produced measurable improvements.

Select one or two improvement priorities, agree on the expected results, and review subsequent performance before introducing additional changes.

This creates a manageable improvement process in which engineering metrics support concrete decisions rather than becoming an additional reporting burden.

What are the common mistakes when measuring engineering velocity?

Engineering velocity can become misleading when teams interpret metrics without considering estimation practices, work complexity, and delivery conditions.

Five measurement mistakes deserve particular attention.

1. Using velocity to evaluate individual developer performance

Sprint velocity, throughput, and delivery timelines reflect team workflows involving multiple contributors.

For instance, a developer resolving a difficult architectural issue may complete fewer work items while removing a major constraint for the rest of the team.

Ranking developers using ticket counts or story points can undervalue this contribution and encourage employees to prioritize easily measurable activity.

Better approach: Use velocity for team-level planning and process improvement. Evaluate individual contributions using broader evidence of technical impact, collaboration, judgment, and work quality.

2. Comparing story points across different teams

Story points reflect estimates within a team's own planning system. Different teams may assign different estimates to similar work because their experience, complexity, and estimation conventions differ.

A team completing 40 story points is therefore not necessarily delivering more than another team completing 25.

Better approach: Compare each team's velocity with its historical baseline and focus cross-team discussions on delivery outcomes, dependencies, and shared constraints.

3. Prioritizing output while ignoring software quality

A team might increase its completed work item count by shortening testing or rushing changes through review.

Initially, throughput appears stronger. Over subsequent releases, production incidents and corrective work may consume the capacity gained.

Better approach: Evaluate delivery speed alongside measures such as change fail rate, deployment rework rate, and failed deployment recovery time.

4. Treating ticket counts or code activity as complete productivity measures

Pull requests, commits, lines of code, and completed tickets capture visible engineering activity, but their totals depend heavily on work type and task boundaries.

Removing unnecessary code, simplifying architecture, or fixing a critical defect may create substantial value without generating high activity counts.

Better approach: Interpret activity metrics in the context of completed outcomes, development complexity, delivery performance, and product priorities.

5. Setting arbitrary velocity targets

Targets based on continuous increases in story points or completed tickets can distort team behavior.

Developers may split work into unnecessarily small items, increase estimates, or prioritize tasks that improve reported numbers without addressing important delivery constraints.

Better approach: Establish realistic baselines, review normal variation, and set improvement objectives around observable workflow problems, such as reducing review waiting time or improving deployment reliability.

How can Plane help engineering teams track work and delivery progress?

Measuring engineering velocity begins with visibility into planned work, active tasks, dependencies, and completed deliverables. Teams need a shared view of execution to understand what is progressing, what remains blocked, and how delivery expectations are changing.

Plane brings these elements together in a project management workspace built to support engineering planning and execution.

1. Plan sprints and track progress with Cycles

Plane's Cycles help engineering teams organize work into time-bound iterations and monitor progress against planned scope.

Teams can:

• Assign work items to active or upcoming Cycles.
• Review completed and unfinished work during an iteration.
• Monitor cycle progress and identify potential delivery risks.
• Use burn-down and build-up charts to evaluate progress based on work item counts or estimate points.

Cycle progress charts are available on Pro and higher plans. Historical Cycle results can inform future sprint planning and capacity discussions.

2. Track work items, ownership, and dependencies

Plane's work item management capabilities allow teams to organize development tasks, bugs, technical improvements, and other engineering responsibilities.

Each work item can carry information such as its state, priority, assignees, estimate, and related work.

Teams can also define dependencies, including blocking relationships, to identify work that depends on other deliverables.

This helps engineering managers understand the execution constraints affecting planned work.

3. Visualize engineering work metrics with Dashboards

Plane's Dashboards allow teams to create visualizations using work item data from one or more projects.

Engineering managers can configure views of:

• Completed and pending work items.
• Work item counts and estimate points.
• Work distribution across projects, assignees, or states.
• Completion trends and progress over time.

Dashboards are available on Pro and higher plans, while additional widget models, including the Cycle progress bar, require Business.

These work-management metrics can complement specialized engineering telemetry from Git, CI/CD, and observability systems. Deployment frequency, change fail rate, and other DORA measurements require suitable technical delivery data.

4. Give engineering and product teams shared execution visibility

Plane provides a common workspace for reviewing active development work, priorities, dependencies, and progress.

Engineering managers can use this information to explain delivery constraints, while product managers can assess how changes in scope or priority affect upcoming work.

A shared execution view helps teams hold more informed conversations about delivery commitments and the trade-offs required to meet them.

Want better visibility into your engineering team's work and delivery progress? Talk to sales to explore how Plane can support engineering planning, coordination, and execution.

Final thoughts

Engineering velocity gives software teams a practical way to understand how consistently work progresses from development to delivery. Combining sprint planning metrics, workflow measurements, and software delivery indicators helps teams identify constraints that individual metrics may overlook.

Start with a clear measurement baseline, focus on the delays affecting delivery, and review improvements over time. Sustainable engineering performance comes from creating workflows that support predictable progress, dependable releases, and effective collaboration.

Frequently asked questions

1. What is a good engineering velocity?

A good engineering velocity is one that supports predictable delivery while maintaining software quality. There is no universal benchmark because team size, work complexity, estimation methods, and development processes vary. Teams should compare performance against their own historical results and evaluate delivery consistency alongside reliability.

2. What is the difference between engineering velocity and sprint velocity?

Sprint velocity measures the amount of estimated work completed during a sprint, typically in story points. Engineering velocity can describe a broader view of software delivery performance, including throughput, cycle time, change lead time, and deployment frequency. Sprint velocity is one useful component of that broader assessment.

3. Is engineering velocity the same as developer productivity?

Engineering velocity focuses on the pace and consistency of completing and delivering software. Developer productivity encompasses additional dimensions, including technical effectiveness, collaboration, problem-solving, quality, and the value created. A team may deliver changes quickly while still experiencing productivity challenges related to rework or inefficient development practices.

4. Can engineering velocity be measured without story points?

Yes. Engineering teams can measure velocity using throughput, cycle time, work item lead time, and software delivery metrics without assigning story points. This approach is particularly useful for teams using Kanban or continuous delivery workflows. Consistent measurement boundaries and historical comparisons remain important for interpreting performance.

5. How often should engineering teams measure velocity?

Measurement frequency depends on the metric and development process. Scrum teams typically review sprint velocity at the end of each iteration. Throughput, cycle time, and work in progress can be monitored continuously, while broader delivery trends can be assessed weekly or monthly. The review cadence should support meaningful decisions without creating unnecessary reporting overhead.