What Velocity Really Means on Your Construction Project

Stop Guessing How Fast Your Team Is Moving — Start Measuring It

Inspired by Mike Cohn's work on velocity at Mountain Goat Software. Translated for the jobsite by Felipe Engineer-Manriquez.

If I asked you right now, "How fast is your project team moving?" — what would you say?

Most superintendents would give me a gut feeling. "We're ahead of schedule." "We're a little behind." "It depends on the trade."

That's not good enough. Not if you want predictability. Not if you want to make and keep promises.

In Scrum, there's a concept called velocity. It's simple: how much work does your team actually complete in a sprint? Not how much they planned. Not how much they promised the owner. How much they finished.

Mike Cohn, one of the sharpest minds in Scrum, wrote about this concept and broke it down into something every team needs to wrestle with. I've taken his ideas and brought them straight to the jobsite — because this isn't a software concept. It's a performance concept. And performance matters whether you're writing code or pouring concrete.

Two Ways to Think About Velocity

Cohn lays out two definitions, and both matter in construction:

Definition 1: How much your team delivers in a sprint.

On a construction project using Scrum, a sprint is typically a one- or two-week cycle. Your sprint backlog — what Lean practitioners know as the Weekly Work Plan — is the list of commitments your team made. Velocity is the count of what actually got done.

If your team committed to 14 tasks and completed 11, your velocity is 11. Period. Not 14. Not "basically 14 because those last three were almost done." Eleven.

Definition 2: Your team's ability to turn plans into real, completed work.

This is the deeper one. Velocity isn't just a number — it reflects your team's capability. Can they take a constraint log, a set of submittals, a coordination issue, and turn those into resolved, completed deliverables? That ability — plan to done — is what velocity measures over time.

If you've spent any time in Last Planner System pull planning sessions, you already know this instinct. PPC% — Percent Plan Complete — is the Lean Construction equivalent. It's been asking the same question for decades: Of the promises you made this week, how many did you keep?

The River Problem

Cohn uses a brilliant analogy that translates perfectly to construction. Imagine you're swimming across a river. You swim 2 kilometers, but the current pushes you 1 kilometer downstream. Did you swim 2 kilometers or 3?

On a jobsite, this looks like a crew that installs 30 light fixtures but has to go back and redo 8 of them because the ceiling grid was out of tolerance. Did they complete 30? Or 22? Or 38 (counting the rework)?

Here's the construction version of Cohn's river:

• Punch list items = the current pushing you downstream
• Rework = swimming against the flow
• Constraint removal = clearing debris out of the river before your team even gets in the water

This is where your team has to get honest. If you're counting rework as completed velocity, you're inflating your numbers. If you're not counting constraint removal — those RFIs you chased down, the submittal reviews you expedited, the coordination conflicts you resolved before they became problems — you might be undervaluing your team.

There's no universal right answer. But there is a universal right action: your team must define what velocity means to them and stick with it.

The 1-Point-Per-Card Approach

Here's what I use with my teams, and it's changed the game: every task card gets exactly 1 point.

No story points. No Fibonacci sequences. No two-hour estimation meetings where three people argue about whether hanging drywall in a corridor is a 3 or a 5.

One card. One point. Always.

Here's how it works:

Break your work into small, roughly equal-sized tasks. Each card on your board should represent about 1 day of effort or less. "Install fire dampers in Building C, Level 3" — that's a card. "Coordinate all MEP systems" — that's not a card, that's a project. Break it down.

Velocity becomes a simple count. If your team completed 12 cards this sprint, your velocity is 12. Next sprint they finish 14. Then 11. Average those over 3–4 sprints and you've got a reliable forecast: this team completes about 12 tasks per sprint.

For context, I use the 1-point-per-task approach daily in my personal Scrum. When I was a project manager, I averaged about 3 to 5 points per day. Today, as a director operating with deeper Lean practices and AI helpers supporting my workflow, I'm well above 20 points per day. Same principle. Same 1-point rule. The difference is flow, clarity, and leverage.

Why this works:

• No estimation debates. You skip the longest, least productive meeting in Scrum. The energy goes into breaking work down properly instead of arguing about relative size.
• Focus on flow. When every card is 1 point, the only question is: Is it done or not? That drives completion behavior, not activity behavior.
• Predictability. After 3–4 sprints, you can tell an owner with confidence: "This team reliably completes 12 commitments per cycle. Here's what we're committing to next."
• Simplicity. New team members — that drywall foreman who's never heard of Scrum — can understand it in 30 seconds. "Each sticky note is one task. We count how many we finish. That's our score."

This approach works best for two kinds of teams: mature teams that already know how to break work into consistent small batches, and teams brand new to Scrum who need the simplest possible on-ramp. One card, one point. No exceptions.

What Counts and What Doesn't

This is where Cohn's most important advice lands: whatever you decide, be consistent.

On my projects, here's the framework:

Your team might draw the line differently. That's fine. A mechanical contractor's velocity board won't look like a concrete contractor's. What matters is that everyone on your team — from the project engineer to the foreman — agrees on the definition and doesn't change it mid-project.

In the Big Room environment, where multiple trades coordinate daily, this consistency becomes critical. When the GC asks each trade lead, "What's your velocity?" — that answer has to mean the same thing week over week, or the data is worthless.

The Cultural Shift

The hardest part of velocity isn't the math. It's the honesty.

In pull planning, we teach teams to move from "we'll try" to "we commit." Velocity holds you to that commitment — not to punish, but to learn.

A team that consistently commits to 15 tasks and completes 10 doesn't have a velocity problem. They have a planning problem. Maybe they're not removing constraints early enough. Maybe their tasks are too big. Maybe they're not accounting for the inevitable: weather delays, material shortages, inspection failures.

Velocity over time tells you the truth about your team's capacity. And the truth — even when it's uncomfortable — is always more useful than optimism.

The Scrum ↔ Construction Translation

Start This Week

Here's your challenge: pick one crew or one trade on your current project. Set up a simple board — physical sticky notes on a wall or a digital board, whatever works. Break next week's work into 1–2 day tasks. One card per task. Track how many get to Done by Friday.

That number is your velocity. Write it down. Do it again next week. And the week after.

By week four, you'll have something most construction teams never get: a real, data-driven answer to the question, "How fast are we going?"

That's the power of velocity. Not as a software metric. As a construction metric. As a team metric.

And if you want to go deeper — come join us in the EBFC community. We're building better construction, one sprint at a time.

Felipe Engineer-Manriquez is a construction industry leader with 30 years of experience bringing Lean and Agile practices to design and construction teams. He is the host of The EBFC Show and founder of the EBFC community.

The velocity concepts in this article were inspired by Mike Cohn's original post, "Know Exactly What Velocity Means to Your Scrum Team" on Mountain Goat Software. Full credit to Mike for the framework — we just brought it to the jobsite.