Jo Blythe – Project Velocity Analogy Explained Simply

When a client sets a target of twenty houses in a year, the speed of work becomes immediately tangible. No complex formulas are needed, just a clear distance and a clear time. That intuitive sense of pace is at the heart of the project velocity analogy that borrows from physics but ends up somewhere quite different.

The same logic applies to a long drive. Knowing the miles and the hours lets anyone calculate the speed in between. In project work, the analogy holds, but the terms shift. Distance becomes finished output, time remains time, and the ratio is what teams call throughput or, under certain conditions, velocity.

Understanding the distinction matters for anyone managing construction, software, or any effort where completed work is counted over weeks or months. The physics framework offers a starting point, not a final answer.

How Does the Physics Speed Analogy Map to Project Work?

Key insights from the analogy

• Average speed in physics is purely a ratio of distance to time, with no direction or quality component.
• Throughput in project management counts the number of finished items per time interval, directly comparable to speed.
• Agile velocity, measured in story points, is an estimate‑based planning metric, not a measure of physical movement.
• Construction output is usually tracked in units, milestones, or quantities, making throughput a more natural metric than velocity.
• Academic work on construction project pace treats speed as a measurable concept analogous to motion but distinct from physics velocity.
• Velocity is a planning tool, not a productivity measure; it helps forecasting but does not assess quality or value.
• Throughput and velocity are not interchangeable – one counts items, the other counts estimated effort.

What Distinguishes Throughput from Velocity?

The two terms are often used interchangeably, but they measure fundamentally different things. Throughput counts the number of finished work items per unit of time, regardless of how big or complex each item was. Velocity, in Agile contexts, sums the story points (an estimate of relative effort) that a team completes in a sprint. This distinction appears consistently across Scrum.org and other Agile sources.

Throughput: a count of completed items

Throughput is straightforward. If a construction team finishes five foundations in a week, the throughput is five per week. It requires no estimation system. The same metric works for software teams that deliver features, bug fixes, or tasks. Because throughput is easy to measure and communicate, it is often preferred for forecasting delivery dates using cumulative flow diagrams.

Velocity: an estimate‑based planning metric

Velocity normalises work by assigning story points to each job. A team might average 30 story points per sprint and use that number to predict how much work they can commit to in the next sprint. Agile sources emphasise that velocity is not a productivity measure and does not reflect quality. It is a planning tool only.

Why the difference matters for construction

Construction projects rarely use story points. Output is typically physical: square meters of flooring, kilometres of road, or number of units installed. This makes throughput or pace a more natural fit. The paper “Need for Speed: Framework for Measuring Construction Project Pace” explicitly explores how to measure project pace over time, acknowledging that a domain‑specific metric is needed rather than a direct physics translation.

Why Is Construction Pace a Separate Concept?

Applying the physics analogy directly can lead to confusion. In physics, velocity includes direction and is a vector quantity. In project work, direction is usually known (the project plan), and the focus is on magnitude – how much work per unit time. That is closer to speed or throughput.

The need for a domain‑specific framework

Academic literature, including the “Need for Speed” paper, argues that construction projects require a specific measure of pace. Unlike software sprints, construction tasks often have dependencies, weather constraints, and material supply chains that affect speed. A simple ratio of output to elapsed time may not capture the complexity, but it provides a baseline.

What the analogy offers and what it misses

The closest well‑supported analogy is: distance/time = speed in physics, while completed work/time = throughput in project management. Velocity in Agile is a planning metric based on estimated work, not a true physical vector. The analogy helps communicate the concept of pace, but it does not account for quality, risk, or resource efficiency.

What Does the Research Say About Measuring Project Pace?

The available research frames project pace as a measurable concept analogous to motion. The “Need for Speed” paper aims to measure construction project pace over time using milestones and output quantities. Agile sources from scrum.org and others provide clear definitions of throughput and velocity, but most are software‑focused. The translation to construction is still developing.

How Has the Understanding of Project Velocity Evolved?

1. Ancient roots: The physics concepts of speed and velocity were formalised by Galileo and Newton, establishing distance/time as a fundamental relationship.
2. Early project management (1950s–1970s): Construction and engineering projects tracked progress with Gantt charts and earned value, measuring cost and schedule performance, not speed per se.
3. Agile software development (2000s): Scrum popularised velocity as a story‑point‑based metric for sprint planning, separating it from pure output counts.
4. Flow metrics movement (2010s): Kanban and DevOps introduced throughput, cycle time, and lead time as more granular measures of delivery speed.
5. Construction research (2020s): The “Need for Speed” paper and related work propose project pace as a distinct performance concept, borrowing from physics but recognising domain differences.

What Is Established and What Remains Unclear?

Why Does This Analogy Matter for Real Projects?

Understanding the analogy helps teams and stakeholders speak a common language. When a client asks “How fast are we going?”, the project manager can point to a tangible number: houses per month, features per sprint, or milestones per quarter. That clarity reduces misunderstandings and supports better planning.

The analogy also prevents misuse of metrics. Because velocity in Agile is not a direct measure of speed, using it to compare different teams or to evaluate individual performance leads to false conclusions. By grounding the conversation in throughput or pace, the focus stays on delivery, not on gaming the numbers.

For those interested in the careers of broadcasters who have covered similar topics, see Dermot Murnaghan – A Look at the Veteran Broadcaster’s Career and Gabby Logan – From Gymnast to BBC Sports Presenter and OBE for related profiles in media.

Which Academic and Industry Sources Support This Analogy?

The physics foundation comes from Lumen Learning on time, velocity, and speed and from Physics.info on velocity. Project management definitions are available from Scrum.org comparing velocity and throughput, from The Burndown on flow metrics, and from Plane on throughput formula. Agile velocity is explained by LibreTexts on Agile delivery metrics and the Agile Alliance glossary on velocity. Construction‑specific research is published in a paper available through Academia on measuring construction project pace. Additional context on project velocity and throughput comes from Tempo on project velocity and from C2 Wiki on project velocity. The distinction between throughput and velocity is also covered on weblogs.asp.net.

What Is the Best Way to Explain Project Velocity?

The cleanest explanation: work completed is to time as speed/throughput is to distance/time in physics, while velocity in Agile is a planning metric based on estimated work, not a true physical vector. For construction, use throughput (output per unit time) and avoid confusing it with physics velocity. The analogy helps intuitive understanding, but the metric must be chosen for the context.

Frequently Asked Questions