The availability check before PI planning took most of an afternoon. The delivery lead went down the roster with every engineer: booked leave, conference days, the on-call weeks, the two public holidays inside the increment. The answers went into a sheet, the sheet became a number of person-days, and scope was sized to fit it. The team voted four fingers for 12 March.

Three weeks later the sheet was still correct about everything it had recorded. It just no longer described the team. A two-week family leave had been approved after the vote. The new contractors in Kraków came with a holiday calendar nobody had loaded. A senior engineer had handed in her notice, with her last day before the release. The roadmap still showed 12 March in green.

What resource availability means

Resource availability is the time, capacity and people a piece of work can actually count on, and when. In resource availability in project management, it usually lives in a roster or resource calendar: who is on the work, how much of their week, which days they are out, which holidays apply. Some teams reduce it to a ratio of available resources to required resources, expressed as a percentage.

The availability a team confirms at the vote is expert engineering judgment. The people in the room know who is stretched, who is about to go on leave and which holidays fall where. That knowledge is part of the evidence behind the confidence vote, and nothing in this article replaces it.

Availability is confirmed once. It changes every week.

The sheet captures availability on planning day. After the vote, availability keeps moving in small, ordinary ways:

• Leave approved after the vote. Each request is reasonable. Together they remove specific people on specific days, often in the same fortnight.
• New people, new calendars. A contractor team or a new region brings public holidays that were never in the plan.
• Departures and arrivals. A resignation removes a person. A new hire adds a name long before they add throughput.
• Loans and pull-aways. Someone is lent to another team for a sprint, or pulled into an escalation.

None of these adds an issue to the release. The board looks the same. That is a capacity change, the third of the three things that erode a committed release date. It rarely travels alone: an engineer who leaves takes knowledge another team was waiting on, which turns into a dependency, and a team short on people is the one that accepts a small extra ask without re-checking the date, which is scope.

The availability sheet is rarely re-read against the date. When it is, it answers the question it was built for: how many person-days do we have? It does not answer the one that matters after the vote: what does this change cost the committed date, in days?

Keep the availability check. Read the date against it.

The answer is not a longer sheet or a stricter leave policy. It is to treat confirmed availability as an assumption and re-read the date whenever it changes.

1. At planning, write the committed date and the confidence level the team voted at next to the availability you confirmed.
2. Record leave per person, per day, against the account doing the work, not as a blanket percentage for the whole team.
3. Load each team’s public-holiday calendar, including teams that join after the vote.
4. When availability changes, record it before it takes effect, then read the re-forecast.
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 12 March at 85% confidence. At the vote the 85% forecast sits at 9 March: three days of margin. After the vote, ten days of approved leave are recorded for one engineer, the Kraków holiday calendar is loaded and removes two working days for three people, and the departing engineer’s days after her last day are recorded as time off. No issues were added. The 85% forecast is now 17 March, five days past the commitment. The 50% forecast is 10 March, so the release reads amber, not yet red.

Now the conversation has a number on it. Bring the handover forward? Move a Should-have past the cut-line? Ask another team for a reviewer for two weeks? Renegotiate the date while there is still margin to trade? Every option is the team’s call. What changes is that the call happens the week availability moved, not at the demo.

Where Advanced Release Planning fits

Advanced Release Planning for Jira reads resource availability at the source. Time off is recorded per person, per day, against the Jira accounts assigned to the release’s issues, so availability drops only on the days someone is away. Public holidays can be imported in bulk from a CSV and applied per team, and teams in different countries can carry different calendars at the same time. Working days are calendar days minus weekends, applicable holidays and individual time off, folded into the Monte Carlo forecast through the Capacity Awareness setting. The forecast is built on the team’s delivered throughput, so a change nobody recorded, such as a slow ramp-up, still registers as later 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. The app does not store allocation percentages or skills, and it is not an HR system.

For the document many teams fill in at the vote, see why the capacity planning template records who was available. For how leave and holidays bend the forecast from day one, see the silent schedule killer: PTO and public holidays. For exactly what the app reads, see the PTO and holidays reference doc.

Key takeaways

• Resource availability is the time and people a piece of work can count on, and when.
• The availability a team confirms at the vote is expert engineering judgment and part of the evidence behind the confidence vote.
• Availability changes after the vote through leave, new calendars, departures and loans, usually without a single issue being added.
• Record each change per person, per day, before it takes effect, and read the gap in days at every sprint boundary.

FAQ

What is resource availability in project management?

The people, time and equipment a project can actually use, and when. For a software team it is mostly who is working on the release on which days, after leave, holidays and other commitments.

How do you track resource availability?

Record time off per person and per day against the accounts doing the work, load each team’s holiday calendar, and record loans and departures when they are agreed, not when they start.

Does a change in availability move a committed release date?

Often, yes. Whether it does, and by how many days, depends on who is out and when. Read the shift in days against the confidence level the team committed at.

Confirm availability at the vote. Keep the date honest after it. 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