Resource Utilization in Jira: How to Measure It, and What "Good" Looks Like

Utilization Reports ActivityTimeline
In this article
What is resource utilization?
How do you calculate resource utilization?
What is a good resource utilization rate?
Can Jira measure resource utilization on its own?
How to measure resource utilization in Jira with ActivityTimeline
How do you improve a low utilization number?
TL;DR
  • Resource utilization = (hours worked ÷ available hours) × 100. For planning ahead, swap logged hours for scheduled hours.
  • For delivery and services teams, 70–85% is the healthy band. Around 80% billable utilization is the most common target. Sustained 100% is a planning failure, not a win.
  • Billable utilization only counts client work. Overall utilization counts everything. Compare each against its own target, never against each other.
  • Native Jira stores the raw ingredients (worklogs, estimates) but has no concept of a person's available capacity, so it can't produce the percentage. Teams add an app like ActivityTimeline for the report itself.

Someone in a quarterly review asks, "So what's our utilization?" And suddenly three people are looking at three different spreadsheets that don't agree with each other, and the honest answer is somewhere between "about 75%, probably" and a shrug. It's one of the most common situations customers describe to us when they first reach out. Jira knows who logged what and when. It just won't tell you the percentage.

This guide covers the part the spreadsheets keep getting wrong: what utilization actually is, how to calculate it honestly, what number you should be aiming for, and how to get that number out of Jira without exporting anything.

What is resource utilization?

Resource utilization is the percentage of a person’s or team’s available working hours spent on actual project work, usually calculated as hours worked or scheduled ÷ available hours × 100. If a developer has 40 available hours this week and 32 of them are spent on, or scheduled for, real tasks, their utilization is 80%. For resource managers, delivery leads, professional services teams, and anyone responsible for tracking utilization in Jira, it’s a headline KPI because it shows whether paid capacity is being used well, flags overbooking and idle time early, and affects delivery quality, team health, and revenue.

Here’s the distinction most guides skip, and the one that causes most of the spreadsheet arguments: utilization has two directions.

Looking backward, utilization is logged hours divided by available hours. It tells you whether the time you had actually went into the work. This is the number finance asks about.

Looking forward, utilization is scheduled hours divided by available capacity. It tells you whether you’re about to run out of people three weeks from now, while you can still do something about it.

Both are legitimately called “utilization.” They answer different questions, they come from different data (worklogs vs. estimates and bookings), and they should be tracked separately. When two people quote different utilization numbers for the same team, this split is usually why. From there, the rest is deciding what a good utilization rate looks like, how billable utilization differs from overall utilization, where Jira’s native reporting falls short, how to measure both views with ActivityTimeline, and what to change to improve the number without breaking the team.

The two directions of resource utilization

How do you calculate resource utilization?

The formula is simple: resource utilization = (hours worked ÷ available hours) × 100. A developer who logs 32 hours of project work in a week where they had 40 available hours is at 32 ÷ 40 × 100 = 80% utilization. For forecasting, the same formula uses scheduled hours instead of logged ones: scheduled hours ÷ available capacity × 100.

The formula is the easy part. Two refinements decide whether your number means anything.

First: available hours are not contract hours. A 40-hour contract with one public holiday in the week means 32 available hours, not 40. Subtract vacations, holidays, sick leave, and part-time schedules before you divide. This is where most homemade spreadsheets quietly break: they divide by 40 for everyone, every week, and then nobody understands why the numbers never reconcile with reality. The person who took Friday off didn't have 40 hours. Pretending they did makes them look underutilized when they were actually fully booked.

Second: decide what counts as the "work" on top. If you count every logged hour, you get overall utilization. If you count only client-facing, chargeable hours, you get billable utilization: billable hours ÷ available hours × 100. Internal meetings, training, admin, and the weekly all-hands are real work, but they're non-billable, and for a services business the billable number is the one that connects to revenue. A consultant with 34 billable hours out of 40 available is at 85% billable utilization, even if their overall utilization is closer to 100%.

Get those two things right (honest availability on the bottom, a clear definition on top) and the rest is arithmetic.

What is a good resource utilization rate?

For delivery and professional-services teams, 70–85% is the healthy band, and around 80% is the most commonly cited target for billable utilization. Sustained 100% is not a stretch goal; it's a planning failure that just hasn't presented its invoice yet. Below roughly 50%, something is broken in either demand or scheduling.

Why not 100%? Because a Jira team's week contains work nobody scheduled: the production bug, the support escalation, the estimate that was off by a day, the meeting that appeared on Tuesday. A plan with zero slack doesn't absorb any of that; it just converts it into overtime. And people who run at 100% for months ship worse work and eventually leave, which is the most expensive utilization problem there is.

Why not relax at 60%? Because at that point you're paying for hours that go nowhere in particular, and you usually can't say where. That's not a people problem, it's a visibility problem, and it's fixable (more on that below).For honest context, industry benchmark research from SPI, reported by Deltek, found that professional-services firms averaged 68.9% utilization in 2024, after three straight years of decline. So if your first real measurement lands below 70%, you're not an outlier. You're average. The interesting question isn't "why is it low?" but "where do the missing hours actually go?" And you can't answer that until you categorize non-billable time.

One more nuance, because this trips up teams comparing numbers across tools: the right target depends on which utilization you're looking at. A scheduled-capacity target can sit higher than a billable target, because scheduled utilization includes legitimate non-billable work. In our own planning guidance we suggest scheduling toward roughly 90% of a team's capacity, keeping about a 10% buffer for the unplanned. That 90% is a scheduling target. It doesn't contradict the ~80% billable target; they're measuring different things. Put them side by side as if they were the same metric and you'll conclude your team is simultaneously overbooked and underperforming, which helps nobody.

MetricFormulaHealthy range
Overall utilization (backward)logged hours ÷ available hours × 100~70–85%
Billable utilization (backward)billable hours ÷ available hours × 100~70–85%, target ~80%
Scheduled utilization (forward)scheduled hours ÷ available capacity × 100up to ~90%, keep a ~10% buffer

Can Jira measure resource utilization on its own?

Honestly, no. And it's worth being precise about why, because Jira is strong for project management and task management and does hold most of the raw ingredients. Native Jira gives you worklogs (who logged what, on which issue, when), original and remaining estimates, and per-project time reports. That's the numerator of the utilization formula, sitting right there, but Jira is weak at tracking resource utilization because it lacks resource availability and resource capacity data for individual team members.

What Jira has no concept of is the denominator. There's no field anywhere in Jira for a person's available capacity: no working schedules, no vacations, no public holidays, no part-time arrangements. It also can't aggregate time across multiple projects into a per-person view, doesn't distinguish billable from non-billable work, and doesn't display a utilization percentage anywhere in the product. That means project managers and resource managers can't calculate resource utilization rate or produce resource utilization metrics from native data alone.

So the standard workaround appears: export worklogs to a spreadsheet, maintain availability by hand in a second tab, and rebuild the formulas every time someone joins, leaves, or books a holiday. It works for about a month. Spreadsheets also struggle to preserve planned utilization versus actual utilization, surface utilization trends, or show reliable workload distribution for active projects. Then the spreadsheet drifts from reality, people stop trusting the number, and the KPI quietly dies until the next quarterly review resurrects it.

To be fair to Jira: it was built to track issues, and it tracks them well. Utilization is a people-and-capacity question, and that's simply a different data model. Which is why teams that need the number usually add project management tools or resource management software as a dedicated resource utilization tool and resource utilization software to improve resource utilization, support efficient resource allocation, and plan future projects.

How to measure resource utilization in Jira with ActivityTimeline

ActivityTimeline is our resource-planning and tracking app for Jira. It syncs with your Jira data and adds the missing half of the formula: per-person capacity with schedules, vacations, and holidays built in. That means it can produce both directions of utilization, backward from worklogs and forward from what's scheduled, without anything leaving Jira for a spreadsheet.

