Engineering Work Mix: Where a Team’s Sprint Actually Goes
Roadmaps are written as if engineering time goes to features. Sprint data usually says otherwise. Work mix shows how a sprint’s work divided between features, bugs, testing, review, technical debt, support, operational work and research — so plans can be built on what the team really does.
- Planned roadmap work 48%
- Added mid-sprint 14%
- Production bugs 22%
- Support & operations 16%
Only 48% of the sprint went to the plan the roadmap assumed.
A team can look slow on the roadmap while half its sprint goes to bugs, support and unplanned work.
What work mix is
Work mix is the share of a sprint’s work in each kind of work. A practical set of categories for product teams:
| Category | Typical Jira signals |
|---|---|
| Feature | Story, Epic, New Feature, Improvement |
| Bug / defect | Bug, Defect, Incident |
| Testing / QA | Test, QA task; testing labels |
| Code review | Review tasks; review labels |
| Technical debt | Tech debt, Refactor, Chore |
| Production support | Support request, Service request; support labels |
| Operational | Ops, Maintenance, Infrastructure tasks |
| Research | Spike, Research, Discovery |
| Other | Anything the mapping does not recognise |
Work mix can be measured two ways: over everything the sprint handled (planned, carried in and added, finished or not) or over completed work only. The first describes where attention went; the second describes what was delivered. Both are useful, and the gap between them is informative.
Why it matters
A team that spends 35% of its sprint on bugs and support has 65% of its capacity for everything else. If the roadmap was planned against 100%, the roadmap was wrong before the sprint began. Work mix makes that visible without anyone having to track hours.
It also explains carryover that looks mysterious. When work mix shifts toward bugs and support for several sprints, feature work carries over even though the team is busy — the busyness went somewhere else. See why work carries over.
And it is one of the few honest ways to talk about technical debt: “technical debt was 4% of work handled for six sprints” is a concrete statement a leadership team can decide to change.
How to calculate it from Jira
- Choose the unit: story points (if the team estimates consistently) or issue counts. Unestimated issues count as zero points, so use issue counts if many bugs and support tickets go unestimated.
- Map each issue to one category. Check labels first (they are the most specific signal), then components, then status, then issue type.
- Sum each category and divide by the total.
Category share = work in category ÷ all work (handled or completed)Make the mapping visible and editable
Every team uses Jira differently. One team’s “Task” is operational work; another’s is a feature sub-task. The mapping must be adjustable, and the share of work that lands in “Other” should be shown: when more than a fifth of work is uncategorised, the mix is incomplete and should be read with care.
Story points understate unplanned work
Bugs and support requests are often unestimated. In points, they count as zero and disappear from the mix. Compare the points view with the issue-count view; if bugs are 8% of points but 25% of issues, the team is doing a lot of small, unestimated reactive work.
How to interpret the mix
- Compare with the plan. If roadmap planning assumes 80% feature work and the mix shows 55%, adjust the roadmap or the mix — deliberately.
- Compare handled with completed. A category that is a large share of handled work but a small share of completed work is carrying over.
- Watch the trend. A bug share rising over several sprints is an early quality signal.
- Count categories, not only shares. A sprint where the team handled seven kinds of work is fragmented even if no single category dominates — see sprint context switching.
There is no ideal mix. A team that owns a critical production system should spend more time on support and operations than a greenfield team. The goal is a mix that is chosen, not one that happens.
Apply this to your team’s delivery
Create a free account, set up your organization and project, then import a Jira CSV. Start with the available evidence; add sprint dates and history for stronger analysis.
Common mistakes
- Counting only completed work. Unfinished bugs and support investigations still consumed the sprint.
- Trusting the default mapping. Review it with the team once; it takes ten minutes and makes every later number more accurate.
- Reading points only. Unestimated reactive work vanishes.
- Comparing teams. Different systems, different mapping habits and different responsibilities make cross-team mix comparisons misleading.
- Turning it into a per-person report. Work mix describes the team’s workload, not anyone’s performance.
What to do with it
- Reserve capacity by category. If bugs and support are consistently 25% of work handled, plan feature work into the remaining 75%.
- Make technical debt explicit. Decide a target share and check it each sprint.
- Reduce the number of categories in flight when carryover persists: batch operational work, rotate support.
- Share it with product partners. A shared view of where capacity goes makes trade-offs easier than arguing about velocity.
Questions to ask
- How much capacity should be reserved for bug fixes?
- Is technical debt getting the share we agreed?
- Which kinds of work are we asking the team to juggle this sprint?
Example
A five-engineer team handled 38 issues in a sprint: 16 features, 9 bugs, 5 support requests, 3 testing tasks, 2 reviews, 2 operational tasks and 1 spike. By issue count, features were 42%, bugs 24% and support 13%. By points, features were 71% — because most bugs and all support requests were unestimated.
The roadmap assumed 80% feature capacity. The team agreed to plan feature work to 60% of median throughput and to estimate bugs at triage so the points view stopped hiding them.
Related metrics and how the Workload & Carryover report helps
See it on your own data in the Workload & carryover report.
Related: engineering interrupt load, planned vs unplanned work, sprint context switching and engineering capacity planning.
The Workload & Carryover report shows work mix for handled or completed work, in points or issues, lets you edit the category mapping (saved only in your browser), and flags when too much work is in “Other” for the mix to be trusted.
Frequently asked questions
- What is a healthy engineering work mix?
- There is no universal ideal. It depends on what the team owns. The healthy version is a mix the team and its leaders chose and plan around, rather than one discovered after the sprint.
- Should work mix be measured in story points or issues?
- Both. Points show where estimated effort went; issue counts reveal small, unestimated reactive work such as bugs and support that points hide.
Related guides
Interrupt load
How to measure engineering interrupt load from Jira — work added after sprint start as a share of all work handled — why not every addition is an interruption, and how to plan around it.
Sprint context switching
How to see context switching in sprint data without time tracking: work categories per sprint and per engineer, added work and existing WIP as indicators of fragmentation — and the limits of what Jira can show.
Planned vs unplanned work
How to measure planned vs unplanned engineering work from Jira by when work entered the sprint — not by issue type — why bugs are not automatically unplanned, and how to reserve capacity for unplanned work.
Why work carries over
The six recurring reasons work carries over between sprints — overcommitment, interruptions, WIP accumulation, testing and review queues, fragmentation — and how to tell them apart with Jira data.