09Managing scope

In agile planning, scope is not carved in stone. That is often read as "scope is not managed", which is the opposite of the truth. When the date of a release is fixed, scope is the variable that absorbs uncertainty, so it needs more deliberate management, not less. Every change in scope changes what the release will contain or when it will arrive, and the stakeholders must know it.

One owner, one entry point

Scope decisions belong to the Product Owner, and they go through the ordered backlog. A request that reaches the team by any other route, such as a stakeholder asking a developer directly, is where uncontrolled scope begins. A single entry point does not mean refusing requests. It means every request is seen, weighed against the rest, and placed.

The release goal as a filter

For each new request, the first question is whether it serves the goal of the current release. If it does not, it goes to the backlog for a later release, and the requester is told when it is likely to come. The release goal makes "not now" a reasoned answer rather than a refusal.

When a request does serve the goal and the date is fixed, the rule is simple: something comes in only if something of similar size goes out. The feature buffer described in the previous section is what makes such exchanges possible without endangering the mandatory work.

Two kinds of scope growth

Scope grows in two ways, and both must be visible.

• Added scope. New requests from users, customers or the organisation.
• Discovered scope. Work that turns out to be bigger than estimated, usually during refinement.

Both move the scope line of the release burn-up chart, and both change the forecast. A team that tracks only added scope will be surprised by the second kind, and so will its stakeholders.

Communicate the impact

Every material change in scope produces an updated forecast, shared with the stakeholders: what changed, why, and what it does to the range or to the content of the release. Stakeholders should learn about a change in scope from the team, at the moment the decision is made, not by noticing later that a date has slipped.

Protect the sprint

New requests go to the backlog, not into the sprint in progress. The Sprint Goal protects the sprint. If a change makes the Sprint Goal obsolete, the sprint is cancelled and planned again, openly, rather than silently redirected.

Scope in a regulated product

In a regulated product, scope changes are not only a planning matter. Medical device standards and financial regulations alike require changes to be controlled, with their impact on risk and on verification assessed and recorded. A late addition also changes what the customer will have to validate. Here agile scope management meets what the PMBOK Guide calls integrated change control: the mechanism differs, but the discipline is the same.

The example

Midway through release 2, a blood establishment asks for autologous donations. Checked against the release goal, "a realistic day of whole blood collection", the request does not belong in this release. It goes to the backlog, and the customer is told in which release it is expected. Had it been urgent, it could have replaced the optional inventory cases in the feature buffer, with the exchange, its size and its effect on validation stated explicitly to every stakeholder concerned.