The release plan had a PERT chart, and for once it had a number on it. Each activity carried an optimistic, a most likely and a pessimistic duration. The longest chain came out at sixty working days, with a standard deviation of five. The team committed to day sixty-five, and the chart said that date had roughly an 84% chance of holding. The team voted a four.

In week five, the platform team flags that the new service needs a dedicated integration environment before end-to-end testing can start. Nobody had drawn that activity. Two weeks later, the reporting chain, which had looked comfortable, runs long because two of its people were pulled onto a production incident. The chart on the wiki still says 84%.

The PERT analysis was not wrong. It was right about the plan the team had on the day it was drawn.

What a PERT chart is good at

PERT, the Program Evaluation and Review Technique, was developed for the US Navy’s Polaris program in the late 1950s. A PERT chart is a network diagram: activities and the dependencies between them. What sets it apart from a plain network is the duration model. Each activity gets three values, and the expected duration is weighted towards the most likely one, commonly (O + 4M + P) / 6. The spread, (P − O) / 6, travels with it.

Add the expected durations along the longest chain and you get an expected finish. Add the variances along the same chain and you get a spread around it. From those two figures, a PERT analysis reads off the probability of finishing by any target date. That is the right instinct: a date is a range, and a commitment should say how sure the team is. Building the chart is expert engineering judgment about sequencing and risk, and it is part of what the team votes on.

What the probability on the chart cannot see

The probability is only as current as the network and the ranges under it. Three things follow.

• It holds only the activities and links someone drew. An activity added in week five is not in the figure until someone redraws the chart and works it through again. Dependencies surfaced too late are the second of the three things that erode a committed release date.
• It follows one chain. Classic PERT takes its spread from the critical path alone. Where near-critical chains merge into the same milestone, the milestone waits for the slowest of them, so the single-chain probability tends to read higher than the plan deserves. The critical path method has the same blind spot after the vote: the chain that sets the date can change.
• Its ranges are set once. The optimistic and pessimistic values are elicited at planning. When the work behind an activity grows, or the people behind it change, the range on the chart stays where it was. As with three-point estimates generally, the range is honest on day one and frozen after it.

Where the PERT chart drifts after the vote

The drift comes from the same three places it always does:

• Scope creep. An activity grows past its pessimistic value, or new activities appear inside the release.
• Dependencies surfaced late. An environment, a security review or another team’s deliverable joins a chain.
• Capacity changes. People are pulled onto incidents, leave, or move teams, and a chain with float loses it.

None of these redraws the chart. Each one moves the date.

Keep the probability, make it live

Keep the PERT conversation. It is where the team says out loud what waits on what and how wide the uncertainty is. Change where the live number comes from. The dependencies are already in Jira as issue links. The evidence of how fast the team actually delivers is in Jira too. Forecast from those, re-run whenever they change, and 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: the team commits to 20 November at 85% confidence. In week five the integration environment is added as a work item and hard-linked to the testing it gates. The forecast at 85% moves to 28 November. The gap is eight days, and it is visible the day the link is added. The question becomes “do we bring the environment forward, move work off the chain, or renegotiate?” while there is still time to choose.

How Advanced Release Planning keeps it live

Advanced Release Planning for Jira does not draw a PERT chart, store optimistic, most likely and pessimistic values, or apply the PERT formula. The team still owns the assumptions: which throughput window to trust, whose capacity is in, what is in scope, which links are real blockers. The app runs a 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%.
• Because the forecast samples the team’s whole delivery history, slowdowns that hit several items at once are already in the record, instead of being summed away as independent.
• Hard links drive a Critical Path view of the work currently dictating the date, including blockers in another team’s Fix Version. Soft links are recorded but do not drive the path.
• When scope, dependencies or capacity change, the movement is reported against the committed date in days.

The mapping from each PERT element to what the app reads is in the PERT Charts & the Committed Release Date reference.

The PERT chart records how sure the team was on planning day. The forecast shows how sure it can be today, and what the difference costs in days. With both, the team renegotiates before the date slips, not after.

FAQ

What is the difference between a PERT chart and a Gantt chart?

A PERT chart is a network: it shows which activities depend on which, with a three-value duration on each, and supports a probability for the finish date. A Gantt chart is a timeline: it shows each activity as a bar against the calendar. PERT is better for reasoning about sequencing and uncertainty; Gantt is better for showing who is doing what, when.

Do agile teams use PERT charts?

Rarely as a full network with three durations per item. The two questions PERT answers still matter: which chain of dependencies sets the release date, and how confident the team is in it. Agile teams usually hold the first in Jira issue links and answer the second with a forecast over their own delivery history.

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