Azure DevOps allocation

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

ADO allocation reporting involves two parts:

  • Work item categorization – DX categorizes work items based on customizeable SQL-based categorization rules.
  • Work item time spent – DX calculates the time spent on each work item using data from ADO Boards and ADO pull request commits (when available).

Work item categorization

By default, DX provides categorization rules for parent work item (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 ADO categorization rules.

Work item time spent

DX estimates time spent on work items by combining data from state changes and 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 work items that were in an in-progress stage and then divides the developer’s capacity across those work items based on time spent in an in-progress state.
  • Time is allocated based on the month work is performed. If a work item moves to an in-progress stage in January but is completed in February, time is allocated to each month accordingly.
  • If a work item has sub-items worked on by multiple developers, DX allocates time to each developer based on their sub-item activity.
  • If multiple developers contribute to an ADO work item (e.g., one assigned, others authoring commits), DX can use ADO commits data—if the data connector is enabled—to allocate work more precisely.
  • Calculations are winsorized by treating work items 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 ADO work item must not be a parent (e.g., Epic) or Task, to avoid double counting
  • The ADO work item must be non-deleted
  • The ADO work item must be assigned
  • The ADO work item must have been moved to an in-progress state category
  • DX must have access to the ADO work item (i.e., not listed in denylist)

Advanced settings

Active state allowlist

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

select distinct(name)
from ado_work_item_type_states
where category = 'InProgress'

Allocatable work item types

By default, time is only allocated on Issue, Bug, and User Story work items. To track time on other work item types, you can specify which ones should be included. Regardless of your settings, parent items and tasks are automatically excluded to prevent double counting.

Parent work item allowlist

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

Max days in state

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