Per-engineer workload
There's no separate "workload" screen — the same Timesheet grid that drives CapEx/OpEx (/timesheet, the Grid tab) is how you read who's full, who's idle, and who's overloaded. Rows are people, ordered by manager hierarchy; columns are the period you've selected; cells are inferred hours.
Per-engineer hours for a month, nested by reporting line.
What it does, and where the data comes from
The grid runs the same inference engine as the report: issue transitions become status spans, spans that fall in an in-progress status (per the rules you've configured) are attributed to the issue's assignee, and each day's total is bounded by the org tree's daily cap before being rolled into the display buckets. Employees are nested under their manager, so a lead's row sits above their reports.
Expanding a row (the ▶ toggle) breaks it down into that person's individual tickets for the period, each with its own per-bucket hours. Clicking a ticket opens a drawer of its raw in-progress intervals — exact start and end timestamps per status — so you can see precisely which spans produced the number.
What a full or overloaded person looks like
The daily cap (default 8h, set per org tree) is the reference line for a "full" day: in Normalized mode, no single day can show more than that cap, so a row that sits at or near workdays × cap for the period is running at capacity. A row that stays there month after month, or a single ticket dominating someone's expanded breakdown for weeks, is the signal to look closer — most often a ticket parked in an active status rather than genuinely being worked that whole time.
Normalized vs Raw time basis matters here: Normalized spreads each ticket's wall-clock time evenly across everything active at once, so concurrent tickets never make a day look longer than it was. Raw counts each ticket's full logged duration independently, so someone juggling several simultaneously in-progress tickets can show inflated daily numbers even before the cap trims them down — a useful signal that WIP, not effort, is the issue.
Assignees that don't resolve to a tracked identity land in an Unmatched summary row instead of any person's total — a workload picture with a large Unmatched row is incomplete, not necessarily light.
The date window
- Week / Month / Year — the granularity selector. Week and Month display day-by-day columns; Year rolls up to month columns.
- ‹ › period navigator — steps the anchor date backward or forward by one unit of the selected granularity.
- Normalized / Raw — the time-basis toggle described above.
- Org tree picker — switches the whole grid to a different tree; hidden when the grid is already embedded on a single tree's Timesheet tab.
If it looks wrong
| Symptom | Cause | Fix |
|---|---|---|
| Someone's row is far higher than their teammates' | A ticket parked in an active status, or several concurrent in-progress tickets in Raw mode | Expand the row to find the ticket, then see working practices |
| A person is missing entirely from the grid | Their tickets' assignee doesn't resolve to their tracked identity | Check the Unmatched row and confirm assignee/identity matching |
| Totals look different between two time bases | Normalized vs Raw handle overlapping tickets differently | Expected — use Raw to spot concurrent-ticket WIP, Normalized for the credited total |
Related
- Timesheet — the section hub and how hours are inferred.
- Working practices these numbers depend on — what to do about an overloaded row.
- Org trees — the hierarchy the grid nests employees under.
Last updated