Chapter 11 – Agile PM
11.3. Scope in Agile
Robert Merrill (2017), a Senior Business Analyst at the University of Wisconsin-Madison, and an Agile coach, advises taking a three-part approach to scope on Agile projects, determining the following:
- Minimum viable features—If we can’t deliver this much within schedule and budget constraints, the project should be cancelled.
- Features we can’t think about now—Although these might be featuring the client wants, they are not something we can create, and so we can’t waste time and mental energy thinking about them.
- Everything else—This is our unpredictability buffer, which we maintain to protect schedule and budget.
Note that these categories are not frozen; they can be changed during each iteration planning cycle. Scope in an Agile project is variable, but carefully and visibly managed.
The Agile Perspective on Scope Creep
Agile welcomes changes to product requirements even late in the development process. Indeed, the founders of Agile made an openness to late-breaking changes, which is one of their Principles Behind the Agile Manifesto.
In this environment of constant iterations and revisions, Agile developers have a different perspective on scope creep (product owner changes the requirements, and something new gets added). A blog post for OptiSol (2015) spells out some ways to identify what is and isn’t scope creep in Agile. Making changes “before the team has started to think about the details” would not be considered scope creep in Agile, nor would replacing one feature with another, as long as the new feature doesn’t add new work for the team. However, swapping a new feature for a feature that is already complete is definitely a form of scope creep, because it creates new work. The same is true of replacing a small feature with something more complex (OptiSol, 2015).
