Scope Creep: When Your Scope Is The Least of Your Problems

“A Wild Scope Creep Has Appeared!”

Dang it! That frightening beast has caught us by surprise once again.

Why does scope creep happen?

How could we have seen the scary scope monster creeping up on us?

What could we have done to prevent the appearance of this mythical creature?

Newsflash: scope creep cannot be prevented by only worrying about scope.

Scope Creep: The Problem Isn’t Your Scope

Let’s get one misconception out of the way: your scope is supposed to creep, at least when doing complex work.

Complex work means you can’t plan and predict everything before starting. It means you’re limited by the Fog of Beforehand: what you can know before beginning the work.

What you know before starting simply won’t cut it. Every step you take should help shape the way. There is no path to follow, you have to carve your own path and discover what’s necessary as you do the work.

With that misconception out of the way, scope creep doesn’t only happen because you can’t know the full scope before starting. Scope creep happens because you don’t know what you’re trying to make possible with that scope.

Read that sentence again. Does it still sound confusing?

Let’s try to rephrase it so it becomes clearer:

“Scope doesn't create value. What that scope makes possible is what creates value.”

It’s not about delivering the scope as promised. It’s about changing something for the person who uses the scope you’ve delivered. That’s what you should be worried about: is the scope doing the job it’s supposed to do? Don’t agonize over: is the scope exactly as we described it?

Scope is the means to an end.

Just like a comedian who tells a joke: delivering a feature is like telling a joke. It doesn’t matter unless it makes people laugh.

Scope only matters to the extent that scope makes a difference for your users or the business. And that’s why it should be anchored in their world, not in your imagination of what you believe they need.

Sounds easy, right? Well, it turns out it’s pretty tricky. Here’s a simple visualization that helps to explain why.

Endlessly revisiting and talking about the scope will actually make things more unclear. You’re injecting your scope with the Fog of Speculation. You’re injecting noise in requirements and making all kinds of assumptions. This happens because you’re trying to accommodate the sense of certainty your developers need to understand the complete behavior of the product.

To hammer the point home:

You’re introducing floating requirements to your scope. These are things that people said were necessary, but when you keep asking and prodding, you will get an unsatisfying answer. Some warning signs when you know this is happening:

“This is how it works in the old product.”

“We’re worried there will be problems if we don’t add this.”

“Sales tells us that the customer considers this a must-have.”

This is how you get floating requirements: stuff that we must deliver according to the scope but is not really necessary for our users or the business to meet their goals.

Unless you can provide a clear answer to what we’re trying to make possible with a specific requirement, it’s a floating requirement. We don’t know whether we really need it. It’s somebody’s assumption turned into a hard requirement that may turn out to be right or wrong.

That’s why we should err on the side of caution and not add things where we doubt they are necessary. If we don’t add something necessary, we will definitely hear it. If we add something unnecessary, it will likely linger around forever like a parasite because we suck at removing it.

Anchor Your Scope in the Reality of What You’re Trying To Make Possible

In short, when you have scope creep, the problem isn’t the scope but the fact you lack understanding of what you’re trying to enable with that scope. Or the fact there is disagreement among all stakeholders about what you’re attempting to make possible with that scope.

And that’s what we should focus our attention on. This problem is especially obvious during product rebuilds. We have an old product with a certain behavior and want to mimic the same behavior in our rebuild. The people who remember why we’ve made all the choices we’ve made in the old product are usually gone.

We must remind ourselves that the product's behavior exists to create value for its users that we can ultimately capture as business value. We should always be rooted in the progress we’re trying to grant to our users - what we’re trying to make possible for them when we add something to our product.

Because that ensures we’re anchored in getting the audience to laugh when we tell a joke instead of trying to tell as many jokes as possible without a clue of whether the audience will laugh.

So that’s why when you have scope creep, it’s usually the least of your problems. It means you lack understanding of what your product makes possible for the users and how it fits into their world, or there is disagreement among this understanding, and that’s why you should start there.

Don’t worry about the scope. Worry about the users and what the scope should make possible for them.

Keep your boots on the ground of the user, not the imaginary surface that we can perfectly plot in a scope document.

Remember, the map is not the terrain, and adhering to the scope isn’t what matters but staying anchored in what that scope should make possible.