Looking backward: utilization from logged work

The backward-looking number comes from timesheets. ActivityTimeline's timesheet reports collect logged hours per person and per team against their real availability for the period, creating a resource utilization report from utilization data in timesheets, so the utilization percentage reflects who was actually there. Reports can be grouped by worklog category, which is what makes the billable split visible (more on that in a moment), and exported to Excel when finance wants the file.

The honesty check on top of that is the Planned vs. Actual report, which provides valuable insights to help teams manage utilization and improve project estimates: planned hours next to logged hours, per person or per team, for any period. It helps project managers and resource managers compare planned utilization with actual utilization for individual team members and teams. If the plan said 36 hours and the worklogs say 41, that gap is your unplanned work made visible. Teams that watch this one report for a few sprints usually stop arguing about whether estimates are "wrong" and start seeing where reality consistently diverges from the plan.
Planned vs. Actual chart

Looking forward: scheduled utilization and forecast

The forward-looking number comes from what's on the timeline. The Resource Utilization Forecast shows each person's utilization rate week by week: the percentage of their available hours already allocated to scheduled tasks, bookings, and events, which supports resource scheduling across multiple projects by showing resource availability and resource capacity week by week. You can filter it by project or any Jira filter, display it in hours or percentages, and break it down by Project, Epic, or a custom field.

That forward view helps maintain utilization at more optimal utilization rates before overload happens.

The point of this report is timing. An overloaded week that surfaces three weeks in advance is a scheduling conversation. The same week discovered on Monday morning is an apology.
Resource Utilization Forecast in percentage view, showing week-by-week utilization per person for the next six weeks
For the team-level view, the Team Utilization Forecast rolls the same logic up: total available capacity per team, utilized capacity, the resulting utilization rate, and a per-project breakdown so you can see not just that a team is at 95%, but which project is consuming the hours. That rollup also helps with workload distribution across active projects and planning future projects.
Team Utilization Forecast
You can read more on resource utilization in our specific case scenario on planning capacity for the next quarter.

The at-a-glance layer: charts and dashboards

For the recurring "how are we doing?" question, two charts do most of the work.

The Team Capacity Chart shows total available capacity (the sum of individual capacities, minus non-working time like days off and holidays, plus any overtime), utilized capacity (from remaining estimates, daily estimates, or story points on assigned tasks, plus bookings, placeholders, and calendar events), the remaining capacity, and the utilization rate as a percentage, broken down week by week or month by month. Together, these act as resource utilization metrics that help teams spot utilization trends. A real example from one of our own walkthroughs: a team that had utilized 580.8 of 880 available hours for the month, roughly two-thirds, with close to 300 hours still open for new work. That works as a practical resource utilization example for team-level capacity decisions. That's a hiring conversation and a sales conversation in one screenshot.
Team Capacity Chart showing available vs. utilized vs. remaining capacity per week, with the utilization rate percentage and the smart legend
The Team Utilization Pie Chart answers a different question: where does the time go? It splits a team's hours across projects, either backward (from worklogs, bookings, and calendar events) or forward (from estimates, bookings, and placeholders). One honest caveat, and it's one we put in our own documentation: the pie chart shows time distribution, not efficiency. A team can spend 50% of its hours on the website project and still be badly utilized. For the efficiency question, use Planned vs. Actual.
Team Utilization Pie Chart showing a team's time split across four projects in percentages
All of these charts also run as Jira dashboard gadgets with caching and configurable auto-refresh, so a dashboard view gives project managersvaluable insights into project resources and resource usage, and the utilization number can live on the same dashboard as everything else your team already checks.
A Jira dashboard with the Team Capacity Chart and Team Utilization Pie Chart added as gadgets

Splitting billable from non-billable

