Jira allocation

DX lets you track how engineering time is allocated based on categorization rules which you define. Jira allocation reporting can be used for business reporting as well as financial use cases such as CapEx reporting.

Jira allocation reporting involves two parts:

  • Issue categorization – DX categorizes issues based on customizeable SQL-based categorization rules.
  • Issue time spent – DX calculates the time spent on each issue using data from Jira and GitHub (when available).

Issue categorization

By default, DX provides categorization rules for parent issue (e.g., Epics) and projects. In addition, customers can create custom SQL-based categorization rules to cover any use case. For more information, see Creating Jira categorization rules.

Issue time spent

DX estimates time spent on tasks by combining data from Jira issues and GitHub commits. DX updates calculations in your database nightly.

Time spent is calculated as follows:

  • Developers are treated as having a maximum capacity of one Dev week per every five weekdays (i.e., 0.2 Dev weeks per weekday).
  • For each weekday, DX looks up issues that were in an in-progress stage and then divides the developer’s capacity across those issues based on time spent in an in-progress status.
  • Time is allocated based on the month work is performed. If an issue moves to an in-progress stage in January but is completed in February, time is allocated to each month accordingly.
  • If an issue has sub-tasks worked on by multiple developers, DX allocates time to each developer based on their sub-task activity.
  • If multiple developers contribute to a Jira issue (e.g., one assigned, others authoring commits), DX can use GitHub commits data—if the data connector is enabled—to allocate work more precisely.
  • Calculations are winsorized by treating issues as in-progress for up to 30 days after the last recorded activity.

In order to be included in calculations, the conditions below must be true:

  • The Jira issue must be non-deleted
  • The Jira issue must be assigned
  • The Jira issue must have been moved to an in-progress status category
  • The Jira issue must have hierarchy level of 0 (i.e., not Epics or Initiatives)
  • DX must have access to the Jira issue (i.e., not listed in denylist)

Advanced settings

Active status allowlist

By default, all in-progress statuses count toward time tracking. If some statuses shouldn’t be counted, you can specify which statuses to include. To see all of your in-progress statuses, run the following query in Data Studio:

select distinct(name)
from jira_statuses
where status_category = 'indeterminate'

GitHub commit signals

When this setting is enabled:

  • If a task has a commit on a given day, the task will be considered active for that day for the commit author regardless of Jira data.
  • If multiple developers contribute to a Jira issue (e.g., one assigned, others authoring commits), time will be allocated to each person.

To enable this setting, you must have set up the GitHub commits data connector.

Parent issue allowlist

This field allows you to limit which parent issue types (i.e. Epics, Initiatives) appear in the report.

Max days in status

By default, DX tracks up to 30 days per status after the last activity. So if a task was in “In Development” for 45 days and “In Review” for 45 days, only 30 days in each status would count (60 total). You can change this threshold as needed.

Allocation limits

By default, all users in are assumed to be at 100% capacity for engineering work. However, you can adjust this per-contributor limits—for instance, setting managers to 60% capacity or excluding certain individuals entirely by setting their limit to 0.

To check the currently set limits, export a CSV from the settings page or view the raw data in the jira_allocation_limits table. To update your settings, re-upload a CSV with modified values. Updates are applied to DX reports nightly.

Uploaded settings are cumulative, meaning that you don’t need to include all users in each CSV upload. However, you must include full row-level data for any user included in the CSV.

Your can include effective date values to account for changes in a contributor’s capacity over time. For example, if an engineer starts as an IC (100% capacity) and later becomes a manager (60% capacity), your CSV would look like the example shown below.

email, capacity, effective_date
dev@example.com, 1
dev@example.com, 0.6, 2024/01/24