Coding time

Most engineering leaders can tell you their sprint velocity. Far fewer can tell you how much of their squad's time is actually spent writing code. Coding time is the elapsed time from when a developer first commits code on a branch to when they open a pull request for review. It is one of the most diagnostic signals in your delivery pipeline because it shows where work is flowing and where it is stalling before anyone else even sees it. This page covers the definition, how to measure it, benchmarks, how to improve it, and how DevStats surfaces it automatically.

• Coding time is the duration between a developer's first commit on a branch and the moment they open a pull request. It matters because it is the only phase of the delivery cycle that is entirely within the squad's control, making it the clearest signal of where development work is actually getting stuck.
• Coding time is calculated as: Coding Time = PR open timestamp minus first commit timestamp. No universally published DORA benchmark exists for this specific phase, but high-performing teams typically see median coding times under 24 hours for routine changes, with complex feature work reasonably falling between one and three days.
• The most common mistake teams make is treating long coding time as a productivity problem when it is often a scoping problem. Oversized tickets, unclear acceptance criteria, and missing dependencies inflate coding time before a player writes a single line of code.
• DevStats tracks coding time automatically by connecting to your Git provider and surfacing it alongside the full PR cycle time breakdown, with benchmarks against 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.

Coding time definition

Coding time is the time a developer spends actively building a change, measured from their first commit on a branch to when they open a pull request. It represents the pure development phase of the software delivery lifecycle, before review, approval, or deployment enter the picture.

Technically, it is calculated as: Coding Time = PR open timestamp minus first commit timestamp. This measurement comes directly from your Git provider and requires no manual input from players. When coding time is consistently long, it signals that tickets are too large, dependencies are unresolved, or the development environment itself is creating friction. Reducing it without sacrificing quality is one of the clearest ways to improve your team's overall PR cycle time.

Why coding time matters for engineering teams

When squads do not track coding time, long development phases become invisible. Sprint commitments slip not because review takes too long, but because the code was never ready for review on time. By the time a manager notices the delay, the sprint is already at risk and the window for intervention has closed.

Coding time connects directly to your delivery KPIs. Predictable coding time means predictable sprint completion, which means more reliable commitments to stakeholders. It also signals workload distribution: when one squad's coding time is consistently double another's, that gap usually points to ticket sizing, tooling, or context-switching issues rather than individual performance. Teams that track this as a process signal, not a people signal, use it to make better scoping decisions at the planning stage. You can see how coding time fits into the broader efficiency picture through DevStats's allocation feature, which shows how engineering time is distributed across different types of work.

Within the SPACE framework, coding time maps to the Activity and Efficiency dimensions. It is a leading indicator: if coding time starts climbing sprint over sprint, something upstream in planning or ticket scoping is breaking down. Measurement surfaces the pattern. The engineering leader decides what to do about it.

How to measure coding time

Coding time is calculated from Git data alone: Coding Time = timestamp of PR open minus timestamp of first commit on that branch. You need a Git provider connection, whether GitHub, GitLab, or Bitbucket. No issue tracker or CI/CD pipeline data is required for the base calculation, though pairing it with issue data gives you richer context about ticket complexity.

No DORA State of DevOps report publishes a specific benchmark for coding time as a standalone metric. The table below reflects qualitative ranges observed across engineering teams, and benchmarks vary by team size, codebase maturity, and release model. Use these as directional signals, not hard targets. DevStats's benchmarks feature lets you compare your team's coding time against anonymized data from 1,000+ engineering squads.

Coding time in practice: a real example

A VP of Engineering at a 40-person SaaS company noticed that sprint completion rates had dropped from roughly 85% to 65% over two quarters. Review times looked fine in the data. Deployment frequency was stable. When she pulled the coding time breakdown by squad, she found that one team's median coding time had grown from one day to four days over the same period. The tickets had not changed in stated complexity, but the team had recently taken ownership of a new service with an unfamiliar codebase.

She did not assume a performance issue. She ran a ticket audit for that squad and found that most of the four-day items were touching three or more services per change. She worked with the tech lead to break those tickets into smaller, single-service scopes for the next sprint. Two sprints later, median coding time for that squad had returned to under two days, and sprint completion recovered to 80%. The data told her where to look. She decided what to do.

How to improve coding time

1. Right-size tickets before the sprint starts. Review your squad's coding time distribution during sprint retrospectives. If the longest coding times consistently map to the largest tickets, set a story point ceiling and enforce it at planning. Watch for tickets that touch multiple services or require cross-team coordination, these are the ones that inflate coding time before a player writes a line of code. Check your planning accuracy data to see if estimation is consistently off for certain ticket types.
2. Reduce context switching with focused sprint allocation. Players who split time across three or more workstreams in a single sprint take longer to complete any one of them. Audit how your squad's time is allocated across feature work, bug fixes, and maintenance. If context switching is the culprit, restructuring sprint allocation by workstream type can bring coding time down without changing ticket scope.
3. Identify environment and tooling friction. Long coding times are sometimes caused by slow build times, flaky local environments, or missing access to dependencies. Run a brief async survey asking players what slows them down before they open a PR. Fix the top two items. DevStats's activity heatmap can surface patterns in when coding activity drops off, which often points to environmental friction during specific time windows.
4. Pair coding time with PR size as a leading indicator. Large PRs almost always have long coding times. Track PR size alongside coding time each sprint. If both are climbing, the problem is upstream in scoping. If coding time is long but PR size is small, the issue is more likely environmental or dependency-related.

Coding time vs. PR cycle time

Coding time is one phase within PR cycle time, not a synonym for it. Conflating the two leads teams to optimize the wrong thing.

Use coding time when you want to understand what is happening before review begins. Use PR cycle time when you want a complete picture of how long it takes a change to go from start to shipped.