Coding Time Metric

Definition

The Coding Time Metric measures the duration between the first commit in a branch and the time the pull request (PR) is opened or transitions from draft status to being ready for review.

Why is This Metric Useful?

This metric provides insights into the time developers spend actively writing code, helping assess focus and efficiency during development.

How to Use it?

• Use Coding Time to evaluate the balance between active coding and non-coding activities.
• Shorter coding times may indicate streamlined processes, while longer times might reveal potential delays due to non-coding tasks or inefficient workflows.

Examples for Context

• Teams with reduced Coding Time often foster a culture of frequent collaboration, which accelerates development.
• High Coding Time may suggest inefficiencies, such as inadequate task planning or overcomplicated tasks.

Calculation

• Difference between the timestamp of the first commit in a branch and the creation of a PR

The Coding Time Metric is calculated as the duration between the first commit in a branch and the issue's start time in the In Progress state. The issue start time is determined by the Issue Start Time Calculation Strategy configured in the settings:

1. By First Transition:
   • The issue's start time is defined as the timestamp of the first transition to the In Progress state.
   • Coding time is measured from the first commit to this first transition.
2. By Last Transition:
   • The issue's start time is defined as the timestamp of the last transition to the In Progress state.
   • Coding time is measured from the first commit to this last transition.

This configuration directly impacts the Coding Time and related metrics, such as MTTR (Mean Time to Resolution), by defining when the issue is officially considered as "in progress." The selected strategy ensures flexibility to match your team's workflows and accurately reflect the time developers spend coding before active progress begins..

Considerations for Using the Metric

1. Draft Pull Request Logic

• Draft PRs are identified based on metadata in the repository.
• Coding Time calculation begins when the PR transitions from draft to active status.

1. Squashed Commits

• When commits are squashed, timestamps for intermediate commits are lost.
• The metric will rely on the earliest available timestamp to ensure accuracy.

1. Cherry Picking

• Cherry-picked commits may lead to duplicate timestamps across branches.
• To avoid skewed metrics, only the original commit timestamp is considered.

1. Coding Time Using Project Management (PM)

• Fallback for Unconnected Branches: If a branch is not linked to a ticket, the metric defaults to the first commit timestamps.
• Late Ticket Connections: If a ticket is connected after the PR is opened, the metric adjusts retroactively based on the first and last ticket transitions.

1. Recommendation of Strategy

• For local work, consider leveraging PM integration to ensure alignment.
• If poor ticket management (e.g., incomplete Jira updates) impacts metrics, use the first commit timestamp as a fallback.