The scope baseline was approved on a Tuesday. Scope statement, work breakdown structure down to the work packages, WBS dictionary, sign-off from the product owner and the sponsor. Forty-six issues in the Fix Version. The team read the backlog, read the throughput, voted four fingers, and committed the release for 20 March.
By week six the baseline document had not changed. The change log showed two approved change requests, both marked “no schedule impact.” The Fix Version held fifty-four issues. Most of the difference never went near change control: a story split into three during refinement, an accessibility fix everyone agreed was obvious, an item from the exclusions list quietly brought back in. The release shipped eight days late. The baseline still said forty-six.
What a scope baseline is
A scope baseline is the approved version of three documents: the scope statement, the work breakdown structure (WBS) and the WBS dictionary. Once approved, it changes only through formal change control, and it is the reference the project compares actual work against. In a Jira release, the closest working equivalent is the set of issues in the Fix Version at the moment of commitment.
Approving that baseline is expert engineering judgment. The team decides what is in, what is out, how the work breaks down and what “done” means for each package. It is the scope assumption underneath the confidence vote. When the team says “four fingers,” part of what they are saying is “for this scope.”
The baseline measures variance in items. The date moves in days.
The scope baseline is good at one question: is the work we are doing the work we agreed? It is not built to answer the question stakeholders actually ask after the vote: does the committed date still hold?
Scope enters without a change request. Splits during refinement, small additions nobody thinks of as scope, exclusions that drift back in, and growth inside existing items. None of it touches the baseline document, so variance against the baseline reads zero while the Fix Version grows.
Approved changes are assessed one at a time. Each change request gets its own impact line. Two “no schedule impact” decisions in the same month can add up to several days nobody signed off.
Variance is reported in the wrong unit. “Eight items over baseline” or “fourteen points of variance” is accurate and tells nobody whether to cut, move people or renegotiate. The committed date is measured in days.
That is scope creep, the first of the three things that erode a committed release date. The other two tend to arrive with it: new items bring issue links nobody mapped at planning, and the extra work competes for the same people the capacity plan already counted.
Keep the baseline. Read it against the date.
The answer is not a stricter change control board. It is putting the baseline and the committed date in the same place, so every scope move has a price in days before anyone approves it.
- When the baseline is approved, make the Fix Version the in-scope list, and write the committed date and the confidence level the team voted at into the baseline document.
- Treat every issue that enters the Fix Version as a scope change, whether or not it came with a change request. Removals count too.
- At each sprint boundary, read scope growth as a percentage and a per-day rate, then read the gap in days between the committed date and the forecast at the committed confidence.
- If you re-baseline, record the new committed date with its confidence level at the same time. A new baseline without a new date only hides the drift.
An illustration, not customer data. A release is committed for 20 March at 85% confidence. At the vote the 85% forecast sits at 17 March: three days of margin. By week six, ten issues have entered the Fix Version and two have left; scope growth reads about 17%. The 85% forecast moves to 26 March, six days past the commitment. The 50% forecast is 19 March, so the release reads amber (attention), not yet red.
Now the change control conversation has a number on it. Move the two could-haves below the MoSCoW cut-line to the next release? Send the re-included exclusion back out? Renegotiate the date while there is still margin to trade? Each option is the team’s call, as is every assumption behind the forecast. What changes is that the call happens in week six, not at the release demo.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not store, template or version a scope baseline, a scope statement or a WBS. It reads the Jira data the baseline describes: the issues in the Fix Version as the scope boundary, issue links as the dependency network, and the throughput window and Capacity Awareness settings as the delivery rate. When an issue is added to or removed from the release, whether in the app or by changing its Fix Version in Jira, the burn-up scope line steps up or down, scope growth is shown as a percentage and a per-day rate, and the Monte Carlo forecast re-runs. The committed date carries its confidence band (50%, 85%, 95%) and stays current as scope, dependencies and capacity move. The team sets the assumptions: which throughput window, whose capacity, what is in scope. The app does the arithmetic at Monte Carlo scale and keeps it live. Green at or above P85, amber between P50 and P85, red below P50.
The baseline starts with the boundary; see what the scope statement records and what it never watches. For where the baseline sits among the six scope processes, see project scope management. For exactly what the app reads from each scope artifact, see the project scope management reference doc.
Key takeaways
- A scope baseline is the approved scope statement, WBS and WBS dictionary. Approving it is expert engineering judgment and the scope assumption behind the confidence vote.
- After the vote, scope enters through splits, refinement additions and re-included exclusions that never reach change control, so variance against the baseline can read zero while the Fix Version grows.
- Treat every issue entering or leaving the Fix Version as a scope change, and read growth as a percentage and per-day rate.
- Read the gap in days between the committed date and the forecast at the committed confidence at every sprint boundary, and record a new date whenever you re-baseline.
FAQ
What is a scope baseline in project management?
The approved version of the scope statement, the work breakdown structure and the WBS dictionary. It changes only through formal change control and is the reference for comparing actual work against agreed scope.
What is the difference between a scope baseline and a schedule baseline?
The scope baseline fixes what will be delivered. The schedule baseline fixes when. Scope moving past its baseline is one of the most common reasons the date moves past its own; see why re-baselining the schedule makes a slip official.
How do you track a scope baseline in Jira?
Use the release’s Fix Version as the in-scope list at the moment of commitment. Every issue added to or removed from it afterwards is a scope change. A forecast that reads the Fix Version reports that change in days against the committed date.
Keep your scope baseline. Add the number it is missing. See the committed date and its live confidence band in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.