At PI planning, the team traced the critical path across the program board: API contract, then the payments service, then checkout, then the release. Four cards, one string between each. Everyone agreed that chain set the date, and the team voted a four on it.

In week four, the security team mentions that the new payments flow needs a penetration test before it can ship. Nobody had drawn that string. The test has a three-week queue. It now sits on the longest chain, so the chain on the wall is no longer the critical path. The date on the wall has not moved.

Nothing was wrong with the analysis. It was correct for what the team knew on the day it was drawn.

What the critical path method is good at

The critical path method (CPM) models a project as a network of dependent activities. A forward pass gives each activity its earliest start and finish; a backward pass gives its latest. Activities with zero float form the critical path: the longest chain of dependent work, and so the shortest time in which the whole project can finish. A delay anywhere on that chain delays the end date.

Drawing it forces the right conversation. Which work truly waits on which? Which team holds the blocker? Where does the plan have slack, and where does it have none? That is expert engineering judgment about sequencing, and it is part of what the team votes on when it gives a release a four or a five.

What it cannot tell you after the vote

CPM produces one path from one set of inputs: a single duration per activity and the dependencies known when the network was drawn. Once work starts, that gives it three structural limits.

• It holds only the dependencies someone wrote down. A blocker found in week four is not on the path until someone redraws the network. Dependencies surfaced too late are the second of the three things that erode a committed release date.
• It reports one path, not the near-critical ones. A chain with two days of float looks safe on the diagram. When one task on it runs long, it becomes the critical path. The schedule float that looked like margin is the first thing erosion spends.
• It uses one duration per task. Where several chains merge into one milestone, the milestone waits for the slowest of them. A finish date built from single durations on each chain tends to be earlier than one that allows for the spread on every chain.

Where the critical path moves after the vote

In practice the path shifts in three ways, and none of them files a change request:

• A late blocker joins the chain. A security review, a platform upgrade, a vendor API that ships later than promised.
• A soft link turns hard. “Better to sequence after” becomes “cannot start until.”
• A parallel chain overtakes. The chain that had float loses it, because its work grew or its people were pulled onto something else.

The third one carries the other two killers. Work that grows inside items is scope creep. People pulled away is a capacity change. The critical path is where all three show up as days.

Read the path from Jira, not from the wall

Keep the method. Change where the path comes from. The dependencies are already in Jira as issue links. Read the path from them, and let it change every time a link is added or reclassified, not at the next planning event. Then open every review with one number: the gap between the committed date and today’s forecast at the confidence level the team committed at.

An illustration: a team commits to 14 November at 85% confidence. In week four the penetration test is added as a work item, hard-linked to the checkout work it gates. The forecast at 85% now reads 25 November. The gap is eleven days. The question moves from “is this on the critical path?” to “do we start the test earlier, move work off the chain, or renegotiate the date?”

How Advanced Release Planning keeps it live

Advanced Release Planning for Jira does not ask for activity durations or lag, and it does not produce a CPM float table. The team still owns the assumptions: which throughput window to trust, whose capacity is in, which links are real blockers. The app runs the Monte Carlo forecast over the team’s real Jira throughput, at a scale nobody runs by hand, and keeps it current.

• The committed date carries a live confidence band: 50%, 85% and 95%.
• Hard links (the dependent item cannot start until the blocker is done) drive the path. Soft links are recorded but do not.
• A Critical Path view shows the ordered sequence of work currently dictating the date, including blockers that live in another team’s Fix Version.
• Circular dependencies are detected and kept out of the path instead of distorting it, and items on or near the path are ranked by risk.

The mapping from CPM terms to what the app reports is in the Dependency-Aware Planning & Critical Path reference. For the buffer-based alternative to CPM, see critical chain project management.

The critical path method records which chain the team believed would set the date. The forecast shows which chain sets it today, and what the difference costs. With both, the team renegotiates before the date slips, not after.

FAQ

How do you find the critical path?

List the activities, their dependencies and a duration for each. Run a forward pass for earliest start and finish, then a backward pass for latest start and finish. Activities whose earliest and latest times match have zero total float and form the critical path. In Jira, the dependencies already exist as issue links; the chain that matters is the sequence of hard blockers that finishes last.

Do agile teams use the critical path method?

Rarely as a full network with durations. The question it answers still matters: which chain of dependencies sets the release date. Agile teams usually hold that answer in issue links and program boards rather than in a Gantt schedule, which is why reading it live from Jira fits the way they already work.

See your committed date and its live confidence band in Advanced Release Planning, or view it 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