Engineering Time Allocation Sankey Diagram: Team Capacity
Show where a sprint's engineer-days go: from teams to feature work, bug fixes, tech debt, meetings and on-call, then to planned and unplanned work. Replace the sample days with your own.
An engineering capacity Sankey shows where a team's days really went. It separates the work that was planned from the work that arrived, so unplanned work stops hiding inside a velocity number.
The example has 150 engineer-days in one sprint, from three teams. They go to five kinds of work: features, bug fixes, tech debt, reviews and meetings, and support and on-call. The last column splits the same days into planned and unplanned, so a bug that came in during the sprint and a feature that was committed at planning read differently.
Most trackers can tell you a team's points. They cannot easily show that the Platform team spent 24 of its 40 days on tech debt and on-call. The diagram is for conversation, not for rating people: the days are estimates, and one person's day can be split across kinds of work. See /sankey/roadmap-delivery for what the planned work became.
How to read this diagram
- Of 150 engineer-days, 98 (65%) were planned and 52 (35%) were not.
- Feature work is 55 days (37%); 50 were planned and 5 arrived mid-sprint.
- All 25 bug-fix days and 20 on-call days were unplanned: 45 days, 30% of capacity.
- Platform spent 24 of its 40 days (60%) on tech debt and on-call.
The data behind it
Invented figures for illustration. Not data about any real company, team or system.
| From | To | Amount (engineer-days) |
|---|---|---|
| Platform team | Feature work | 8 |
| Platform team | Tech debt | 12 |
| Platform team | Reviews and meetings | 8 |
| Platform team | Support and on-call | 12 |
| Product A team | Feature work | 30 |
| Product A team | Bug fixes | 12 |
| Product A team | Tech debt | 5 |
| Product A team | Reviews and meetings | 13 |
| Product B team | Feature work | 17 |
| Product B team | Bug fixes | 13 |
| Product B team | Tech debt | 3 |
| Product B team | Reviews and meetings | 9 |
| Product B team | Support and on-call | 8 |
| Feature work | Planned at sprint start | 50 |
| Feature work | Unplanned | 5 |
| Bug fixes | Unplanned | 25 |
| Tech debt | Planned at sprint start | 18 |
| Tech debt | Unplanned | 2 |
| Reviews and meetings | Planned at sprint start | 30 |
| Support and on-call | Unplanned | 20 |
The same data as CSV
source,target,value
Platform team,Feature work,8
Platform team,Tech debt,12
Platform team,Reviews and meetings,8
Platform team,Support and on-call,12
Product A team,Feature work,30
Product A team,Bug fixes,12
Product A team,Tech debt,5
Product A team,Reviews and meetings,13
Product B team,Feature work,17
Product B team,Bug fixes,13
Product B team,Tech debt,3
Product B team,Reviews and meetings,9
Product B team,Support and on-call,8
Feature work,Planned at sprint start,50
Feature work,Unplanned,5
Bug fixes,Unplanned,25
Tech debt,Planned at sprint start,18
Tech debt,Unplanned,2
Reviews and meetings,Planned at sprint start,30
Support and on-call,Unplanned,20How it works
Choose one period
Take one sprint or one month, and list the engineer-days available after holidays and leave.
Group work into five or six kinds
Use the labels your tracker already has, such as feature, bug, debt and support. More than six makes the middle column unreadable.
Count each day once
Estimate the days per team and kind of work, then mark which were in the sprint plan.
Check the balance
Each kind of work must leave as many days as entered, and the total must equal the capacity.
Frequently asked questions
Is this a measure of productivity?
No. It shows where the time went, not how well it was used. Use it to discuss the plan, such as why a third of capacity is unplanned, not to compare people.
How do I count a day split across two kinds of work?
Split it in the data: half a day to each. Keep the same rule every period so the charts stay comparable.
Edit this engineering time Sankey
Open the example as your own chart and enter your team's days.