How Scope Works in Adaptive Projects
The question behind most of the confusion about adaptive scope is a fair one. If the requirements can change, what exactly is anybody agreeing to? A team that answers by saying it will work out what to build as it goes has described its method and not its commitment, and no sponsor has ever found that reassuring.
Something is always fixed. Adaptive delivery does not remove the boundary, it moves the boundary to a different level and changes what flexes inside it. Once that inversion is explicit, adaptive scope stops being a paradox and turns into a set of ordinary decisions.
Something is always fixed
On predictive work the feature set is fixed, and time and cost absorb the variation, at least in principle. On adaptive work the arrangement is usually the reverse: the date is fixed, the budget is fixed, and the feature set is what moves.
The third fixed thing is the one people forget, and it carries more weight than the other two. The outcome is fixed. A project exists to change something, and that intention does not flex because the feature list does. If a team can reprioritise its way to a release that does not achieve the outcome, the boundary was never drawn.
So three things are held and one moves. Writing all four down at the start, in six lines, does more for an adaptive project's scope discipline than any amount of backlog hygiene afterwards.
Where the boundary lives when the feature list moves
Section 2.2.3 of the PMBOK® Guide Eighth Edition covers how the scope work adapts to its context, and on adaptive delivery the adaptation is mostly about the level at which the boundary gets written.
The outcome statement is the boundary. It names who is affected, what changes for them, and how anyone will know. "Subscribers can change their own plan without calling us, and call volume for plan changes falls by half" is a boundary. "Improve the subscription experience" is not, because no release could fail it.
Out of scope still has to be said, and it carries two meanings that get run together. Not in this release is a sequencing statement, and it implies a later conversation. Not part of this project at all is a boundary statement, and it closes one. A backlog with no explicit exclusions collects requests indefinitely, and the people making them reasonably assume they are queued.
The controls that do the baseline's job
A scope baseline does three things on a predictive project: it defines what is included, it gives change something to be assessed against, and it gives acceptance something to test. Adaptive delivery needs all three and gets them from four mechanisms.
Order is the first. In an ordered backlog, priority is the control: nothing is refused outright, and everything below the line the team can reach is not being built. It only works when somebody with authority owns the order and the order is genuinely strict, because a backlog of forty items all marked high priority contains no control at all.
The definition of done is the second. It fixes the standard each item has to reach, which is the part of scope that predictive work carries in acceptance criteria. Without it, scope leaks downwards: items get declared complete at different levels of finish, and the work still outstanding is invisible.
Capacity is the third, and it is what makes the other two honest. A team with a known throughput and a fixed date has an arithmetic limit on what fits in the release, and that arithmetic is the conversation to have with a stakeholder who wants something added. Adding an item means naming the item it displaces.
Acceptance at the review is the fourth. Validating scope happens every cycle rather than once at the end, and the person accepting has to be somebody who can say this meets the outcome, not a delegate taking notes back to somebody who can.
Three weeks out, and the right argument
A publisher's platform team was replacing subscription management for a news product, with a price change going live on the first of April that the existing system could not handle. The date was immovable, the budget was a fixed team for five months, and the outcome ran to two sentences: subscribers manage their own plan changes without calling, and the contact centre's plan-change volume falls by half.
The out-of-scope list was written in the same hour and had two parts. Corporate and bulk accounts were not in this release, with a note that they would be looked at in the summer. Gift subscriptions were not part of the project at all, because the commercial team had decided to retire them.
In the first week of March the team was two items short of capacity. The conversation that followed took forty minutes and was about which self-service actions would ship in April and which would follow in May. It ended with the downgrade path shipping and the payment-method change deferred, because subscribers downgrading were driving most of the calls.
What made that conversation possible was the work done in week one. Nobody argued about the date, because the date was fixed and everybody knew why. Nobody argued about whether the release would still be worth having, because the outcome statement said what it had to achieve and the downgrade path was the item that achieved it. The argument was about sequence, which is the argument an adaptive project ought to be having three weeks out.
For a PMP® candidate, what helps is seeing that adaptive scope is controlled, so a situation describing an adaptive project with scope running away is describing a missing mechanism. Ask which of the four is absent. Is the order not strict? Is done undefined? Is capacity being ignored? Is nobody with authority accepting the work? Look for the control that has been left out, on the assumption that adaptive delivery has controls. Practising that where the team is working perfectly well and the scope is still moving is how a structured PMP exam preparation course teaches scope control.
Write the outcome statement first, and make it something a release could fail. Then write the two out-of-scope lists, this release and not at all, and send both to the people who will be asking. Most scope trouble on adaptive projects arrives because nobody wrote the second list, and requests that were never going to be built are sitting in a backlog looking like commitments.
Interested in going further?
An adaptive project with nothing fixed has no shape, and one with the wrong thing fixed has the same argument every March. Omega's PMP® Exam Preparation works through situations where scope has to be controlled without a baseline to control it against.
The Scope Performance Domain and its tailoring considerations are set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A103: Requirements vs Scope: Why the Difference Matters
A105: Scope Baseline Explained
A106: Product Backlog vs Project Scope
A102: The PMBOK 8 Scope Performance Domain: What It Really Covers
A107: Scope Creep vs Legitimate Change
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
