The plan had two small numbers in it that nobody argued about. Integration could start two days before the payments API was finished, because the contract was agreed. And security review would take three days after the feature froze, because it usually did. The team voted four fingers on 19 June and went back to work.
Three weeks later the API contract changed, so integration waited for the API to be done. The review queue was full, so three days became seven. Neither change was a new task. Neither showed up as scope. The release was five days past its committed date, and the schedule still showed a two-day lead and a three-day lag.
What leads and lags are
Leads and lags are the time adjustments a planner puts on a dependency. A lead lets the successor start before its predecessor finishes: build the integration while the API is still being completed. A lag is a wait the plan requires between two pieces of work: three days of security review after code freeze, 48 hours of soak time in staging, a vendor’s five-day certification turnaround. In a precedence diagram, a lead is often written as a negative lag on the arrow.
Setting them is expert engineering judgment. A lead says “we know this interface well enough to overlap.” A lag says “we know this gate takes time and we are not going to pretend it doesn’t.” Both make the plan more honest, and both are part of the evidence the team weighs when it casts its confidence vote.
Bets on time that nobody re-prices
The trouble is what happens to those numbers after the vote. A lead or lag is written once, on an arrow, and then it is treated as a fact.
Leads fail quietly. An overlap depends on the predecessor staying stable. When the interface shifts, the successor has to wait for it to finish. The start-to-start-with-overlap the team planned becomes a finish-to-start, and the two days the lead saved are gone. Nobody files a ticket for that.
Lags stretch. A wait is usually someone else’s queue: a review board, a compliance sign-off, a partner’s release window. Three days was true on the day it was written. It is not refreshed when the queue gets longer.
Neither looks like work. A failed lead or a longer lag adds no issue, no story points, no new line on the board. Scope looks flat. The date moves anyway.
Jira does not hold them. Jira issue links record that one item blocks another. They carry no lead or lag value, so the time adjustment lives in a separate schedule or a planner’s head, and is re-read about as often as the schedule is.
That is a dependency surfacing too late, the second of the three things that erode a committed release date. The other two often travel with it: the team waiting on a review picks up unplanned work to stay busy, and the person who owned the overlap is out the week it fails.
Keep the judgment. Read the effect in days.
The answer is not to stop using leads and lags. It is to record each one where the forecast can see what happens to it.
- For every lead, link the two work items in Jira and treat the link as soft while the overlap is a plan rather than a certainty. The moment the overlap fails, reclassify it as a hard link: the successor now really cannot start.
- For every material lag, especially one that sits in someone else’s queue, create a placeholder work item that carries the expected end date and a named owner, and hard-link it to the work it gates. When the queue moves, update that date.
- Record the committed date with the confidence level the team voted at.
- At every sprint boundary or cross-team sync, read the gap in days between the committed date and the forecast at the committed confidence, and look at which links are dictating the date.
An illustration, not customer data. A release is committed for 19 June at 85% confidence. At the vote the 85% forecast sits at 16 June: three days of margin. In week three the payments integration loses its two-day lead and the security review placeholder moves from three days to seven. No issues were added. The 85% forecast is now 24 June, five days past the commitment. The 50% forecast is 18 June, so the release reads amber (attention), not yet red.
Now the cross-team sync has a decision with a number on it. Ask for a priority slot in the review queue? Cut the one feature that depends on the changed API? Renegotiate the date while there is still margin to trade? Every option is the team’s call, and so is every assumption behind the forecast. What changes is that the call happens in week three, not at the release demo.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not read leads or lags, and it does not ask you to enter one. It reads what they turn into: Jira issue links between the work items in the Fix Version, marked hard (the dependent item cannot start until the blocker is done) or soft (a sequencing preference that is recorded but does not drive the path). A hard link added or reclassified in Jira enters the critical-path analysis the next time the forecast runs. A placeholder work item with a promised date, hard-linked to the work it gates, participates like any internal blocker; when its date changes, the dependency-aware Monte Carlo forecast re-runs and the change shows against the committed date in days. The Critical Path view shows the ordered sequence currently dictating the date. 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.
Leads and lags sit on the arrows of a network diagram; see what the precedence diagramming method can and cannot tell you after the vote. For the buffer a stretched lag eats first, see schedule float. For exactly what the app reads from each dependency element, see the dependency-aware planning reference doc.
Key takeaways
- A lead lets work overlap its predecessor; a lag is a required wait between two pieces of work. Both are engineering judgment and part of the evidence behind the confidence vote.
- After the vote, leads fail and lags stretch. Neither adds an issue, so scope looks flat while the committed date moves.
- Jira issue links carry no lead or lag. Record a failed lead as a hard link and a material lag as a dated placeholder work item, hard-linked to the work it gates.
- Read the gap in days between the committed date and the forecast at the committed confidence at every sprint boundary, not the leads and lags written on vote day.
FAQ
What are leads and lags in project management?
Time adjustments on a dependency. A lead lets the successor start before the predecessor finishes, creating an overlap. A lag forces a wait between the predecessor finishing and the successor starting, such as review, curing or soak time.
What is the difference between lead and lag?
A lead pulls the successor earlier and shortens the path. A lag pushes the successor later and lengthens it. Many scheduling tools write a lead as a negative lag on the same arrow.
How do you track leads and lags in Jira?
Jira issue links do not store a lead or lag value. Link the work items, mark overlaps as soft until they are proven, reclassify a failed overlap as a hard link, and model a long wait as a placeholder work item with a date and owner, hard-linked to the work it gates.
Keep your leads and lags. Add the number they are missing. See the committed date and its live confidence band in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.