The constraint was written down before anyone voted. One performance engineer, shared with the payments team, available to this release two days a week. It sat in the planning notes under Resources, next to the test environment that had to be booked a sprint ahead. The team talked it through, sequenced the load-test stories around those two days and voted four fingers on the commitment with the constraint in plain view.
In sprint 4, payments had an incident. The two days became zero for three weeks. The planning notes still said two days a week. Nothing in them said what three weeks of zero had done to the date.
What resource constraints are
Resource constraints are limits on what a project can draw on to deliver: people, skills, time, budget and equipment. In software delivery they usually look like this:
- People and headcount: how many engineers are on the release, and for how much of their week.
- Specialist skills: the one person who knows the billing module, the shared security reviewer, the performance engineer split across teams.
- Time: holidays, planned leave and fixed windows such as a code freeze or a change-board slot.
- Environments and equipment: a staging environment several teams book, a device lab, a licence count.
- Budget: what limits how many of the above you can add.
Capacity constraints are the same idea seen from the team’s side: the amount of work the team can actually complete in a period, given those limits. The standard responses are well known. Resource leveling moves work to fit the people available. Critical path analysis shows which constrained work sits on the longest chain. Prioritization decides what waits.
The constraint goes into the vote
When a team commits to a release date, the confidence vote is expert engineering judgment. The engineers in the room know which resource is scarce, who is shared, which environment is contested and how they plan to work around each. They price those resource constraints into the commitment, along with scope and the dependencies they can see. On the day of the vote, that judgment is the best information anyone has.
The trouble starts after the vote. The constraint list stays the same. The state of each constraint does not:
- A shared specialist gets pulled away. Another team’s incident or deadline takes the days your release was counting on.
- A soft constraint becomes binding. The reviewer who “can usually fit it in” stops fitting it in, and work queues behind them.
- Planned availability turns into unplanned absence. Illness, a resignation or a mid-increment reassignment removes capacity the vote assumed.
That is capacity change, the third of the three things that erode a committed release date. It rarely travels alone. When the constrained person is away, the work that needs them often becomes a blocker for someone else, and the scope they were meant to finish stays open.
Why a constraint list can’t tell you how late you are
Teams record resource constraints in planning notes, a RAID log, a capacity spreadsheet or a resource plan. Each says which resource is limited and by how much. None of them says what a change to that limit costs the committed date, because the cost depends on things the list does not hold: how much in-scope work needs the constrained resource, how fast the rest of the team is actually delivering, and how much room is left between the forecast and the commitment.
So a line that reads “performance engineer, 2 days/week, shared” is accurate in sprint 1 and misleading in sprint 5, and it looks exactly the same in both. This is the same gap described in capacity risk and in resource leveling: the constraint is known. Its price in days is not.
Read the constraint in days
Advanced Release Planning for Jira keeps the committed date next to a live forecast. Monte Carlo simulation runs on your team’s own Jira throughput and draws a 50/85/95% confidence band around the release. The team still owns the assumptions: which throughput window is representative, whose capacity counts, what is in scope. The app does the arithmetic at a scale no planning meeting can, and keeps it current.
For resource constraints, it works from inputs you already keep:
- Time off recorded per person, per day, against the Jira accounts assigned to the work, plus public-holiday calendars per team. Planned absences are folded into the forecast up front.
- Delivered throughput. When a shared specialist is pulled away or a reviewer becomes a bottleneck, completed work slows, and the forecast reflects it without a separate input.
- The committed date and its confidence line. When capacity changes, the date is re-forecast and the shift is reported in days against P50, P85 and P95.
An illustration, not customer data: a release committed for 12 December at P85. The performance engineer’s three weeks of zero show up as slower completion on the load-test stories and the work that waits on them. The forecast now puts P85 six days after the committed date, and the release moves from green to amber. That is the cue to act while there are options: ask payments for one protected day a week, bring in a second person for the load tests, move a story below the MoSCoW cut-line, or re-commit to a new date with its confidence stated.
Keep the list. Add the price.
Naming resource constraints at planning is good practice, and it belongs in the vote. What the list cannot do is notice when a constraint tightens. Record time off against the Jira accounts doing the work, keep your constraint list if it helps, and let the forecast say what each change costs the committed date this week. The capacity change reference doc lists what the app reads and what it does not.
Key takeaways
- Resource constraints are limits on people, skills, time, environments and budget. Capacity constraints are what those limits leave the team able to deliver.
- The constraint list is fixed at planning. A shared person pulled away, or a soft limit turning hard, is what moves the committed date.
- A live forecast reads recorded time off and delivered throughput in Jira and reports the shift in days against the 50/85/95% band.
FAQ
What are examples of resource constraints? A specialist shared between teams, a fixed headcount, planned leave and public holidays, a contested test environment, and a budget that caps hiring or contractors.
Does Advanced Release Planning manage resources for us? No. It is not a resource-management or HR system and does not assign people or store a resource plan. It reads the Jira accounts on the work, the time off recorded against them and the team’s delivered throughput, and reports what changes in those cost the committed date.
Put a number on the next constraint
Before the next shared specialist disappears for a sprint, see what it would cost your committed date. See the committed date and its live confidence band in Advanced Release Planning, or try it on your own Jira data from the Atlassian Marketplace.
1 Comment
Leave your reply.