It’s week six of the Program Increment, and the release everyone voted a confident four on is now amber. The steering meeting does what steering meetings do: someone senior leans back and says, “What if we pull two engineers over from the platform team?” Heads nod. Budget appears. It feels like decisive action. It is also the textbook setup for Brooks’s Law.
Fred Brooks watched this exact meeting happen in 1975. His verdict, in The Mythical Man-Month, became the most quoted sentence in software management: adding manpower to a late software project makes it later. Brooks’s Law is fifty years old, and it has outlived every methodology invented to dodge it — because none of its causes have gone away.
Why Brooks’s Law still holds
New people don’t arrive productive. They arrive with questions — and the people who can answer them are the ones already carrying the critical path. For their first weeks, a new engineer is a net cost: environment setup, codebase archaeology, review cycles that run long, and a mentor whose own throughput just dropped by a third.
Meanwhile, coordination grows faster than headcount. Brooks’s arithmetic is blunt: a team of n people has n(n−1)/2 communication paths. Grow from eight to ten and the paths jump from 28 to 45 — 60% more coordination for 25% more hands. And the work itself has to be repartitioned, which in software is rarely clean.
None of this says you should never add people. It says that the day you change the team, you changed the foundations of the plan — whether or not anything on the plan visibly moved.
Your confidence vote priced in a specific team
Go back to the day the date was committed. At PI Planning, the team looked at the scope, weighed it against their real delivery history, and voted their confidence. That vote was expert engineering judgment — people who know this codebase, this domain, and each other, saying “we can do this.” And it priced in a specific team: these eight engineers, this throughput record, this on-call rotation.
What it could not price in is what hadn’t happened yet. That’s the quiet villain of every release: post-commitment erosion — the three things that erode a committed release date after the vote are scope creep, dependencies surfaced too late, and capacity changes. A mid-release rescue squad is the third one wearing a cape. The roster changed, so the capacity assumptions behind the committed date changed — downward first, then perhaps upward, on a curve nobody in the steering meeting can actually see.
Keep the judgment. Redo the arithmetic — continuously.
This is exactly what Advanced Release Planning for Jira is built for. The team still owns every assumption that matters: which throughput window reflects reality, whose capacity counts, what’s in scope. The app takes those validated assumptions and does the arithmetic at Monte Carlo scale — thousands of simulations against the team’s actual throughput history, not a slide’s imagined future output.
When the roster changes, you record the capacity change and the forecast reruns. The committed date and its confidence band (50/85/95%) respond in days, attributed to that change — the same way the app tracks unplanned work stealing capacity or capacity risk from planned absences. If onboarding drag pushes the 85% date out nine days, you see those nine days this week — not in the go/no-go meeting. And as the new engineers’ finished work starts landing in the throughput history, you watch the band tighten again: evidence, not hope, that the rescue is paying for itself.
Before you add anyone to a late release
Re-forecast on the team you have. If the gap to the committed date is three days at 85% confidence, you manage it. If it’s three weeks, no plausible hire closes it in time — renegotiate scope or date now, while it’s cheap. Cut at the line first: moving Should-haves to the next release costs nothing to onboard. If you do add people, add them early, to work that genuinely partitions — Brooks himself allowed that exception — and let the confidence band tell you when they’ve broken even.
Either way, the stakeholder conversation happens before the slip, with the erosion measured in days and attributed to its cause. That’s the difference between defending a miss and renegotiating a commitment.
The vote was right. Keep it right.
Your team’s confidence vote was correct the day it was taken — an expert judgment on the evidence available. Brooks’s Law is simply a reminder that the evidence changes, and that the fastest way to change it is to change the team. Try Advanced Release Planning for Jira and watch how your committed date responds to a capacity change — in days, before it slips. For the mechanics, the docs cover how capacity change tracking works.
Leave a Reply
Your email is safe with us.