The capacity review at PI planning was careful. Each engineer said how much of their week would go to the release, the platform lead added up the answers, and the team planned at about 80% resource utilization on release work, with the rest held for support, reviews and meetings. Scope was sized to fit. The team voted four fingers for 5 February.

Four weeks later the utilization report looked even better. The same team was at 96%. Everyone was busy, nobody was idle, and the resource manager mentioned it in the steering meeting as a win. The roadmap still showed 5 February in green.

What resource utilization measures

Resource utilization is the share of a person’s or team’s available time that is spent on work, shown as a percentage. The usual resource utilization formula is hours worked divided by hours available, times 100. Agencies and services firms often split it into billable and total utilization, and commonly aim for around 80%. Below that, capacity sits unused. Above 100%, people burn out and deadlines slip.

The utilization a team plans at the vote is expert engineering judgment. It is the team saying how much of each person’s week the release can count on, after the support rotation, the reviews and the meetings. It is part of the evidence behind the confidence vote, and it belongs there.

Busy is not the same as delivering the release

The 96% in the story hides two things, and neither shows up in the report.

The extra hours went somewhere else. One engineer was lent to another team two days a week. Support escalations grew after a large customer went live. A security patch wave took a sprint. Utilization rose because people were busier, not because the release got more of them. The share of capacity left for the release fell.

Waiting time grows faster than load. Queueing theory has a plain result for any shared resource: as utilization climbs toward 100%, the time work spends waiting rises much faster than the load does. In the simplest queueing model, going from 80% to 90% busy more than doubles the wait, and going to 95% roughly doubles it again. In a delivery team, that wait is the pull request nobody can review, the question nobody has time to answer, the ticket sitting in “ready for test”. A few points of utilization can cost days.

Headcount is unchanged and no issues were added. The board looks active. That is a capacity change, the third of the three things that erode a committed release date. It rarely travels alone: the lent engineer usually carries a dependency back with them, and a busy team is the one that says yes to “just one more small thing”, which is scope.

Keep the utilization plan. Read what a change costs in days.

The answer is not to chase a lower percentage or to stop reporting it. It is to treat the planned figure as an assumption and re-read the date against it.

1. At planning, write down the share of each person’s week the release assumes, and the committed date with the confidence level the team voted at.
2. Base the forecast on a throughput window long enough to include the team’s normal mix of support and interruptions, so the usual level is already in the numbers.
3. When a known change starts (a loan to another team, an extra support week, a patch sprint), record those days as time off against that person’s Jira account before it starts.
4. Read a rising utilization number as a question, not a win: where did the extra hours go?
5. At every sprint boundary, read the gap in days between the committed date and the forecast at the committed confidence.

An illustration, not customer data. A release is committed for 5 February at 85% confidence. At the vote the 85% forecast sits at 2 February: three days of margin. In week two one engineer is lent out two days a week for four weeks, recorded as eight days of time off. Over the next two sprints review and test queues lengthen, and delivered throughput on release work slows. No issues were added. The 85% forecast is now 13 February, eight days past the commitment. The 50% forecast is 4 February, so the release reads amber, not yet red. The utilization report, meanwhile, went up.

Now the conversation has a number on it. End the loan early? Move the patch work to after the release? Trim a Should-have at the cut-line? Renegotiate the date while there is still margin to trade? Every option is the team’s call. What changes is that the call happens in week four, not at the demo.

Where Advanced Release Planning fits

Advanced Release Planning for Jira does not compute or store a resource utilization percentage. It reads the inputs a utilization change actually touches. Time off is recorded per person, per day, against the Jira accounts assigned to the release’s issues, and public-holiday calendars are imported per team, both folded into the Monte Carlo forecast through the Capacity Awareness setting. The forecast is built on the team’s delivered throughput over the throughput window you choose, so the normal level of support and interruption is already reflected; what it surfaces is a change from that level. A known loan or pull-away recorded as time off reaches the forecast directly; longer queues and slower delivery register as later throughput data comes in. Either way the committed date is re-forecast and the shift is reported in days against the 50%, 85% and 95% bands. The team sets the assumptions: which throughput window, whose capacity, what is in scope. The app does the arithmetic at Monte Carlo scale and keeps it live. Green at or above P85, amber between P50 and P85, red below P50.

For the decision that sets who works on the release, see why resource allocation is decided once. For the chart that shows where planned load peaks, see the resource histogram. For exactly what the app reads when capacity changes, see the capacity change tracking reference doc.

Key takeaways

• Resource utilization is the share of available time spent on work, as a percentage: hours worked divided by hours available.
• The utilization a team plans at the vote is expert engineering judgment and part of the evidence behind the confidence vote.
• Utilization can rise while the release gets less capacity, and near 100% waiting time grows faster than load.
• Record known loans and pull-aways as time off, keep the normal level in the throughput window, and read the gap in days at every sprint boundary.

FAQ

What is the resource utilization formula?

Hours spent on work divided by total available hours, times 100. Billable utilization counts only client or revenue work in the top line.

What is a good resource utilization rate?

Services firms commonly target around 80%. For a delivery team, the more useful question is how much of that time goes to the release, and whether the share has changed since the vote.

Does high utilization move a committed release date?

It can. If the extra hours go to work outside the release, or queues lengthen as the team nears 100%, delivered throughput on the release slows and the date moves. Read the shift in days against the confidence level the team committed at.

Keep the team busy. Keep the date honest too. See the committed date and its live confidence band in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio