What Is Cycle Time in Development? A Practical Guide for Startup Engineering Teams

Cycle time in development is the elapsed time from when work actually starts on a task to when it is delivered. It is one of the clearest indicators of how quickly your team turns ideas into shipped software, but only if you define "start" and "delivered" the same way every time. Most of the confusion around the metric comes from inconsistent boundaries, not from the math.

This guide defines cycle time precisely, separates it from lead time and PR cycle time, shows where the hours usually go, and walks through measuring it from Linear and GitHub data. It also covers how to read the number without distorting it, and what to change when it climbs.

Cycle Time Defined: Start, Finish, and What Sits Between

Cycle time is the time between first active work on an item and its completion. The start is typically the moment a Linear issue moves to In Progress, or the first commit on its branch. The finish might be the pull request merging, the code deploying to production, or the ticket reaching Done. There is no universal standard. Each team picks its boundaries, and the important part is writing them down so the number means the same thing next quarter as it does today.

The choice of end event changes the result more than people expect. Suppose a ticket moves to In Progress on Monday at 10am. The pull request opens Wednesday, merges Thursday, and ships in Friday's release. Measured to merge, the cycle time is about three days. Measured to deploy, it is about four. If your team batches releases weekly, a merge-based metric will hide a day or more of delay that customers actually feel.

A reasonable default for a startup that deploys continuously is start at In Progress, end at production deploy. If deploys are manual or batched, track merge as the end and treat the merge-to-deploy gap as a separate measurement.

A flow metric, not a speed score

Cycle time describes how work moves through your system. It does not measure how hard any one person works. A developer can code for two focused hours and still have a ticket with a three-day cycle time because it sat waiting for review. Treating the number as individual effort is the most common misreading, and it leads to bad decisions.

Because ticket durations are skewed (most finish quickly, a few drag on for weeks), a single average misleads. Report a distribution instead. The median (50th percentile) tells you what is typical. The 85th percentile tells you that 85 percent of items finish within that time, which is a more honest basis for forecasting and for spotting the long tail.

Cycle Time vs. Lead Time vs. PR Cycle Time

These three terms get used interchangeably, and they should not be. They differ in where the clock starts and stops.

• Lead time starts when the work is requested or the ticket is created, so it includes time spent waiting in the backlog. It reflects what a requester experiences.
• Cycle time starts when someone begins working. It reflects how efficiently your team moves work that is already underway.
• PR cycle time is a narrower, code-level slice, usually from first commit or PR open to merge. It says nothing about planning, QA, or release.

One feature, three measurements

Imagine a feature ticket created on the 1st of the month. It sits in the backlog until the 8th, when a developer moves it to In Progress. The first commit lands on the 8th, the PR opens on the 10th, the PR merges on the 11th, and the feature deploys on the 12th.

• Lead time (created to deployed): 11 days.
• Cycle time (In Progress to deployed): 4 days.
• PR cycle time (PR open to merge): 1 day.

Same feature, three very different numbers, and each answers a different question. A long lead time with a short cycle time points at prioritization and backlog management. A long cycle time with a short PR cycle time points at what happens before the PR or after the merge.

The DORA connection

The DORA research program tracks a related metric it calls lead time for changes, which runs from code commit to running in production. It is defined separately from the cycle time described here, and DORA has refined its wording across reports. Check the latest DORA publication before quoting its definition or thresholds.

The practical rule: never compare numbers across teams or tools without confirming how each defines start and end. A team that starts the clock at ticket creation and a team that starts it at first commit are measuring different things, and the comparison will mislead you.

Where Cycle Time Actually Goes: The Stages to Break Down

A single cycle time figure tells you whether you have a problem. A stage breakdown tells you where it is. A typical pull-request-based workflow has these stages:

1. Coding: from work start to PR opened.
2. Waiting for review: from PR opened to first review activity.
3. Review and revisions: from first review to approval.
4. Waiting to merge or deploy: from approval to merge, and from merge to production.
5. QA or release: any verification or release process after merge.

In many teams, a large share of elapsed time is spent waiting rather than working. A PR sits unreviewed overnight, an approved change waits for the next release window, a ticket idles because its author moved on to something else. This is a pattern worth checking in your own data rather than a fixed rule. If your coding stage is a day and your total is five, the other four days are where improvement lives, and no amount of typing faster will recover them.

A hypothetical review bottleneck

For example, imagine a seven-person startup where only two senior engineers are trusted to approve changes to the core service. Coding takes a median of one day. But PRs wait a median of two days for a first review, because both reviewers are also writing features and handling incidents. Total cycle time is dominated by the review-wait stage, and the cause is structural: too few reviewers for the volume of changes. Pushing developers to code faster would change nothing. Spreading review ownership, or writing down which areas need senior sign-off and which do not, would.

Common drivers of long stages

