It is the Thursday before planning. Eight people, one story on the screen, and someone asks the question that makes three point estimation worth doing: best case, most likely, worst case?
The answers are good. Five days if the auth service behaves. Eight if it doesn’t. Fifteen if the vendor sandbox is down again, which it was twice last quarter. That last number is not pessimism — it is somebody remembering a real thing that really happened. The room converges. The three values go into the sheet, the PERT formula turns them into 8.5, the sheet rolls up forty of those, and out comes a date.
The date goes on a slide. The slide goes to a steering group. Nobody in that room ever sees the three numbers again.
The technique is not the problem
Three point estimation is one of the more honest things our industry does. Ask an engineer for a single number and you force them to choose between the date they hope for and the date they would defend. Ask for three and they will tell you the truth about a distribution.
The optimistic, most likely and pessimistic values a team gives are expert engineering judgment — the accumulated memory of which integrations are flaky, which reviewers are slow, which “small” changes never are. The same is true of the commitment confidence vote that follows at PI planning. When a team raises a fist of five, they are not guessing. They are pricing every risk they can see against the capacity they believe they will have.
What both rituals share is a timestamp. A confidence vote is a snapshot. A three point estimate is a snapshot. Each is accurate on the day it is taken, and neither one knows what happens next. That is also the honest reading of the planning fallacy: the problem was never that teams cannot estimate.
What happens next
Three things move a committed release date after the estimate is given, and none of them is the estimate being wrong. They are the three things that erode a release date.
Scope creep. Fourteen items joined the Fix Version after planning. Nobody re-elicited O, M and P for the release. Work was simply appended to a total built from a fixed set.
Dependencies surfaced too late. The auth service the worst case was about turned out to be a hard blocker owned by another team. The pessimistic number assumed a delay. It did not assume a queue.
Capacity changes. Two engineers moved to an incident. One took the leave everyone knew about and the model did not. The three points described how long work takes. They said nothing about how many people are left to do it.
There is a quieter arithmetic problem too. A PERT roll-up discards the range at the moment of summing — O and P weight the mean, then only the mean propagates — and it adds item estimates as though their risks were independent. When one flaky integration or one absent specialist touches eight items at once, independent means understate the tail. Which is why the release planning template has a date field and no confidence field.
Keeping the range live
Advanced Release Planning for Jira takes the same posture as a three point estimate and refuses to let it freeze. It reads the completed-work history for the Fix Version out of Jira, runs thousands of Monte Carlo simulations over that throughput, and returns a committed date carried with its confidence band — P50, P85, P95.
The team still owns the assumptions. Which throughput window is representative. Whose capacity counts. What is in scope. The app does the arithmetic at a scale no spreadsheet roll-up reaches, and — the part that matters — runs it again every time the evidence moves.
So when those fourteen items land, the band moves and the app reports how far, in days. When the dependency is linked in Jira, the blocking chain constrains the date. When capacity drops, the distribution shifts with it. The judgment is not replaced. It is kept current. (See exactly what the forecast reads, and what it does not do, in the docs.)
A range you can still negotiate with
That is the whole difference between a range and a live range. A three point estimate tells you what the team believed in the planning room. A live confidence band tells you what today’s evidence supports.
Which changes the conversation with the steering group from explaining a miss to proposing a trade while there is still time to make one. Cut two Could-haves and hold the date at 85%. Or keep the scope and move the date eleven days. Both are negotiations. Neither is an apology.
Your team already gives you the range. The only thing missing is a way to keep it true after planning day.
Keep your team’s range live
Advanced Release Planning, Roadmaps & Management for Jira forecasts a committed release date with a 50/85/95% confidence band from your team’s real Jira throughput, and re-runs it as scope, dependencies and capacity move. Runs on Atlassian — your data never leaves Jira. Try it free for 30 days on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.