Every serious release has a decision log somewhere. A row for the day the team agreed to pull the reporting module into this release. A row for the day the platform team’s API was allowed to slip a sprint. A row for the day two engineers were loaned to the incident. Each row has a date, an owner, a rationale, and a tidy status of “Approved.” What none of the rows has is a column for what the decision did to the release date.
That is not a flaw in the template. A decision log is built to answer “why did we do this?” months later, and it does that well. The problem is what happens between the rows. Three approved decisions, each judged small on the day, add up to a committed date that no longer holds, and the log that recorded all three is the last place anyone would look to find out.
What a decision log actually captures
Start by giving the artifact its due. A decision log in project management is the record of choices that changed the plan: what was decided, when, by whom, what alternatives were considered, and why this one won. It is the memory of the release. When a stakeholder asks in November why a feature that was “definitely in” shipped in the next version, the log is the honest answer, and a team that keeps one is doing better governance than most.
Every one of those decisions was also made against a date. The team committed to that date at PI planning, or whatever your commitment moment is called, with a confidence vote that reflected expert engineering judgment about scope, dependencies and capacity as they stood that week. The decision log begins its life the day after the vote, and each entry is a place where one of those three inputs was allowed to change.
Look down any real log and the entries sort neatly into the three things that erode a committed release date. Scope decisions: an item added, a requirement widened, a “quick” enhancement accepted. Dependency decisions: an upstream delivery accepted a sprint later, an integration moved behind a vendor’s timeline. Capacity decisions: a loan to another team, a hire deferred, a specialist’s leave approved. Each entry records the decision. None records the days.
The column the decision log template is missing
Here is the mechanical gap. A decision log entry is a snapshot: it freezes the state of the trade-off at the moment of approval. “Adding the export feature costs roughly a week; we have slack; approved.” That sentence may have been true on the day. But the slack it spent was the same slack the previous decision spent, and the one before that. Snapshots do not add up on their own. Somebody has to re-open the release plan, re-run the forecast, and ask what the committed date looks like after every row so far, and no decision log template has a field that forces the question.
So the erosion arrives in a form the log cannot see. Each decision was reviewed against a baseline that had already moved. Each was, individually, defensible. The date slips not because anyone chose to slip it, but because no single decision was ever priced against the running total, and the log, the one place all the decisions are gathered, was never asked to keep one.
Keep the price of every decision live
The fix is not a better spreadsheet. It is to give the decision log a companion that does the arithmetic the log cannot: a live forecast of the committed date that re-runs every time one of the three inputs changes in Jira.
Advanced Release Planning holds the committed date alongside the confidence level the team voted at, 50, 85 or 95 percent, and runs a Monte Carlo forecast on the team’s own throughput. The team still owns the assumptions: which throughput window counts as evidence, whose capacity is on the roster, which items are in scope. The app owns the recalculation. When a work item is added to the Fix Version, when a dependency’s date moves, when someone’s allocation changes, the band moves with it, and the movement is recorded in days and attributed to scope, dependency timing or capacity.
That gives the decision log the column it was missing, without changing the template. Before an entry is approved, the forecast shows the committed date with and without the change, which is the schedule line of a change impact analysis done in days rather than story points. After it is approved, the change history against the committed date carries the running total the log never kept, so the twelfth small approval is read against the eleven before it, not against the vote. And when cumulative drift pushes the committed date below the confidence the team chose, the release moves from on-track to attention while the options are still open, which is where the change control board earns its meeting.
Nothing about this replaces the team’s judgment. The confidence vote was the right call on the evidence available; the log is the right record of what changed afterward. What the live band adds is the one thing a snapshot cannot: the current cost, in days, of everything the log already says. The readings the app supplies for each logged decision are described in the renegotiation how-to.
Give your decision log a running total
Keep the log. It is the memory of the release and you will be glad of it. Then put the committed date and its confidence band next to it, so every row is priced when it is written and re-priced as the release moves. See how Advanced Release Planning keeps a committed date live in Jira, and let the next decision be renegotiated before it slips, not explained after.
1 Comment
Leave your reply.