Skip to main content

Coding Time Metric

Coding Time Metric

Steven Silverstone
Updated by Steven Silverstone
Definition

Coding Time measures the elapsed time from the start of work on a branch to the creation of a pull request (PR).

In the standard model:

Coding Time = Time from first commit in a branch to PR creation

If draft pull requests are used, coding time ends when the PR becomes ready for review (i.e., when it transitions from draft to active/ready), not when the draft is initially created.

How the Metric Is Calculated

Standard Calculation

Coding Time is calculated as:

PR creation (or “ready for review”) timestamp − first commit timestamp

Where:

  • First commit timestamp = earliest commit timestamp observed for the branch
  • PR creation timestamp = the timestamp when the PR is opened
    (or when the PR transitions from draft to active, if draft logic applies)
Draft Pull Request Logic

If draft PRs are enabled:

  • Draft PRs are identified using repository metadata.
  • Coding Time ends when the PR transitions from draft to active/ready-for-review status.

This prevents long-lived drafts from being treated as “ready for review” work.

Jira-Based Coding Time

If Jira-based coding time is enabled, the metric can use a ticket-based start timestamp strategy.

In that configuration:

  • The “coding start” timestamp is derived from the linked Jira issue’s transition to In Progress, based on the configured Issue Start Time Calculation Strategy.

Strategies include:

  • By First Transition: Start time = first transition to In Progress
  • By Last Transition: Start time = last transition to In Progress

If the branch is not linked to a ticket, Coding Time falls back to the first commit timestamp.

If a ticket is linked after PR creation, historical values may be recalculated based on the ticket’s transitions.

(These behaviors are captured in your existing article and must remain explicit.) 

Normalization

The headline value is normalized to the selected time bucket and aggregation type.

  • Daily / Weekly / Monthly determines the time bucket.
  • AVG / P50 / P75 / P90 determines the aggregation method over PRs in that bucket.

The headline value represents:

Aggregate Coding Time (AVG or percentile) for PRs created within the selected time range

This is a duration statistic, not cumulative time.

How the Metric Is Displayed in the Dashboard

1. Headline Value (e.g., 11h, 10m on average)

Represents the selected aggregation (AVG/P50/P75/P90) of Coding Time across PRs created in the selected period.

2. Time-Based Values in the Chart

Each chart point represents:

The selected aggregation (AVG/P50/P75/P90) of Coding Time for PRs created within that time bucket

The tooltip may display sample size context (e.g., number of branches/PRs contributing to the bucket).

What This Metric Reflects

Coding Time reflects the duration of the “implementation phase” before review begins.

It is sensitive to:

  • Work batching (large vs small units of work)
  • Context switching and interruptions
  • Local workflow patterns (commit habits, draft PR usage)
  • Ticket workflow discipline (if Jira-based timing is enabled)

It does not measure review responsiveness (Pickup Time) or review duration (Review Time).

Data Sources

Derived from:

  • Git commit metadata (branch commit timestamps)
  • PR creation events and draft status transitions
  • Jira issue transitions (if Jira-based coding time is enabled)
Tunable Configurations

Coding Time may be influenced by:

  • Jira-based coding start configuration (Issue Start Time Calculation Strategy)
  • Draft PR handling (draft-to-ready transition logic)
  • Repository/branch inclusion and filtering rules
  • PM integration linkage rules (ticket-to-branch association)
Limitations
  • Squashed commits: Intermediate commit timestamps may be lost; the metric uses the earliest available timestamp.  
  • Cherry-picked commits: Duplicated timestamps may appear across branches; the metric uses the original commit timestamp to avoid skew.  
  • Late ticket connections: Linking a ticket after PR creation may trigger recalculation based on ticket transitions.  
  • Ticket hygiene sensitivity (Jira mode): Incorrect or inconsistent Jira transitions can distort the computed start time.
  • Draft PR behavior: Long-lived drafts can shift coding time end point to “ready for review,” which may differ from PR creation time.

Coding Time measures elapsed time between defined system events — not the amount of focused “hands-on keyboard” work.

Stakeholder Use Cases

Engineering Managers

  • Identify unusually long implementation phases and potential batching issues.
  • Detect teams or repos where work consistently sits in coding for extended periods.

Team Leads

  • Encourage smaller PRs and earlier PR opening to improve feedback loops.
  • Diagnose workflow friction (context switching, unclear task scope).

Developers

  • Compare personal or team patterns (early PR creation vs “big bang” PRs).
  • Validate that workflow habits (draft PRs, ticket linking) align with measurement goals.

Platform / DevEx Teams

  • Evaluate whether Jira workflow configuration aligns with engineering reality.
  • Improve tooling and standards for branch naming, ticket linking, and PR readiness conventions.

How did we do?

Code Changes Metric

Commits Metric

Contact