Scope change and scope creep: how to manage them in agile and SAFe

1. What is a scope change?

Scope is the work you agreed to deliver: a scope statement in a traditional project, the Sprint Backlog in Scrum, and the features and PI objectives committed in PI Planning in SAFe.

Agile methods were built to accept change: "Welcome changing requirements, even late in development."^[2] That is not the same as accepting every request without looking at the cost.

2. Scope change vs scope creep

Scope creep is also called requirement creep or feature creep.^[1] Its harms include "overruns in costs, schedule, or both", though the same source notes that if it "is well managed, it can help projects by creating a better final product."^[1] The remedy is not to refuse change but to turn creep into managed change.

3. Scope management in traditional projects vs agile

The classic model is the project management triangle, or triple constraint, which holds that "the quality of work is constrained by the project's budget, deadlines and scope (features)."^[3] Change one corner and another must move.

Traditional projects protect scope with change control, which the Project Management Institute defines as a "process whereby modifications to documents, deliverables, or baselines associated with the project are identified, documented, approved, or rejected."^[4] Agile teams keep the baseline and the explicit decision, and drop the paperwork.

4. What causes scope creep?

• A poorly defined scope or goal. If nobody can say what the sprint or PI is for, any request looks relevant.^[1]
• Missing requirements. Stakeholders who were not consulted surface needs later.^[1]
• Low apparent cost of change. Creep enters "while presented as small, simple, and easy to implement changes."^[1]
• Gold plating. Teams add extra features to impress, without being asked.^[1]
• Side-door requests and unplanned work. Direct asks, incidents and defects that consume capacity without reaching the backlog.

5. How to manage scope changes in Scrum

The Scrum Guide calls the Sprint Goal "the single objective for the Sprint" and says it "provides flexibility in terms of the exact work needed to achieve it."^[5] During the sprint, "no changes are made that would endanger the Sprint Goal" and "scope may be clarified and renegotiated with the Product Owner as more is learned."^[5]

• Route every request through the Product Owner, not straight to developers.
• Test it against the Sprint Goal. If it serves the goal, swap it in; if not, it waits.
• Swap, do not stack. Something of similar size goes back to the Product Backlog.
• Cancel only in extreme cases. A sprint can be cancelled if its goal becomes obsolete, and "only the Product Owner has the authority to cancel the Sprint."^[5]

6. Scope changes in SAFe PI Planning and execution

Committed and uncommitted PI objectives

PI objectives "summarize the business and technical goals that teams and trains intend to achieve in the upcoming PI and are either committed or uncommitted."^[6] Uncommitted objectives "are not included in the team's commitment or counted against teams in the ART predictability measure", and they identify "work that can be variable within the scope of a PI."^[7] They are the train's built-in room for scope change: when unplanned work arrives, an uncommitted objective can give way before a committed one does.

The PI baseline

PI Planning ends with teams committing to a set of PI objectives.^[8] Take a snapshot of the plan at that moment: features per team and iteration, story points, dependencies and objectives. Every later change is measured against that snapshot, not against memory. Kendis guidance: never overwrite the baseline.

Unplanned work and mid-PI changes

Unplanned work is anything that enters the PI after the baseline: defects, urgent customer requests, regulatory changes. Handle it in one of three ways:

• Absorb it in capacity left free in planning.
• Swap it for an uncommitted objective or a lower-value feature, and record the removal.
• Escalate it to Business Owners when a committed objective is at risk.

ART Sync: the place to decide

SAFe describes the ART Sync as "the primary mechanism for the ART to align and adjust throughout the PI", and says it "enables coordinated adjustments to optimize the delivery of PI objectives."^[9] Put scope change on its agenda every time: what was added, removed or moved, and which dependencies broke.

Inspect and Adapt and the predictability measure

Inspect and Adapt looks at "what has actually happened over the last PI rather than what was supposed to happen."^[10] The ART predictability measure is the average of the teams' achievement scores for the PI.^[11] Uncommitted objectives "are excluded from the planned commitment" but are included in the actual business value achieved, and SAFe has said that reliable trains should operate in the 80 to 100 percent range.^[12] Review scope change alongside it: 70% predictability with 40% churn is a different problem from 70% with no change. For a full PI Planning walk-through, see the PI Planning guide.

7. How to measure scope change

Use points and feature counts together, read the trend over several sprints or PIs, and do not set a target of zero: a train that never changes scope is probably not learning. The agile metrics guide and the flow metrics guide cover the metrics to read alongside it.

8. A scope change process and checklist

1. Fix the baseline. Freeze the plan at the end of PI Planning or Sprint Planning: features, stories, points and committed objectives. Every later change is measured against it.
2. Log every request where the plan lives. New work enters the backlog in Jira or Azure DevOps, not a chat thread. Mark it as added after planning, and note who asked and why.
3. Assess the impact. Check the request against the Sprint Goal or PI objectives, the remaining capacity and any dependencies. Size it, and name what it would displace.
4. Decide at the right level. The Product Owner decides inside a sprint. Product Management and Business Owners decide on features and objectives, usually in the ART Sync.
5. Trade, do not just add. If something comes in, something of similar size goes out or moves to an uncommitted objective. Record the removal as well as the addition.
6. Update the plan and tell the people affected. Move the work on the board, update dates and dependencies, and tell any team that depends on the changed item.
7. Review the numbers on a cadence. Look at added, removed and moved scope at each sprint review and ART Sync, and at the PI level in Inspect and Adapt.

Checklist for each request:

• Does it serve the Sprint Goal or a PI objective?
• What is its size, and what will it displace?
• Which dependencies, teams or milestones does it affect? Check the program board.
• Does it create or change a risk? Log it with the ROAM method.

9. Worked example: scope change in one PI

Net growth suggests a stable plan; churn shows almost a third of planned scope was touched. In Inspect and Adapt, the train finds that both production fixes came from one service, and that two removed features were dropped to absorb them with no recorded decision. The improvement items: fix that service, and agree every swap in the ART Sync.

10. Common scope management mistakes

• No baseline. Nobody can prove what changed.
• Side-door work. Requests that skip the Product Owner stay invisible.
• Stacking. Adding without removing overloads the plan.
• Treating all change as bad. Teams then hide it.
• Reporting net growth only. Additions and removals cancel out and hide churn.

11. Tools for tracking scope changes

In Kendis, switching a PI board to Tracking captures a snapshot of the plan. Analytics shows story points added and removed since planning, per sprint, plus carry-over and unplanned work. On the solution board, the baseline is captured automatically when a linked PI board moves to Tracking, then a snapshot is taken at the end of every sprint and never overwritten. At the end of the PI, the End of Increment report compares committed features with final scope and shows how much unplanned work was absorbed.