Skip to main content

Issues and PRs > Assigned at

Tom Williams avatar
Written by Tom Williams
Updated over a week ago

Dataset: Issues & Pull Requests

Entity: Pull Requests, Issues

Field ID: assigned_at

Type: Datetime

Description: The datetime at which a user was first assigned to the item.

Source: Calculated

Transformation logic:

  • GitHub, GitLab, Jira, and Trello: It is the datetime of the first user assigned event, which happens when a user is added to the list of assignees for the first time.

  • ClickUp: Since this app does not expose historical events, Keypup tracks changes on the assignees field to detect this timestamp. This tracking only applies to assignments performed after the project has been connected to Keypup. This field remains null when we detect that reviewers were assigned before importing the issue or pull request to Keypup because we cannot know precisely when this assignment occurred.

From:

Github (PRs, Issues)

The date of the first user assigned event

Gitlab (PRs, Issues)

The date of the first user assigned event

Bitbucket (PRs)

N/A - no concepts of assignment

Azure DevOps (PRs, Issues)

N/A - no concepts of assignment

JIRA (Issues)

The date of the first user assigned event

ClickUp (Issues)

Use updated_at when the assignees attribute is populated for the first time

Trello (Issues)

The date of the first user assigned event

Reporting Use Cases

The assigned_at field is fundamental for measuring your team's responsiveness and the lifecycle of their work. As a timestamp, it can be used for calculating key performance indicators, filtering your data, and analyzing trends.

  • Calculating Durations and Lead Times: This field marks the official start of work on an item. You can calculate critical metrics such as:

    • Lead Time for Changes: The total time from assignment to completion, calculated with (closed_at - assigned_at) / DAY(). This is a core DORA metric that measures the efficiency of your development process.

    • Time to First Commit: The time it takes for a developer to start coding after being assigned the task, using (first_commit_at - assigned_at) / HOUR(). A high value might indicate that developers are being assigned work long before they have the capacity to start.

    • Age of Open Items: For items that are still open, you can calculate how long they have been in progress with (NOW() - assigned_at) / DAY(), which helps identify stale or blocked tasks.

  • Filtering and Triage: The presence or absence of this timestamp is a powerful filter:

    • Finding Untriaged Work: Use a filter where assigned_at is null to create a list of all issues and pull requests in your backlog that have not yet been assigned to anyone.

    • Time-based Filtering: You can filter for all work that was assigned during a specific period, such as "in the previous 3 months," to focus reports on a specific sprint or quarter.

  • Trend Analysis: By using assigned_at as a dimension in charts, you can visualize workflow patterns over time. For example, using YEAR_MONTH(assigned_at) as a dimension with COUNT() as a metric will show you how many new items your team picked up each month, helping you understand team capacity and workload distribution.

Did this answer your question?