Worklog categories are what turn "utilization" into "billable utilization." ActivityTimeline ships with Billable and Non-Billable out of the box; you can rename them or add your own, and set a default category per project so that, say, everything logged in an internal project lands as Non-Billable automatically. This reduces manual errors on non billable tasks and gives you cleaner utilization tracking. Time logged natively in Jira arrives as Billable by default, and a "~" prefix in the worklog comment flags it Non-Billable instead. Small mechanism, but it means the billable split doesn't depend on anyone remembering a second tool.
the Log Work dialog in Jira with the worklog category dropdown open, showing Billable and Non-Billable options
When you need more detail than a category, worklog attributes add custom fields to every worklog: Cost Center, Client Name, Location, whatever your reporting needs. Attributes can be required, optional, or hidden, and if your team is coming from Tempo Timesheets, existing Tempo attributes can be imported directly rather than rebuilt by hand, while automating repetitive reporting fields can significantly improve resource utilization by reducing admin overhead.

How do you improve a low utilization number?

Carefully, and in this order. Because effective resource utilization is really about how to improve resource utilization without making everyone look busier, and that fixes the chart while breaking the team.
  • Fix the availability data first. If holidays, vacations, and part-time schedules aren't in the system, every utilization number downstream is fiction. This one step alone usually moves the reported number several points, because people who were "underutilized" turn out to have been on leave.
  • Categorize before you cut. A team at 65% isn't lazy; its hours are going somewhere you can't see. Mark non-billable work honestly for a month before deciding anything. Tracking non billable utilization separately from revenue generating work is what reveals where time really goes. Often the finding is 20% of capacity going to internal ceremonies, and that's a calendar decision, not a performance one.
  • Rebalance across teams, not within them. The overloaded team and the underutilized one usually exist in the same company at the same time. Cross-team visibility is what lets you move work sideways instead of pressuring the busy team to somehow log more, which leads to more efficient resource allocation, better workload distribution, and more proper utilization.
  • Use the forecast to fill gaps ahead, not to punish gaps behind. Last month's 68% already happened. Next month's 68% is still negotiable, if you can see it coming.
  • Set the target per metric. ~80% billable, up to ~90% scheduled, and say so out loud, so nobody quietly chases 100% of anything. Resource utilization vs capacity utilization is a useful distinction here, because they are related metrics but not interchangeable.
A resource utilization plan helps teams manage utilization consistently across future projects.

After a few cycles of this, teams usually notice the same thing we did: a utilization report never made anyone work more. It shows you where the plan and reality disagree, and that disagreement is where the fixable problems live.

If your utilization number currently lives in a spreadsheet that one person maintains and nobody quite trusts, ActivityTimeline has a 30-day trial.
Connect it to your real Jira data, build the utilization report, and see whether the number survives contact with reality before paying anything.

Frequently Asked Questions

What's the difference between resource utilization and resource allocation?
Allocation is the assignment: which people go to which projects, and for how many hours. Utilization is the measurement: what percentage of their available time that assigned (or logged) work actually fills. You allocate first, then utilization tells you whether the allocation was realistic. Bad utilization numbers are usually allocation problems wearing a disguise. Allocation decisions should also reflect resource capacity and resource availability, especially across multiple projects.
What's the difference between utilization and billable utilization?
Overall utilization counts every hour of real work, including internal meetings, training, and admin as non-billable tasks. Billable utilization counts only client-facing, chargeable hours. A person can sit at 95% overall and 60% billable at the same time. Track both, compare each against its own target, and never quote one as if it were the other.
Is 100% resource utilization good?
No. A schedule with zero slack has no room for bugs, support interrupts, or estimates that miss by a day, so unplanned work becomes overtime by default. Sustained 100% reliably leads to slipped plans and burned-out people. Aim for roughly 80% billable, and keep about a 10% buffer even in scheduling.
How often should you review utilization?
Weekly for the forward-looking forecast, because next week's overload is still fixable. Monthly for backward-looking actuals, because trends matter more than any single week. Monthly reviews also help spot utilization trends and support planning for future projects. Reviewing actuals more often than monthly mostly generates noise and tempts people to manage the metric instead of the work.
Ready to try capacity management add-on?
Free 30-day trial
No credit card required
Cancel anytime

Related Articles