Skip to main content

Issues and PRs > Resolving PR first merged at

Tom Williams avatar
Written by Tom Williams
Updated this week

Dataset: Issues & Pull Requests

Entity: Issues

Field ID: resolving_pr_first_merged_at

Type: Datetime

Description: The earliest merge date among all resolving PRs. (via auto-closing keywords). It is only applicable to issues.

Source: Calculated

Transformation logic:

  • Pull Requests: Not applicable. This field will always be null.

  • Issues: The earliest occurrence of all merged_at fields inherited from resolving pull requests. The null values are ignored. A null value is returned only if all merged_at values are null.

From:

Github (PRs, Issues)

Calculated

Gitlab (PRs, Issues)

Calculated

Bitbucket (PRs)

N/A

Azure DevOps (PRs, Issues)

Calculated

JIRA (Issues)

Calculated

ClickUp (Issues)

Calculated

Trello (Issues)

Calculated

Reporting Use Cases

The Resolving PR First Merged At field is a crucial timestamp that captures the moment the very first piece of code for an issue is successfully merged. This marks the initial delivery of value, making it essential for measuring the speed of your iterative development process and the efficiency of your initial development cycle.

  • Calculating "Time to First Value": This is the primary use case for this field. It measures the total time elapsed from an issue's creation until the first tangible code lands in the main branch, providing a powerful measure of agility.

    • You can calculate this with the custom formula (resolving_pr_first_merged_at - created_at) / DAY().

  • Measuring the Initial Development Cycle: You can isolate the duration of the first complete development-to-merge cycle for an issue.

    • The formula (resolving_pr_first_merged_at - resolving_pr_first_created_at) / DAY() calculates the time from the start of the first PR to its merge, showing how quickly the initial part of a feature moves through your pipeline.

  • Filtering for Partially Completed Work: This field allows you to identify issues where development work has started to be delivered, even if the issue as a whole is still open.

    • To find all open issues that have at least one PR merged, you can create a report using a filter where Resolving PR First Merged At is not null and State = "OPEN". This helps distinguish work that is truly "in progress" from work that is "partially delivered" and may be awaiting further PRs.

Did this answer your question?