Dataset: Issues & Pull Requests
Entity: Pull Requests
Field ID: resolved_issue_first_assigned_at
Type: Datetime
Description: The earliest first assignment date among all resolved issues (via auto-closing keywords). This field only considers the assigned_at field of issues, not the last_assigned_at field. It is only applicable to pull requests.
Source: Calculated
Transformation logic:
Pull Requests: The earliest occurrence of all
assigned_atfields from resolved issues. Thenullvalues are ignored. Anullvalue is returned only if allassigned_atvalues arenull. Resolved issues are issues that are referenced by a resolving pull request.Issues: Not applicable. This field will always be
null.
From: |
|
Github (PRs, Issues) | Calculated |
Gitlab (PRs, Issues) | Calculated |
Bitbucket (PRs) | Calculated |
Azure DevOps (PRs, Issues) | Calculated |
JIRA (Issues) | N/A |
ClickUp (Issues) | N/A |
Trello (Issues) | N/A |
Reporting Use Cases
The Resolved Issue First Assigned At field is a powerful timestamp that marks the earliest point in time that any of the underlying issues for a pull request were assigned. It effectively represents the "true start" of active work for a feature or bug fix, making it invaluable for calculating more accurate, business-oriented lead times.
Calculating Accurate Feature Lead Time: This is the primary use case. Instead of measuring from the pull request's creation, you can measure the entire lifecycle from the moment the work was first triaged and assigned.
You can calculate an end-to-end "Active Lead Time" with the custom formula
(merged_at - resolved_issue_first_assigned_at) / DAY(). This metric provides a more holistic view of your process, including the time from issue assignment to the start of coding.
Analyzing Triage and Queue Time: By comparing this timestamp with the creation date of the first related issue, you can measure the efficiency of your backlog grooming and triage process.
The formula
(resolved_issue_first_assigned_at - resolved_issue_first_created_at) / DAY()calculates the "Time to Triage" for a feature. A high value here indicates that issues are sitting in the backlog for a long time before being assigned, which could be a bottleneck in your planning process.
Filtering for Historical Analysis: You can use this field to find pull requests that have resolved very old or long-running issues.
To identify recently completed work that cleared out old technical debt, you could create a report filtered where merged_at in the previous 30 days and
Resolved Issue First Assigned At before 1 year ago. This helps you understand the age of the work your team is delivering.