Cycle time

Cycle time is how long a task takes from the moment someone starts it to the moment it's finished. If you move a card into In Progress on Monday morning and into Done on Wednesday afternoon, its cycle time is about two and a half days. Measured across many tasks, cycle time tells you how fast work actually flows through your team — independent of how much work you took on.

Cycle time vs. lead time

These two are often confused. Lead time is measured from when a task is requested (added to the backlog) to when it's done — it includes all the waiting. Cycle time starts the clock only when work begins. Lead time tells a customer "how long until I get this?"; cycle time tells the team "how long does our actual work take?" For improving a team's process, cycle time is the more actionable number.

Why cycle time beats velocity for flow

Velocity counts how much got done per iteration; cycle time measures how long each thing takes. For continuous-flow teams without sprints, cycle time is the better health metric: a rising cycle time means tasks are getting stuck, usually because too much work is in progress at once. Lowering WIP almost always lowers cycle time — the two move together.

How to read it

Don't obsess over the average; watch the spread. A team where most tasks finish in 2 days but a few take 3 weeks has a consistency problem hiding behind a reasonable mean. The long-tail tasks are where the real bottlenecks live — usually review queues, unclear requirements, or external dependencies.

How GritShip handles this

GritShip is built for continuous-flow teams, the exact context where cycle time matters more than sprint velocity. The board's left-to-right card movement makes long-stuck cards visually obvious — a card that's sat in In Progress for two weeks stands out — which is the low-tech version of a cycle-time alert.