The scope management plan is approved. The requirements are collected, the scope statement is signed, the WBS is in Confluence, and on Friday the team cast its confidence vote: 20 November, at 85% confidence. Everyone did project scope management by the book.

Three weeks later the release is nine days behind, and no step of the process flagged it. That is not a failure of discipline. It is a gap in what the process was built to measure.

What project scope management covers

Project scope management is the set of processes that define what work a project includes, what it excludes, and how changes to that boundary are handled. The PMBOK Guide (sixth edition) splits it into six processes:

1. Plan scope management. Write the scope management plan: how scope will be defined, validated and controlled, and who approves changes.
2. Collect requirements. Gather what stakeholders need from the release.
3. Define scope. Write the scope statement: deliverables, exclusions, acceptance criteria, constraints and assumptions.
4. Create the WBS. Break the deliverables into work packages. The scope statement plus the WBS form the scope baseline.
5. Validate scope. Get formal acceptance of completed deliverables.
6. Control scope. Monitor scope against the baseline and route changes through change control.

Read that list against the calendar. Processes one to four finish before the commitment. Validate scope happens deliverable by deliverable, mostly near the end. Control scope is the only process that runs through the weeks after the vote, which is exactly when scope moves.

The vote prices the scope. The weeks after re-price it.

The confidence vote is where the team turns the scope baseline into a date. It is expert engineering judgment: the engineers in the room know which items are larger than they look, which throughput window reflects how they work now, and who will be on the release. The team owns those assumptions. A good forecast does the arithmetic on top of them at Monte Carlo scale; it does not replace them.

But a vote is a snapshot. After it, scope keeps arriving in ways that control scope was never designed to price:

• Small additions that never file a change request. A ticket added to the Fix Version during refinement is ordinary Jira work, not a formal change.
• Re-included exclusions. Something the scope statement ruled out comes back in as a “quick follow-up”.
• Growth inside items. Acceptance criteria get longer. The item count stays the same; the work does not.

Control scope answers “is this change approved?” and “does the work match the baseline?” It does not answer “what does this cost the committed date, in days, at the confidence we voted at?” Scope creep is the first of the three things that erode a committed release date, alongside dependencies surfaced too late and capacity changes, and it is the one this process is supposed to own.

What a live control scope process looks like

The fix is not a seventh process. It is giving control scope a number to watch. Four habits make the difference:

1. Reference the Fix Version, not a copied list. If the in-scope list in your scope management plan points at the Jira Fix Version, every addition is counted, whether it came through change control or not.
2. Record the confidence line with the date. “20 November” is half a commitment. “20 November, committed at 85%” tells the next review what to compare against.
3. Read scope change as a rate. “Scope grew 14% in three weeks, under 1% per working day” is a number a sponsor can act on. “Some new tickets came in” is not.
4. Open every scope review with the gap in days. Today’s 85% forecast against the committed date. If the gap is growing, renegotiate scope or date now, while there are still options.

An illustration, not customer data: the team above committed to 20 November at 85%. Over three weeks, nine items joined the Fix Version through refinement and none filed a change request. The 85% forecast moved to 29 November. Control scope saw nine tickets that broke no rule; the committed date saw nine days. With the gap visible in week one, the product owner could have moved two Should-have items below the MoSCoW cut-line and kept the date.

Where Advanced Release Planning fits

Advanced Release Planning for Jira does not write or store a scope management plan, a scope statement or a WBS. It reads the Fix Version, issue links and the throughput window the team selects, runs a Monte Carlo simulation, and keeps the committed date and its 50/85/95% confidence band current. Removals step the burn-up scope line down, scope growth is shown as a percentage and a per-day rate, and the P50/P85/P95 dates react as scope grows or shrinks. A scope-driven slip becomes a dated, attributable event in days, not a surprise at the go/no-go.

That is the job control scope was always meant to do after the vote. The process names the boundary; the forecast tells you what crossing it costs. For the paperwork side, see why the change request’s schedule impact field so rarely gets filled in. The project scope management reference doc maps each of the six processes to what the forecast reads.

FAQ

What are the six processes of project scope management?
Plan scope management, collect requirements, define scope, create the WBS, validate scope and control scope (PMBOK Guide, sixth edition).

What is a scope management plan?
The document that says how scope will be defined, validated and controlled, and who approves changes to it. It sets the rules; it does not track the date.

Which scope process protects the release date?
Control scope, when it is read in days against the committed date and the confidence the team voted at, not only against the baseline.

Keep the committed date live

Your team’s confidence vote is a snapshot of expert judgment. Advanced Release Planning keeps it live as scope moves. See the committed date and its live confidence band in Advanced Release Planning, or try it on the Atlassian Marketplace.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio