It’s the Wednesday sync, three sprints from the finish line, and the release forecast has been amber for a week. Somebody senior finally says it: “Can we crash the schedule? Or overlap the hardening and start integration now?” Every delivery lead knows this meeting. The date is drifting, the pressure is real, and the two oldest rescues in project management — crashing and fast-tracking — are suddenly on the table, usually without their price tags.

Crashing vs fast tracking, defined

Crashing shortens the schedule by adding capacity: more engineers, contractors, overtime. Fast-tracking shortens it by overlapping work that was planned in sequence: starting integration before the API is final, testing against a moving build. Agile teams rarely use the PMBOK names, but they make both moves constantly — “borrow two devs from platform” is a crash; “don’t wait for the design review” is a fast-track. Both are legitimate. Both sometimes work. And both bill you later unless you size them honestly first.

What crashing actually costs

Crashing is a capacity change, and capacity changes cut both ways. Brooks’s Law has held since 1975: people added to late work make it later first, because onboarding and coordination consume the very throughput you were buying. A crash that looks like +2 engineers is, for the first few weeks, closer to −1. There’s a money cost too — overtime and contract hours are the expensive way to buy days. Crashing pays off when the work truly parallelizes and the ramp-up is short. Your team knows whether that’s true; no dashboard does.

What fast-tracking actually costs

Fast-tracking compresses the plan by borrowing certainty you don’t have yet. Overlapping dependent work means building against interfaces that may still change — and when they do, the rework lands late, exactly where the plan has no room left. Worse, the overlap manufactures the classic date-killer: the dependency nobody flagged. Starting early didn’t remove the dependency between the two pieces of work. It hid the dependency until it was expensive.

The question neither rescue answers

How many days short are you — today? Your team committed the date at planning with a confidence vote, and that vote was expert engineering judgment: the people closest to the work, weighing evidence they validated themselves. It was right when it was cast. But a vote is a snapshot, and since the vote, the three things that erode a committed release date have been working on it: scope crept in, dependencies surfaced late, capacity changed. Deciding on compression without the current gap is folklore — you’re buying days without knowing how many you need. This is exactly where release planning in Jira has to get honest: the committed date tracked against a live 50/85/95% confidence band, forecast from the team’s real throughput, with the drift measured in days.

Model the rescue before you pay for it

The division of labor matters here. The team owns the assumptions — which throughput window reflects reality, how much effective capacity a borrowed engineer adds and from when, what is genuinely in scope. The app’s job is the arithmetic at Monte Carlo scale, re-run every time an assumption changes. So model the crash as the capacity change it is, with the team’s honest ramp-up judgment, and watch whether the band actually reaches the committed date. Model the fast-track and let the dependency chain show what the overlap is really carrying. If the band barely moves, you’ve just learned the rescue was theater — before paying for it, not after.

The lever the meeting forgets

Sometimes compression is the right call: a small gap, truly parallel work, a short ramp. But when the model says no, the honest lever is renegotiation — trade scope below the cut-line, or recommit to a date the band supports at 85% confidence. Renegotiating before the slip, with the gap in days on the screen, is a calmer conversation than the one that follows a failed crash. That is the whole point of keeping the vote live: the commitment stays defensible because the evidence underneath it stays current.

The next time someone says “crash it,” bring the gap. Release Management, Roadmaps, Portfolio PPM & Timeline for Jira forecasts every release’s committed date at 50/85/95% confidence from real throughput, tracks erosion against it in days, and re-forecasts as your assumptions change. See how the modeling works in the docs, browse the rest of our release planning guides, and put a number on the rescue before you buy it.

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