What Is Scope Creep and How To Stop It

Scope creep can be the bane of a product manager’s life. It might come from a bit of late feedback from a high-profile customer, the sudden realization that altering the piece of code you wanted to change will have an immense knock-on effect on the rest of your app, or even a disagreement between stakeholders over a product’s direction. 

Wherever and whoever the question or extra information comes from, it means that the scope of your project is vulnerable to change.

In this article we will look at everything you need to know about scope creep, we will cover:

• What is scope creep?
• What is scope creep in product management?
• What causes scope creep?
• Who is responsible for scope creep?
• Why is it a problem?
• How can it be prevented?
• Can it ever be a good thing?
• Examples of scope creep
• How to stop scope creep

What is scope creep?

Scope creep, in product management, is used to describe changes, extensions, and or uncontrolled growth to the scope of work once a project has begun. It is believed to have a negative impact on the success of a project. It can happen when the project isn’t well-defined or documented.

What is scope creep in product management?

Scope creep is a term that comes from waterfall project management, where development is sequential and linear. Within waterfall projects, one phase needs to be completed before the next one can start. 

In theory, there’s no room for scope creep in an agile product management practice. Whereas in agile product management, you take an iterative approach and divide work into short sprints, incorporating feedback with each iteration. Any additional scope should be incorporated into the next sprint.

An agile project is bound by three vectors – time, cost, and scope – the iron triangle of constraints. The goal of a project is to deliver on all these different vectors, and they all have an impact on quality. So if one has to give, then it’s likely that the others will as well. What do I mean by this? If you cut a project’s time, you won’t be able to maintain its scope. If quality is paramount, then you might have to cut scope. Adding to a project’s scope, then it will take longer to complete and cost more, or quality will suffer.

What causes scope creep?

That, at least, is the theory. But, even in the best agile teams, it can be very tempting to add to the scope of something if you’re working on it anyway. 

Let’s say you’re working on the checkout flow for your app. At first, you think it will be a simple checkout flow, but then you start to look at other checkout flows. And, even though your checkout project has already started, you realize that there’s something else you could do so that people can share their purchase after checkout, and that would be much better for the product. So you add it to the project, and you then have a bit of scope creep.

I’ve occasionally described product management as a bit like living with a devil on one shoulder and an angel on the other. They’re certainly around when scope creep is in the air. One of them (and you decide which one) says: “Hey, this makes sense. While you’re working on this, you could add these other things. It’s going to save everyone time, and the boss has been asking for this feature forever. It’s just one button. How hard can it be?.”

You usually see scope creep in agile projects because the teams involved have started to treat the project as a series of mini waterfall projects which are limited by scope rather than time. What they should do instead is break the project up into time-bound sprints, and carry over to the next sprint whatever work there is that doesn’t fit into the time. And as long as they’re having retros and moving forward nothing will get forgotten. 

Who else is responsible for scope creep?

Scope creep is also caused by others – internal stakeholders, external stakeholders, customers – people who aren’t as close to the product as the teams responsible for delivering value and driving a product forward. They’ll think that the product team can do something additional to a product or feature “while they’re there”. But accommodating the wishes of others can push a project back a little more each time, and, before you know it, what was originally a three-week sprint has taken three months to complete. 

Why is it a problem?

Back to our three constraints on quality – time, cost, and scope. Changing one has an impact on the others. Scope creep can drain resources and lead to disagreements over the direction. It can distract from the product’s goals, and be demoralizing for those involved. Ultimately, it can lead to project failure.

How can scope creep be prevented?

You’ll read that scope creep comes about because of weak leadership, the involvement of too many stakeholders, poorly defined objectives, poor estimation, poor communication, and so on. There are weak areas in any organization so the key I believe, to managing, even preventing, scope creep is to get everyone to understand how your release process works.

Instead of trying to do everything in one project, product managers should aim to get the team comfortable with the idea of opening and closing the same areas in different sprints. Your app doesn’t have surgical scars, you should be able to open it, dig into the code, close it and move to release relatively easily. Doing this keeps the project on track, it helps to ensure that you’re not sidetracked away from the product’s goals and that you stay agile and iterate on feedback. 

