The resource histogram in the planning deck looked fine. There had been one spike, in sprint 4, where the two QA engineers were booked at 130% of their available hours, and the team had already flattened it: regression testing moved a sprint earlier, one exploratory test pass pushed to the hardening week. Every bar sat under the red line. The confidence vote came in at four fingers.
Three weeks later, one of the QA engineers was pulled onto a production incident for eight working days. Nobody regenerated the histogram. If they had, it would have shown the sprint 4 bar back at 160%. It still would not have said the release was four days late.
What a resource histogram is for
A resource histogram is a bar chart of resource demand over time. Each bar is a period (a day, a week, a sprint), and its height is the hours or headcount scheduled for a person or role in that period. A horizontal line marks available capacity. Bars above the line are overallocation; bars far below it are idle time. You will also see it called a resource loading chart, and in classic project management it is the usual input to resource leveling and resource smoothing.
Used well, it earns its place in planning. It makes an overload visible weeks before it happens, and it gives the team something concrete to reshuffle. Deciding which peak is real, which is a paperwork artifact, and which one the team can absorb is engineering judgment. That judgment goes straight into the confidence vote.
A snapshot, in the wrong unit
The resource histogram has two limits once the vote is over.
It is drawn from the assignments known on planning day. After the vote, people get reassigned, someone is out sick for a week, an incident eats a sprint, a new hire is still ramping up. The real bars move. The chart in the deck does not.
Even redrawn, it speaks in hours, not days. A bar at 160% in sprint 4 might cost the release nothing if that work has slack around it, or a week if it sits on the critical path. The histogram cannot tell the difference. And a histogram can stay flat while the date slips, because it plots scheduled hours, not delivered work. A review queue, a module that has become slow to change, or interrupt work nobody assigned never shows up as a bar.
That is capacity change, the third of the three things that erode a committed release date. The other two, scope creep and dependencies surfaced too late, tend to land on the same people. The QA bar is often where new scope shows up first.
Keep the histogram. Read capacity in days.
The fix is not a better chart. It is keeping the inputs live and reading them against the date.
- Use the histogram at planning for what it is good at: find the peaks, level or smooth them, and let the team decide what is real. Record the committed date with the confidence level the team voted at.
- Record capacity at the source, not in the chart. Time off goes against each person, per day, on the Jira accounts doing the work, and public holidays come from a calendar per team. A reassignment you know about is a time-off entry, not a note in a deck.
- Let delivered throughput carry what the histogram cannot see: interrupt work, review queues, slow drift.
- At every sprint boundary, read one number: the gap in days between the committed date and the forecast at the confidence the team committed at.
An illustration, not customer data. A release is committed for 6 March at 85% confidence. At the vote, the 85% forecast sat at 3 March: three days of margin. In week three the QA reassignment is recorded as eight days of time off. The 85% forecast moves to 10 March, four days past the commitment. The 50% forecast is 4 March, so the release reads amber (attention), not yet red.
Now the sprint review has a decision with a number on it. Borrow a tester from another team for sprint 4? Take the deferred exploratory pass out of this release? Renegotiate the date with the business now, while there is still margin to trade? Each option is the team’s call, and so is every assumption behind the forecast. What changes is that they make the call in week three, not at the release demo.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not draw a resource histogram, and it is not a resource-management system: it does not model skills or allocation percentages. It reads what the histogram is built from, at the source: time off recorded per person, per day, against the Jira accounts assigned to issues; holiday calendars per team; and the team’s delivered throughput and work in progress. The Capacity Awareness setting folds these into a Monte Carlo forecast. When availability changes, the committed date is re-forecast and the shift is reported in days. The committed date carries its confidence band (50%, 85%, 95%) and stays current as scope, dependencies and capacity move. 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.
If the histogram has already pushed you into reshuffling, see what resource leveling does to the committed date. If you keep a written plan alongside the chart, see what each field of a capacity planning template should reference. For the full list of what the app reads and what it does not, see the capacity change reference doc.
Key takeaways
- A resource histogram shows scheduled load against available capacity over time. It is a good planning tool and a fair input to the confidence vote.
- After the vote it is a snapshot: reassignments, absences and unplanned work move the real bars, not the chart.
- Even redrawn, it reports hours over a line, not days against the committed date, and it can stay flat while the date slips.
- Record capacity at the source in Jira and read the gap in days at the committed confidence at every sprint boundary.
FAQ
What is a resource histogram in project management?
A bar chart showing how many hours or people are scheduled for a resource in each period, usually drawn against a line for available capacity, so overallocation and idle time are visible at a glance.
How is a resource histogram different from resource leveling?
The histogram shows where the load is too high or too low. Resource leveling is what you do about it: delaying or reassigning work to remove the overallocation, which can move the dates.
Does a flat resource histogram mean the release is on track?
No. It means the scheduled hours fit. Delivered work can still fall behind through interrupt work, review queues or slower progress, none of which appear as bars. Check the forecast at the committed confidence, in days.
Keep your resource histogram. Add the number it is missing. See the committed date and its live confidence band in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
1 Comment
Leave your reply.