Forget Velocity: Cycle Time Is the Only Metric a Tiny Team Needs

You can double your team's velocity in a single afternoon without writing a single line of code — just estimate everything at twice the points. The board looks more productive. The burndown chart looks heroic. Nothing actually ships faster. That is the whole problem with velocity in one sentence.

If you run a team of two to ten people, you do not need a metrics dashboard with twelve charts. You need exactly one number that tells you the truth: how long does a task actually take to get from "I started this" to "this is done"? That number is cycle time, and it is the only metric a tiny team needs to take seriously.

---

The metrics zoo, and why most of it is for someone else

Before we throw anything out, let's name the animals. Four terms get mashed together constantly, and the distinctions matter because three of them are measuring activity and only one is measuring delivery.

• Velocity — how many story points a team completes per sprint. An internal, relative unit. Useful only inside one team, over a stable period, for one purpose: forecasting how much fits in the next sprint.
• Burndown — a chart of remaining work versus time inside a fixed sprint window. It answers "are we on track to finish this sprint's commitment?" — a question that only exists if you run sprints at all.
• Lead time — the clock from the moment a request enters your system (a customer files a bug, you add an idea to the backlog) until it ships. This is what your customer feels.
• Cycle time — the clock from the moment work actually starts on a task until it is done. This is what your team controls.

Velocity and burndown are sprint-bound by design. If you have already decided that you don't need sprints and you run continuous flow instead, both metrics evaporate — there is no fixed window to burn down and no sprint boundary to count points against. Lead time and cycle time, by contrast, work in any system, because every task has a start and an end no matter how you organize the work.

For a small team shipping continuously, cycle time is the sweet spot. Lead time includes all the queue time before you even touch the work — valuable for setting customer expectations, but noisy and full of stuff outside your control. Cycle time isolates the part you can actually improve.

---

Why velocity is a vanity metric you can game in an afternoon

Velocity feels rigorous because it produces a tidy number that goes up and to the right. But it is built on a unit you invented — the story point — and any team can quietly re-denominate that unit whenever they like.

Here is how velocity dies in practice on a small team:

• Point inflation. Last quarter a "medium" task was 3 points. This quarter, after a frank conversation about looking productive, a "medium" is 5. Velocity climbs 40 percent. Output is identical.
• It is not comparable. Your 8-point story and my 8-point story have nothing to do with each other. Comparing velocity across two teams is comparing two different currencies with no exchange rate. Yet managers do it constantly.
• It rewards padding. When velocity becomes a target, estimates inflate to hit it. This is just Goodhart's Law — when a measure becomes a target, it stops being a good measure.
• It hides the actual problem. A team can have stable, beautiful velocity while individual tasks rot for two weeks in "In Review." Velocity is an average over a sprint; it smooths away exactly the stuck work you most need to see.

The deeper issue is that velocity is downstream of estimation, and estimation on a small team is mostly theater. Cycle time skips estimation entirely. It does not ask anyone to guess how big something is. It measures, after the fact, how long it actually took. There is no number to negotiate and nothing to inflate.

---

Cycle time, Little's Law, and the math you actually need

Here is the one piece of theory worth memorizing. It is called Little's Law, it comes from queueing theory, and it is one of the most reliable relationships in operations:

Average cycle time = Average work in progress ÷ Average throughput

In plain English: how long your tasks take to finish equals how many things you have in flight divided by how fast you complete them. Read that again, because it has a brutal consequence.

If your throughput is roughly constant — and for a small team it usually is, you only have so many hands — then cycle time is directly proportional to work in progress. Start more things at once, and every single thing takes longer to finish. Not because anyone is slacking. Because the math says so.

This is the entire mathematical justification for WIP limits. Capping the number of tasks in your "In Progress" column is not a productivity ritual — it is the one lever Little's Law hands you. Halve your WIP and, all else equal, you halve your cycle time. Work finishes in half the time, which means feedback arrives twice as fast, which means you catch wrong directions before you have sunk a week into them.

---

How to measure cycle time with almost no tooling

The beautiful thing about cycle time is that you do not need a metrics platform, a data team, or a single integration. You need two timestamps per task: when it started, and when it finished. Any kanban board that records column moves already captures this for free.

A few practical notes that save you from common mistakes:

1. Measure in working days, not calendar hours. Nobody cares that a task sat over a weekend. Elapsed business days is the honest unit and it is good enough.
2. Track percentiles, not the mean. Cycle time distributions are skewed — a few monster tasks drag the average around. The median (50th percentile) tells you the typical case; the 85th percentile is what you can promise with a straight face.
3. Use a sample of recent finished tasks. The last 20 to 30 completed cards is plenty. You are not doing science; you are spotting trends.
4. Decide your columns once and leave them alone. If "started" keeps shifting, your data is garbage. Consistency beats precision here.

In GritShip every card carries its move history, so the start-to-done elapsed time is already sitting there — no plugin, no setup. But this works on a whiteboard with sticky notes and a Sharpie too. The method is the point, not the tool.

---

What good cycle time looks like (and how to read it)

There is no universal "correct" cycle time — it depends on how big your tasks are and what you build. But on a healthy small team where tasks are scoped to a day or two of work, the numbers tend to cluster in a recognizable range. Here is an illustrative picture, not a benchmark to chase:

The single most useful signal is not the average at all — it is the trend. A rising cycle time is the smoke alarm of a small team, and it almost always means one of two things:

• Too much WIP. You started six things and finished none. Little's Law guarantees each one now takes longer. The fix is to stop starting and start finishing.
• Tasks too big. A "task" that is secretly an epic will always have a long cycle time, because it never had a chance of finishing quickly. The fix is to slice it — and to keep subtasks one level deep so the slices stay legible.

Notice that "the work is just genuinely harder" is at the bottom. That is deliberate. Nine times out of ten, when a small team's cycle time climbs, the cause is process — too much in flight or tasks that should have been split — not the inherent difficulty of the work. Cycle time is honest precisely because it does not let you blame the work.

---

A worked example: the week your board lied to you

Let's make this concrete. Say you are a two-person team and here is your week.

Monday morning, you and your co-founder pull five tasks into "In Progress" because they all feel urgent. You each grab one, then keep dipping into the others whenever you hit a wall. By Friday, the burndown looks fine-ish — points are trickling down — and standup sounds productive every morning. "Still on the auth refactor, made progress, almost there."

Now look at the cycle times when those tasks finally close:

The two big tasks — auth refactor and CSV export — ate the week. They were each closer to an epic than a task, and because everything was started at once, they competed for the same two pairs of hands the whole time. Little's Law was quietly taxing every card on the board.

Velocity would have papered over all of this. The sprint might still hit its point total, the burndown might still slope downward, and the retro would conclude "good week." Cycle time refuses to lie. The median was 4 days but the 85th percentile was 10 days, and the aging work in progress view would have screamed on Wednesday that two cards had been "in progress" for three days with no movement.

---

The aging work-in-progress view: the only chart you need

If you build or adopt exactly one chart, make it the aging work in progress view. Forget the burndown, forget the velocity bar chart, forget the cumulative flow diagram for now. Aging WIP is the chart that prevents disasters instead of explaining them after the fact.

It is simple: for every task currently in progress, show how many days it has already been in progress, with your typical cycle time drawn as a reference line. Everything else is descriptive — it tells you what already happened. Aging WIP is predictive. A card that has been in progress for eight days when your 85th percentile is four days is going to blow your cycle time whether or not it has finished yet. You can act on it today.

This is why aging WIP pairs so well with async status updates. Instead of a standup where everyone recites "still working on it," the board itself flags the aging cards, and the only status conversation worth having is about the specific tasks the chart has highlighted. The metric drives the meeting, not the other way around.

---

How to actually adopt this without a process project

You do not need a transformation. You need three habits, and you can start all of them this week without telling anyone you have started a "metrics initiative."

1. Agree on what "started" and "done" mean. One ten-minute conversation. Pick the column moves and write them down.
2. Glance at aging WIP every morning. Replace the ritual recitation of a daily standup with thirty seconds of "which cards are aging?" If a card is older than your typical cycle time, that is today's conversation.
3. Review your cycle time distribution every couple of weeks. Median and 85th percentile over the last 20-30 tasks. If the trend is rising, lower your WIP or split your tasks. That is the whole feedback loop.

That is it. No estimation poker, no points, no sprint ceremonies, no velocity spreadsheet. This is the same philosophy behind running a solo or small-team PM setup without the bloat: keep the one signal that tells the truth and delete everything that just makes you feel busy. If you want the broader argument for why most tools pile on metrics you will never use, the case against tools built for teams of 50 is the same case made about charts.

GritShip records column-move history on every card, so cycle time and aging WIP fall out of the data you are already generating — no setup, every interaction under 200ms. But the honest truth is that the discipline matters more than the tool. A spreadsheet and a daily glance at the board will get you ninety percent of the value.

---

Frequently asked questions

What is the difference between cycle time and lead time?

Lead time is the full clock from when a request enters your system (a bug filed, an idea added to the backlog) until it ships. Cycle time is the narrower clock from when work actually starts on a task until it is done. Lead time is what your customer experiences; cycle time is the part your team directly controls. Small teams usually optimize cycle time because it isolates execution from queue time.

Why is velocity considered a vanity metric?

Velocity counts story points completed per sprint, but story points are a unit you invent, so any team can inflate them and show rising velocity with zero change in actual output. It is also not comparable between teams (each team's points mean something different) and it requires a sprint cadence to even compute. It measures perceived busyness, not delivery speed.

How does Little's Law connect cycle time to work in progress?

Little's Law states that average cycle time equals average work in progress divided by average throughput. For a small team with roughly fixed throughput, this means cycle time is directly proportional to how many tasks are in flight. Start more things at once and every task takes longer to finish. The practical lever is to cap work in progress — lowering WIP lowers cycle time without hiring anyone.

What is a good cycle time for a small team?

There is no universal number, but on a healthy team where tasks are scoped to a day or two, a median cycle time of one to three working days is typical. The more important signal is the trend: rising cycle time almost always means too much work in progress or tasks scoped too large. Track the median and the 85th percentile, not just the average.

How do I measure cycle time without special tools?

You only need two timestamps per task: when it started and when it finished. Any kanban board that logs column moves captures this automatically. Record the elapsed working days for each finished task in a spreadsheet, then track the median and 85th percentile over the last 20 to 30 tasks. No metrics platform or integration is required to begin.

What is aging work in progress and why does it matter most?

Aging work in progress shows, for every unfinished task, how long it has already been in progress, against your typical cycle time as a reference. Unlike velocity or burndown, which describe what already happened, aging WIP is predictive — it flags a task that is about to blow your cycle time before it finishes, so you can intervene the same day. It is the single most actionable chart for a small team.

Velocity will always be the metric that looks best in a slide deck, because it is the metric most easily made to look good. Cycle time is the metric that ships software. Pick two timestamps, watch your aging cards every morning, and split anything that lingers. That is the entire system — and it is honest in a way no points-per-sprint chart ever will be.