Key Takeaways
- Schedule float is how long an item can slip before it moves the release date. It is an emergent property of the dependency network, not a reserve anyone decided to set aside.
- Because nobody created it, nobody tracks it. Scope creep, late dependencies and capacity changes all bill to float first, and spending float moves no date at all.
- That makes the date a lagging indicator: a plan can absorb three real erosion events and still read green, right up until the fourth one lands with no float left.
- Jira computes no float. Read the number float was standing in for instead: the gap in days between the committed date and the forecast at the confidence level you committed at.
Every item is green. Nothing is flagged, no issue has moved to Blocked, and the burn-up looks the way it looked last week. Then one integration ticket slips four days, and the committed release date slips four days with it.
What nobody can explain in the stand-up is why this four-day slip mattered when the last three did not. The answer is not that this ticket was special. It is that the earlier slips came out of float, and this one had no float left to come out of.
What schedule float actually is
Float in project management is a critical path method idea, and a precise one. Lay out every item as a network of dependencies, do a forward pass for the earliest each can start and a backward pass for the latest each can start without pushing the end date, and the difference between them is that item’s float. Total float is how much it can slip before the whole release moves. Free float is how much it can slip before it pushes the item immediately behind it.
The critical path is simply the chain with zero float. Everything off that chain has some — and the amounts are wildly uneven. One item might carry three weeks. The one next to it might carry a day and a half.
Float is not a buffer, and the difference matters
A contingency reserve is a decision. Somebody sized it, somebody owns it, and spending it is a conversation. Critical chain project management takes that further: strip the safety padding out of individual estimates, pool it into one explicit project buffer, and manage the release by watching that buffer get consumed.
Float is none of those things. Nobody granted it, nobody sized it, and nobody agreed to spend it. It exists because one item happened to need another, and that other one happened to finish on a Wednesday. It is the residue of the plan’s structure — and residue does not come with an owner, a policy, or a burn-down chart.
Which is exactly why it goes first.
The three killers spend float before they spend the date
The confidence vote at the end of planning is expert engineering judgment doing its job. The room prices a plan it understands, at a confidence it is willing to defend in front of a sponsor. What the room almost never knows is how much float that plan contained — and the three things that erode a release date all bill to it first.
Scope creep lands on whichever chain still has slack. A new item goes onto the Fix Version, the work fits, the date holds. Float down, date unchanged.
A dependency surfaced late reroutes a path. A blocking link added in week five turns an item that had eleven days of float into one that has two, without touching a single estimate.
A capacity change does it most politely of all. Resource leveling is the honest version: you smooth an over-allocation by shifting work into slack that was sitting there anyway. Everything still fits. The margin that made it fit is gone.
Three genuine erosion events, no date movement, nothing to escalate. Then the fourth one arrives, moves the date by a week, and it looks like it came out of nowhere.
Jira does not compute float
It is worth being plain about this, because teams keep looking for the number. Jira has no network diagram. There is no predecessor-successor relationship with lag, no forward pass, no backward pass. “Blocks” and “is blocked by” record a relationship, not a schedule model, so there is no total float figure anywhere to read. Tools that draw a Gantt over Jira will draw the bars, but a float number computed from single dates somebody typed in is only ever as good as those dates.
Advanced Release Planning does not hand you a CPM float table, and it does not decide which work matters — that judgment belongs to the team and it should stay there. What it does is run Monte Carlo simulation over the team’s actual throughput and its live Jira issue links, so slack on the blocking chain is priced into the forecast instead of assumed away. Then it reports the number float was always standing in for: the distance in days between your committed date and the forecast at the confidence level you committed at, re-calculated as the work moves. See how dependency state feeds the critical path and the forecast in the docs.
Three habits that make float visible
- Ask the float question on planning day. Not item by item. Once: if the second-longest chain slipped a week, would the date move? If nobody in the room knows, the plan has an unknown amount of margin in it, and the vote priced it blind.
- Treat a narrowing gap as an event. A committed date that has not moved while the 85% date has crept four days closer is a real erosion event that produced no ticket and no flag. That is the moment to renegotiate — not the moment the gap reaches zero.
- Say it in days, out loud. “We absorbed it” is a status. “We absorbed it, and we have six days of margin left instead of eleven” is a decision the room can actually make.
Float is the cheapest thing a release has and the first thing it spends. Keep the plan. Just stop letting it drain in silence.
See how many days of margin your committed date still has, on a live confidence band in Jira.
Leave a Reply
Your email is safe with us.