The Time Allocation Matrix answers a question the other time reports cannot: where did our effort actually go?
Other reports slice logged time by person or by item. This one rolls it up through your own hierarchy — your epics, your stories, your tasks, whatever structure you use — and spreads it across calendar months. The result is a grid you read top-down for structure and left-to-right for time.
It is built for the reporting people usually do in a spreadsheet at quarter end: how much went into each product line, how that split moved month to month, and what share of the total each branch consumed. Capitalization reporting, client billing summaries, R&D allocation, and "what did the team spend Q1 on" all fall out of the same report.
Find it under Analyze → Analytics → Time → Time Allocation Matrix. You need the time tracking report permission — the same one that gates User Time Tracking.
The report runs in two stages: a setup form where you define the shape, then the results grid.
Rows are your item hierarchy, one level per item type you configured, expandable and collapsible. Every parent branch also gets a subtotal row carrying its rolled-up hours and an allocation row expressing the same branch as percentages. A Grand total row stays pinned beneath the header as you scroll.
Columns are calendar months — Jan 2026, Feb 2026 — followed by Range Total and Total %.
Cells are logged hours to two decimal places. The metric is Actual Time: real time entries recorded against work items, not estimates.
Beneath the title you will see the run's provenance, for example:
Actual Time (hours) · America/New_York · Executed 11 Aug 2026, 09:14
| Badge | Meaning |
|---|---|
| Archived | The item is archived. Archived items are included — retiring an item does not erase the time spent on it. |
| Direct | Hours logged straight onto this item that no child row accounts for. Hover for the exact figure. |
Direct is worth understanding. If your levels are Epic → Story and somebody logged time on the epic itself rather than on any story, that time belongs to the epic and to no story. Rather than hide it or double-count it, the report keeps it on the epic's row and flags it. Direct where you did not expect it usually means work is being logged at the wrong level.
Down the Range Total column — how effort divided across your structure over the whole period. This is the allocation question: which product line, which epic, which client consumed the budget.
Across a row — how one branch's effort moved over time. This is the trend question: did the migration ramp up in March, did support load fall after the fix shipped.
The allocation rows turn the first reading into percentages automatically, both per-month and for the range, so you do not have to compute shares by hand.
Click Analyze, stay on the Analytics tab, and under Time in the sidebar click Time Allocation Matrix. Unlike the other reports this one does not run automatically — it needs a hierarchy before it has anything to show.
Under Monthly reporting period, set Start date and End date. The defaults are the start of the current year through the end of the current month.
The helper text states the two rules:
Actual Time is grouped into calendar months in the organization timezone. A report can include up to 24 months.
Partial months. Columns are whole calendar months. If your start date is not the 1st, or your end date is not the last day of its month, that column covers only part of the month — and the report says so rather than quietly under-reporting. The header gains a suffix (Jan 2026 (Partial)) and a warning names exactly what was excluded: "Jan 2026 is partial; excluded Jan 1, 2026 through Jan 14, 2026 (14 days)." Only the first and last columns can ever be partial.
This is the part that shapes the report:
Levels are evaluated from top to bottom. Item type names stay current when they are renamed.
Level 1 — choose an Item type (say Epic), leave Selection mode on All, and set a Root scope with Choose items. The root scope is required when level 1 uses All, and it is what stops the report scanning your entire organization.
Level 2 onward — click Add level and choose the next item type (say Story). Levels below the first need no root scope; their items are found beneath the level above.
Each level is a card with Move up, Move down, and Remove. Switching Selection mode to Selected lets you pick exact items instead — useful for a fixed comparison set, and those rows appear in the order you picked them.
The rules, which you will meet as validation messages:
| Rule | Message |
|---|---|
| At least one level | Add at least one hierarchy level. |
| No more than 15 | Use no more than 15 hierarchy levels. |
| Every level needs a type | Choose an available item type for level 2. |
| No type used twice | Each hierarchy level must use a different item type. |
| Each level below the one above | Task must be below Story in the item-type hierarchy. |
| Root scope when level 1 is All | Choose at least one root scope when the first level uses All. |
That fifth rule is the one that catches people. Levels must follow your organization's item-type hierarchy — Epic → Story → Task works, Task → Epic does not. They do not have to be adjacent: Epic → Task is fine if tasks live under stories, because the report looks for descendants at any depth.
Problems are listed under Complete the report configuration, and Run report stays disabled until they are resolved.
Click Run report. Use Back to setup to change the configuration and Refresh to re-run it against current data.
Start at the Grand total row pinned under the header, then collapse everything and read the top-level subtotals for the big split. Check Total % for each branch's share, expand the branch that surprises you, and repeat one level down.
Watch for Direct badges (time logged at a level where you expected it on children) and for warning banners — a partial period, or "Some configured selections are unavailable or outside the selected hierarchy." The latter means part of your configuration no longer resolves: an item was moved, archived out of scope, or you lost access to it.
If the grid is empty, the message distinguishes the two causes:
| Message | Meaning |
|---|---|
| No matching items — No authorized items matched this hierarchy and date range. | A configuration problem. Check the root scope and that your level item types match how items are actually structured. |
| No time recorded — Matching items were found, but they have no Actual Time in this date range. | A data problem. The structure is right; the hours are not there. |
Click Views in the toolbar and save. Choose Visible only to you or Visible to coworkers.
Saved views store the configuration, not the results — dates, levels, item types, selections. Opening one drops you on the setup form with everything filled in; you press Run report for current numbers. That is what makes a monthly report repeatable. You can share a view by copying its link.
Views shared with you are filtered through your item access first. If a colleague's view references items you cannot read, those references are stripped and you get "Some saved report settings are unavailable or outdated." Re-pick the missing scope and run it. The stripping is deliberate — it stops a shared view disclosing items you are not allowed to see.
These views cannot be published to the customer portal; this is an internal reporting surface only.
The on-screen grid is for exploring; the export is for handing over — to finance, to a client, or into your own spreadsheet.
.xlsx. It is not emailed.A single Allocation Matrix worksheet:
Two deliberate differences from the screen: the workbook uses one column per level rather than a single indented column, so you can filter and pivot in Excel; and it contains every row, not just the expanded ones, with Excel outlining to collapse them.
Archived items get (Archived) appended. Direct time becomes an Excel cell comment on the Range Total cell. Hours format as 0.00 and percentages as 0.00% — real numbers, not text, so they calculate.
Running the report creates a snapshot that lives for 30 minutes. The export renders from that snapshot rather than re-querying, so the workbook matches exactly what you saw — it cannot drift because someone logged time while the export ran.
The trade-off is expiry. Export too late and you get "Run the report again before exporting. The current results will remain visible until you rerun." Click Rerun report and export again; your results stay on screen meanwhile.
Item permissions are re-checked when the export runs, not only when you ran the report — so an export can never contain items you are not currently entitled to see.
Time entries are included when all of these hold:
Everything is summed in whole seconds and rounded only for display, so a column can look off by a hundredth against a manual sum of the printed numbers. The underlying arithmetic is exact.
Whose time? Everyone's. The matrix is not filtered by person — it sums all time logged against the items you can see, and there is no self-only mode. What limits you is item access: anything you cannot read silently drops out. Two people running the same saved report can therefore legitimately see different numbers.
How time gets in. The report reads DevStride time entries, recorded the usual ways — the time control on an item, the item drawer's time-tracking tab, a running timer, or the API. Nothing extra is needed. Time cannot be logged against workstreams or sub-tasks, so only work-item time appears.
Several things are deliberately not configurable, which keeps the report readable and comparable between runs:
| Metric | Actual Time (hours). No estimates, no points. |
| Column granularity | Calendar months. No daily, weekly, or quarterly view. |
| Timezone | Your organization's timezone, not the viewer's — so everyone sees the same month boundaries. |
| Filters | None. Scope comes from the hierarchy you configure, not from status, label, or assignee filters. |
Because the timezone is the organization's, the same report run in London and New York produces identical numbers. The timezone in use is printed under the title and in every export.
| Limit | Value |
|---|---|
| Hierarchy levels | 15 |
| Date range | 24 months |
| Rows in a result | 5,000 |
| Configured item selections | 5,000 |
Exceeding one produces a clear message asking you to narrow the scope. In practice the row cap is the one you meet, usually by putting a very granular item type at the deepest level across a wide scope.
Goal: how much engineering time went into each product line last quarter, split by month, as percentages.
| Problem | Likely cause |
|---|---|
| This report is too large to display | Over 5,000 rows. Narrow the root scope, drop the deepest level, or shorten the range. |
| Fewer rows than expected | Rows with zero hours are dropped. The items exist; the time was not logged. |
| The item-type hierarchy for level 2 contains a cycle | Your organization's item-type configuration has a loop. An administrator needs to fix it. |
| Time allocation matrix hierarchy cannot be resolved uniquely | An item is reachable by two different paths in your configuration. Simplify the scope so each item has one home. |
| Numbers differ from a colleague's | You have different item access. The report only sums items you can read. |
| Run the report again before exporting | The 30-minute snapshot expired. Click Rerun report. |
| Export shows Failed or Timed Out | Usually size. Narrow the scope or shorten the range and try again. |
| You no longer have access to run this report | The report permission was removed from your role. |