Two causes show up repeatedly. The first is large pull requests. Big diffs are harder to review, so they wait longer for a reviewer, attract more revision rounds, and carry higher risk of merge conflicts. The second is work-in-progress (WIP) overload. When each developer has four items open, each item spends most of its life idle. Individual tasks are not slow; they are just not being touched. Both drivers are visible once you break cycle time into stages and look at PR size and open-item counts alongside it.

How to Measure Cycle Time from Linear and GitHub

If your tickets live in Linear and your code in GitHub, you already have the raw events. The work is connecting them consistently.

1. Pick the start event. The simplest is the timestamp when a Linear issue first moves to In Progress.
2. Pick the end event. Use PR merged if you deploy on merge, or the production deploy time if you can capture it.
3. Link issues to PRs. Linear's GitHub integration can associate PRs through branch names or issue IDs in titles and descriptions. Enforce one convention, because unlinked PRs fall out of your data.
4. Subtract the timestamps for each completed item, then aggregate.

Edge cases to decide up front

• Reopened tickets: either count from the original start or treat the reopen as a new item. Pick one and stay with it.
• Started but paused: a ticket parked for a week inflates the number. Use a Blocked or Paused status so you can exclude or at least flag that time.
• No linked PR: design and research tasks may have no code. Exclude them or measure to Done.
• Weekends and holidays: decide whether to use calendar time or working time. Calendar time is simpler and fine for trend tracking.

Reporting it

Calculate the median and 85th percentile over a rolling window, such as the last 30 days, and segment by work type: bugs, features, and chores behave differently and blending them hides signal. Small teams may have few completed items per window, so avoid reading too much into a single month.

You can do all of this in a spreadsheet by exporting from both tools, but it is tedious and tends to be abandoned. Automated tooling removes that burden. Progress, for example, ingests Linear and GitHub activity and surfaces stalled work without hand-built queries, so you spend time on the slow items instead of assembling the data.

Reading Cycle Time Without Gaming It

Published benchmarks exist, from the DORA reports and from vendor studies of engineering data, but they vary by year, sample, and methodology, and they often define start and end differently from you. Treat any figure you find as context, cite its source and year if you use it, and remember that what is true of a large enterprise sample may not describe a ten-person team. Your own trend is the better benchmark: is your median falling, flat, or rising over the last several months?

Goodhart's law applies

When a measure becomes a target, it stops being a good measure. If cycle time becomes a goal, people can lower it without delivering faster: splitting one ticket into several artificial pieces, approving reviews without reading, or moving tickets to In Progress later than work actually began. Guard against this by pairing cycle time with quality signals such as change failure rate, reverts, and hotfix volume. If cycle time drops while reverts climb, you have traded quality for a prettier number.

Trends and outliers over snapshots

The most useful signal is often the gap between the median and the 85th percentile. A stable median with a rising 85th percentile usually means a handful of items are stalling while typical work flows normally. That is where momentum context helps: knowing whether the team's overall output is accelerating or slowing tells you whether the long tail is an isolated blockage or part of a broader slowdown.

Never rank individuals

Cycle time reflects the system: ticket quality, review capacity, deployment process, dependencies. Ranking developers by it punishes people for taking on hard problems, discourages them from reviewing others' work, and teaches everyone to avoid ambiguous tickets. Use it to ask questions about the process, not to evaluate people.

Practical Ways to Reduce Cycle Time

Because most cycle time is waiting, the highest-value changes reduce queues rather than push people to work faster.

• Shrink batch size. Agree on a concrete target, such as most PRs under a few hundred changed lines and most tickets completable in one to three days. Thinner tickets and smaller PRs get reviewed faster and break less.
• Set a review-response expectation. For example, a first review within one working day. Make the review queue visible, whether through a shared channel, a dashboard, or a daily check, so waiting PRs do not go unnoticed.
• Limit work in progress. Set a soft cap per person, often one or two active items, and finish before starting. This feels slower per developer and is usually faster per ticket.
• Flag stalled work early. Waiting only gets fixed when someone notices it. You can do this with a daily scan of items idle for more than a set period, or use tooling: Progress's pre-computed signals flag stalled work and change pressure from merge volume and code churn, which is one option for catching problems before they show up in your percentiles.
• Review the slowest 10% monthly. Pull the slowest tenth of completed tickets and ask what happened to each. Patterns emerge quickly: unclear requirements, a blocked dependency, a reviewer shortage, an oversized change.

Change one thing at a time where you can. If you shrink PRs and add a review SLA in the same week, you will not know which one moved the number. Give each change a few weeks of data before judging it.

Treat Cycle Time as a Question, Not a Score

Cycle time works best as a trend you watch and a prompt for conversation. A rising 85th percentile does not tell you who is at fault; it tells you where to look. The number is only as trustworthy as the definitions behind it, and it only improves when the team acts on what the slow items reveal.

This week, write down your start and end events, link your Linear issues to GitHub PRs consistently, and pull a 30-day median and 85th percentile. Then open the slowest tickets and find out why they were slow. That single exercise will teach you more than any benchmark. If you want that analysis done continuously rather than by hand, Learn more about our services.