This does mean that the codebase has to be kept tidy so that everyone knows what to look for and where there are likely to be problems. But that’s also a good thing. Then, if someone wants to add a button somewhere, you’ll know whether or not it will have an impact on other areas of your site.

There are other practical steps you can take. For example, you should make sure everyone around the team understands what scope creep is and that they’re not afraid to call it out when they see it. In my experience, equipping your team with the vocabulary to push back, whether through example or through coaching, helps enormously to prevent scope creep.

Laying down some hard rules can also help. For example, make it a rule that no one can add any scope to a sprint once it’s started. Make them wait for the next sprint. If everyone understands how the release process works it shouldn’t cause an issue. 

Personally, I wouldn’t bother to track scope creep. I’ve seen some teams get tied up in managing the velocity of their work and tracking metrics, but it has the potential to be a metric that can be gamed by expanding a project’s parameters or by changing the size of user stories.

Can scope creep ever be a good thing?

If you do it with your eyes wide open, then expanding a project’s scope can sometimes be the right choice to make. Perhaps you open up some code and find it’s a complete mess – but you have to leave that code better than you found it and you hadn’t planned for the work. It may just be removing some excess lines or tidying up bits of code, but it’s still scope creep and the team needs to be able to make judgment calls on how much extra work they can do.  

For this reason, I think it’s always advisable to build a little flexibility into the time you spend on a sprint – because you risk compromising quality if you don’t. Go into a sprint knowing you’ve got the space for a bit of extra work should the need for it arise. 

An example of scope creep

One classic example of scope creep is the development of an automated baggage handling system at Denver International Airport in the 1990s. It was a project that took in over 2,000 design changes during its development and finished 16 months late, 250% over budget.

I’m sure we can all come up with instances of scope creep from our own experience. For example, I was once part of a team at a software company with a big FMCG client that wanted us to build a custom internal employee incentivization program. The idea was that employees had a digital paper doll they could dress up. The doll was displayed on a screen, and every time you did something for the company you earned a sock or a mitten, and so on. 

It started as a simple digital idea. But we kept taking additional requirements from the company and we didn’t push back, so the list of what the company wanted the program to achieve just kept growing. Every time we met with the board it turned into a bigger project. 

What started as an incentive scheme for one division became a scheme that management wanted to scale across all its other divisions. What worked as an incentive scheme for, say, the laundry division would also have to be modified and piloted for, say, the ice cream division, and so on and so on. We did all this work, and the thing never launched.

How to push back politely – a two-pronged approach

1. Learn to say no

It’s part of the job of a product manager to say no, and you’ll have to find effective ways of doing it in order to manage scope creep. There are plenty of resources and frameworks available that teach you how to do this – generally, they encompass active listening, exploration, and understanding of the stakeholder’s problem so that you can say no with empathy and maintain a positive relationship. These resources might be useful, to learn how to say no read them here and here.

2. Educate

You should let everyone know – and I mean everyone – why scope creep is damaging.

Here’s a final summary to help you:

• Scope creep will always have an impact somewhere, whether on the product or the people in the business. Every project is bound by three constraints, time, cost, and scope. Changing any one of these constraints will have an impact on quality.
• No one wants to work in an environment where teams are demoralized or feel that they’re working towards the same goal. Ultimately this is the environment that scope creep will create.
• If work is completed in agile sprints, teach others in the organization what this means. They should understand that whatever isn’t included in the current sprint won’t be forgotten.

I’d like to leave you with something to think about, saying no is imperative for the success of the product you’re building. But, no doesn’t necessarily mean not ever, it could mean not right now – gathering feedback throughout the entire process will help you iterate your product.

Ensuring you have a great process for gathering feedback will make the wider team feel more confident that they are being listened to and might make saying no that bit easier. If you would like to know more about gathering feedback the right way then you need to check out our customer feedback portal and see how it connects to idea management and your roadmap.