The scope management plan was signed off two weeks before PI planning. It was a good plan. It said scope would be defined in the scope statement, broken down in the WBS, accepted by the product owner at each sprint review, and controlled through change requests. It named the change control board. It set the escalation rule: any change larger than 10% of the baselined story points goes to the board. Smaller changes are approved by the product owner.
The team read the backlog, read the throughput, voted four fingers and committed the release for 12 February. By week five, seven items had entered the Fix Version. Each was small. Together they came to 8% of the baselined points, under the threshold, so none reached the board. Every one was handled exactly as the plan said. The release shipped six days late, and the plan was followed the whole way.
What a scope management plan is
A scope management plan is the document that says how a project’s scope will be defined, structured, validated and controlled. It is the output of the first scope process, plan scope management. It does not list the deliverables. It sets the rules: how requirements become scope, how the work breakdown structure is built, who accepts finished work, how change requests are raised and who approves them.
Writing that plan is expert engineering judgment. The team and its stakeholders decide where the boundary sits, how fine the breakdown goes and how much change a product owner can absorb without escalation. Those rules are part of what the confidence vote stands on. When the team says “four fingers,” part of what they are saying is “for this scope, controlled this way.”
The plan’s control rules are written in items. The date moves in days.
The scope management plan answers one question well: who decides when scope changes? It is not built to answer the question stakeholders ask after the vote: does the committed date still hold?
Thresholds are set in the wrong unit. “Escalate anything over 10% of story points” or “more than five new items per sprint” is a reasonable rule. It says nothing about days. A 6% change landing on the critical path late in the release can cost more days than a 12% change landing early on parallel work.
Each change is judged alone. The plan routes every request through the same gate, one at a time. Seven changes below the threshold never add up to one escalation, even when together they spend all the margin the team voted on.
Scope enters without a request. Stories split during refinement, a fix everyone agrees is obvious, growth inside an item already in the release. The plan’s control process never sees them, because nobody raised them as changes.
That is scope creep, the first of the three things that erode a committed release date. The other two travel 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 plan. Add one rule written in days.
The answer is not a lower threshold or a busier change control board. It is one extra section in the plan, so the control rules point at the committed date instead of only at the backlog.
- Name the Fix Version as the in-scope list, and write the committed date and the confidence level the team voted at into the plan.
- Treat every issue entering or leaving the Fix Version as a scope change, whether or not it came with a change request.
- Add a threshold in days: escalate when the forecast at the committed confidence moves past the committed date, however small each individual change was.
- At each sprint boundary, read scope growth as a percentage and a per-day rate, and the gap in days between the committed date and the forecast.
An illustration, not customer data. A release is committed for 12 February at 85% confidence. At the vote the 85% forecast sits at 9 February: three days of margin. By week five, seven issues have entered the Fix Version, each under the plan’s 10% threshold. The 85% forecast moves to 18 February, six days past the commitment. The 50% forecast is 11 February, so the release reads amber (attention), not yet red. Under the item rule nothing escalates. Under the days rule, the board meets in week five.
Now the conversation has a number on it. Move two could-haves below the MoSCoW cut-line? Send the split stories’ extra halves to the next release? Renegotiate the date while there is margin to trade? Each option is the team’s call, as is every assumption behind the forecast. What changes is when the call happens.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not generate, store or template a scope management plan. It reads the Jira data the plan governs: 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 plan is the first of six scope processes; see why only one of them runs after the vote in project scope management. Its sibling on the schedule side has the same gap; see how to write schedule management plan thresholds in days. For exactly what the app reads from each scope artifact, see the project scope management reference doc.
Key takeaways
- A scope management plan sets how scope is defined, validated and controlled. Writing it is expert engineering judgment and part of what the confidence vote stands on.
- Its control thresholds are usually written in items, points or percentages, and each change is judged alone, so many small changes never escalate.
- Name the Fix Version as the in-scope list and treat every issue entering or leaving it as a scope change.
- Add one threshold in days against the committed date, at the confidence level the team voted at.
FAQ
What is a scope management plan?
A project document that defines how scope will be defined, structured, validated and controlled, and who approves changes. It sets the rules for managing scope rather than listing the deliverables themselves.
What should a scope management plan example include?
Typically: how the scope statement is prepared, how the WBS is created and maintained, how the scope baseline is approved, how deliverables are accepted, and how change requests are handled. For a release with a committed date, add the Fix Version as the in-scope list and an escalation threshold in days. See also what the scope baseline fixes at the vote.
What is the difference between a scope management plan and a scope statement?
The scope statement describes what is in and out of the project. The scope management plan describes how that scope will be defined, checked and changed.
Keep your scope management plan. 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.
1 Comment
Leave your reply.