How to manage scope creep in Agile / Scrum
OK we’ve all heard of the scope creep bogeyman. He haunts the dreams of young impressionable software developers around the world. He prowls the streets at night, looking for weary project managers to pounce on.
We’ve all heard the horror stories of big brave projects, brimming with exciting scope items and starry-eyed business analysts, that got gradually covered with the horrible growing fungus of scope creep until they weakened and sank into a deep bog, never to emerge. How does agile deal with this monster? This article will explain how to manage scope creep in agile.
Scope creep is a bogeyman and we don’t have to worry about it
I’m going to take the unusual path of saying that scope creep is a bogeyman. And like all bogeymen, it only exists to the extent that you allow it to exist. And it will only ruin your projects to the extent that you believe it can. If you are doing agile, and you understand scope, and your product owner understands scope, you don’t really have to worry about scope creep.
We don’t have to worry about scope creep if we understand scope
Scrum has some problems, but scope management is one of its great strengths. The rules and artifacts around scope in Scrum are not perfect but pretty close. A lot of people don’t follow them properly but that’s not a problem with Scrum, it’s a problem with its implementations. Let’s review how scope works in Scrum quickly.
The product owner is responsible for scope. The product owner puts scope into a Product Backlog, in the form of Product Backlog Items.
These can be anything: ideas, user stories, prototypes, documents, pictures, whatever you like. At some point they will go through some analysis and clarification, referred to as Backlog Refinement, so that they are ready to go into a sprint. This refinement will usually turn them into user stories in Story Normal Form with Acceptance Criteria, but Scrum does not require this. A user story is just one particular type of Product Backlog Item).
At the start of a sprint, the development team will pick up a set of Product Backlog Items and move them from the Product Backlog into the Sprint Backlog. Those items are the work for the sprint.
How to manage scope creep in Agile
So it’s quite simple: the product owner puts scope into the Product Backlog, the development team pulls scope out of the product backlog (and delivers them). What’s to stop the product owner putting endless amounts of scope into the Product Backlog? Nothing whatsoever. “But oh no, that’s scope creep! We won’t be able to deliver it all! We will all fall in a heap and everything will go to hell!”. Really? Why?
This view arises from a fundamental misconception: the Product Backlog is not a list of “things that are in scope for this project and must be delivered within the agreed time and budget or this project has failed”.
Waterfall projects do have a list like that: it’s just called the scope list. Scope items in Waterfall are part of the iron triangle (scope, cost, time, see my article on project success). You are supposed to deliver all of them or you have failed. A product backlog is completely different: it is just a list of ideas about things that someone might work on.
Scope doesn’t need to be fixed: in fact, scope should not be fixed
Waterfall projects generally fix scope up front, and then figure out the time and money required to deliver that scope. And then try to deliver everything in scope within the time and money constraints.
Scope usually gets added at some point and the project gets into trouble, because it is usually not given more money to deliver the extra scope.
Agile projects tend to fix cost up front. That is, “we’re going to spend $1 million dollars on this project and see what we get”. This is actually not the best way to do it but it is better than the Waterfall way. And then see what scope we can deliver as time and money go by.
This idea of no fixed scope might sound like chaos and madness, but it is the opposite. Fixing your scope up front is madness.
The fact is, your initial scope list will probably have things in it that are a bad idea, and will probably be missing things that are a good idea. It is foolishness of the highest order to insist that your initial scope list should all be delivered by hook or by crook, and that nothing go into it, even if it’s a good idea, unless it goes in via a convoluted and painful Scope Change Control process.
It doesn’t matter if your scope creeps and creeps
So the PO can put however much scope they like into the Product Backlog. It won’t all get done, and that’s fine. This isn’t “scope creep”, this is “I’ve thought of an idea”. It is scope that might get moved into a Sprint Backlog, and might get worked on by a team, and might not. And that’s ok. Scope Creep kills Waterfall projects because “scope” means “it must get built” (even if it’s a bad idea).
Having said that, a smart PO will not fill their Product Backlog with endless lists of scope items. That is because these items are all essentially waste, or “Muda” in Lean terminology. They are “inventory”. Stuff that is sitting around, not going anywhere, not being used by customers.
The best backlog is a light one. A backlog just big enough for a good stream of work to the development team each sprint. And with maybe a few extra ideas in case the team has a strong sprint or some extra capacity.
A sign of an inexperienced Product Owner is that they put every idea they come up with into the backlog, and never take things out of the backlog. Some ideas you should just quietly sweep under the rug.
Agile projects can actually suffer from scope creep if you let them
Scope creep can be a problem for agile if the product owner is naive about how this works. When new items go into the backlog, they need to go in an order of priority. The Product Backlog is an ordered list of backlog items. If a new item goes into the backlog, above other items, it is effectively “pushing them out of the way”.
If the initial funding was sufficient only to deliver the initial scope items (based on whatever estimations were done around those items), then adding new items with a higher priority will mean those now low-priority items will not get done. The product owner needs to understand and accept this!
If you have a product owner who doesn’t seem to understand this, and assumes that everything that goes into the backlog will magically get done, you can try suggesting a “one in one out” rule.
Every backlog item that goes in means another one (usually the one at the bottom of the list) falls out the bottom and doesn’t get done. This is a simplification but it’s a good way to start framing the discussion.
Question:
Have you had a bad experience with scope creep? On a Waterfall (or an Agile!) project? Tell me about it in the comments!
