Over-Allocation — the burnout signal hidden in your Jira data
Half your team is at 80%. Two engineers are at 130%. Your burndown chart can't tell you who.
Why burnout is invisible in the standard tools
Jira's sprint view shows you the work. It doesn't show you who has too much of it. The sprint can be on track while one engineer is silently drowning, and the only way you find out is when they take an unscheduled PTO day or quit.
Most teams approximate with a heuristic — 'don't load anyone with more than X story points' — but story points aren't comparable across people, and 'too much work' is invisible if it sits across multiple Jira projects, multiple sprints, multiple priorities. The person who appears once in each of six places looks fine on every individual board and unsurvivable on the aggregate.
How agile teams try to spot over-allocation today
Real moves teams make. None scale.
- 1:1s where the manager asks 'how's your load' and the engineer says 'fine' because saying anything else feels like failing.
- A spreadsheet that lists every person and their assigned story points, updated weekly. Stale within hours, never reflects in-flight unplanned work.
- 'Capacity planning' as a sprint-planning event — committed to and immediately violated as soon as the first urgent bug lands.
- Watching for symptoms instead of causes: late commits, missed standups, terse Slack messages. By the time symptoms appear, the over-allocation has been going on for weeks.
How Avium Signals computes over-allocation
Over-Allocation is a per-person calculation done at the same moment as the sprint risk computation. The math is straightforward; the value is that it actually runs:
- Capacity per person: sum of their per-sprint hours (or story points, configurable per org). Set in Avium's resource list — defaults to 40h, adjustable for FTE, PTO windows, and mid-sprint capacity changes.
- Committed per person: sum of planned hours (or points) across every active-sprint ticket they're assigned to. Avium counts cross-project work — the engineer assigned to one Platform ticket AND two Mobile tickets gets credit for all three.
- Utilization percent = committed / capacity × 100. Avium classifies the result: over (>105%), high (90–105%), healthy (55–90%), under (<55%).
- The Over-Allocation Signal lists every person in the 'over' bucket, sorted by severity. The Avium Intelligence briefing turns that into 'Sarah is at 130%; she has 2 blocking tickets that should move to Mike (currently 60%).'
Who reads this Signal
See over-allocation across your team
Free tier shows you who's over, by how much, and which tickets are driving it. Avium Intelligence (Business) adds the rebalancing suggestion — which person has spare capacity, which tickets to move, and what the result would look like.
Start free — no credit card →