Key Takeaways
- A change impact analysis answers “what does this change cost?” Most answer in effort, such as story points or hours, measured against a baseline date that was set at the confidence vote and has been eroding ever since.
- The unit that helps a decision is days of movement against the committed date, at the confidence level the team chose: “this change moves the P85 date by six days.”
- Individually small changes pass one at a time. The impact that sinks a release is cumulative, and only a live change history against the committed date shows it.
- The team owns the judgment: whether the change is worth the days, which throughput window applies, whose capacity is in play. Advanced Release Planning does the arithmetic at Monte Carlo scale and keeps it current.
The change request is two paragraphs long. The impact analysis attached to it is one line: “+8 points, absorbed within current sprint capacity, no schedule impact.” Everyone nods. Approved. It is the eleventh change approved since the PI confidence vote, and every one of the eleven said “no schedule impact.” The release now sits nineteen days behind the committed date, and not one of those analyses was wrong on its own terms.
What a change impact analysis is supposed to do
Change impact analysis (often called a change impact assessment) is sound practice. In the PMBOK Guide it lives inside integrated change control: before a change is approved, someone assesses its effect on scope, schedule, cost, quality, and risk. ITIL’s change enablement asks the same question from the operations side. Nobody should stop doing this. The discipline of stopping to ask “what does this cost?” is exactly what separates a governed release from one that drifts.
The problem is not the question. It is the unit the answer comes in, and the baseline it is measured against. On the schedule dimension, most impact analyses fail three ways, and all three happen before the change is even approved.
Three ways the analysis goes stale before the vote
1. It compares against a date that has already moved
The baseline in the template is the committed date from the confidence vote. That vote was expert engineering judgment: the team looked at the scope, its own throughput, and the calendar, and said “this date, at about this confidence.” It was the right call on the evidence available that day. But a confidence vote is a snapshot, and since that day the three things that erode a committed release date have been working on it: scope crept, a dependency surfaced late, a senior engineer moved teams. The committed date that reads “on track” in the template may already sit at 60% confidence in reality. An impact analysis that says “no schedule impact” against that baseline is measuring against a number that stopped being true weeks ago.
2. It reports effort, not date movement
“Eight points” is an input. The board deciding on the change does not need the input; it needs the output, which is where the committed date sits on the confidence band with the change and without it. Effort gets “absorbed” in the analysis because there is always a sprint with some room in it. The same effort reappears at the end of the release as days, when the last sprint discovers it has been carrying ten absorbed changes. Points are how the team sizes work. Days against the committed date are how the decision should be priced.
3. It does not accumulate
Each change is analysed on its own form, in its own meeting, against its own copy of the baseline. Ten approvals of “no schedule impact” are ten separate documents, and nothing in the process adds them up. This is the same shape of failure a change control board runs into: the governance is real, each decision is defensible, and the cumulative drift is invisible until it is nineteen days.
Make the impact analysis a re-forecast, not an estimate
The fix is to change what the schedule line of the analysis contains. Instead of an effort figure and a judgment call about whether it fits, the schedule line should be a re-forecast of the committed date with the candidate change included. In practice, with Advanced Release Planning for Jira, that looks like this:
- Add the candidate item to the Fix Version. The Monte Carlo forecast re-runs on the team’s own throughput window, and the confidence band moves. Read the committed date’s position before and after: “P85 moves from October 14 to October 22.” That is the schedule impact, in days, at the confidence level the team committed at.
- Record the movement, not the points. The analysis says “8 days at P85, attributed to scope,” and the board decides whether the change is worth eight days. That is a real decision. “Absorbed within capacity” was never one.
- Read the cumulative change history in the same meeting. The app keeps a change history against the committed date, in days, attributed to scope additions, dependency timing, or capacity change. The question for the eleventh change is not “what does this one cost?” but “what have the previous ten cost, and where does this one leave us?”
- Treat a breach of the chosen confidence level as the trigger. When cumulative drift takes the committed date below the level the team voted at, the analysis has done its job: it has surfaced the renegotiation early, while there are still options. Move the MoSCoW cut-line, change capacity, or re-commit to a new date that carries its own confidence level. A schedule baseline that is quietly re-baselined after each approval does the opposite: it ratifies the drift.
None of this replaces the team’s judgment. The throughput window is the team’s choice. Which people count as capacity for this release is the team’s choice. Whether eight days is a price worth paying for the change is the team’s and the product owner’s call. What changes is that the analysis is no longer a one-time estimate against a stale baseline; it is a live reading of the same forecast the team validated at the vote, re-run with the change in it.
What the app does, and what it does not
Advanced Release Planning tracks scope change against the committed date in both directions, reports it as a percentage and as a per-day rate, and feeds every change into the Monte Carlo forecast so the P50, P85, and P95 dates react. The change history attributes movement to scope, dependencies, or capacity, and a release’s status (on track, attention, at risk) is computed from where the committed date sits on the live band. The mechanics are documented in Renegotiating a Committed Release Date: How It Works.
It does not implement a change-request form or an approval workflow, and it does not assess the cost, quality, or risk dimensions of an impact analysis. It supplies the schedule dimension: the one that most templates answer in points and most boards discover in days.
Price the change in days, at the confidence you committed at
The confidence vote was the team’s expert judgment about a specific scope on a specific date. Every approved change is a small edit to that scope, and a change impact analysis is the moment to re-read the judgment on evidence, not the moment to declare the date unaffected. See how Advanced Release Planning keeps the committed date and its confidence band live in Jira, so the eleventh change is priced against where the release actually is.
Frequently asked questions
What should the schedule section of a change impact analysis template contain?
Four things: the committed date and the confidence level it was committed at; the forecast position of that date today, before the change; the forecast position with the change included, expressed as days of movement at the same confidence level; and the cumulative drift since the vote, attributed to scope, dependencies, and capacity. An effort figure on its own does not tell the approver what the change costs.
How is change impact analysis different from change control?
Change control is the governance process: who may propose a change, who approves it, and how it is recorded. Change impact analysis is the assessment that feeds the approval decision. A change control board can be rigorous and still approve its way into a late release if every analysis it receives reports “no schedule impact” against a baseline that has already moved.
Related reading: once a change is approved, the entry usually lands in a decision log that records the rationale but not the days. The Decision Log Records What Was Decided. Not What It Cost the Date. covers how to keep the running total live.
1 Comment
Leave your reply.