What is scope creep?<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
What is scope creep in product management?<\/h2>\n\n\n\n
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. That, at least, is the theory. But, even in the best agile teams<\/a>, it can be very tempting to add to the scope of something if you\u2019re working on it anyway. Scope creep is also caused by others – internal stakeholders, external stakeholders, customers – people who aren\u2019t as close to the product as the teams responsible for delivering value and driving a product forward. They\u2019ll think that the product team can do something additional to a product or feature \u201cwhile they’re there\u201d. 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. <\/p>\n\n\n\n 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\u2019s goals, and be demoralizing for those involved. Ultimately, it can lead to project failure.<\/p>\n\n\n\n You\u2019ll 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. If you do it with your eyes wide open, then expanding a project\u2019s scope can sometimes be the right choice to make. Perhaps you open up some code and find it\u2019s a complete mess – but you have to leave that code better than you found it and you hadn\u2019t planned for the work. It may just be removing some excess lines or tidying up bits of code, but it\u2019s still scope creep and the team needs to be able to make judgment calls on how much extra work they can do. One classic example of scope creep is the development of an automated baggage handling system at Denver International Airport<\/a> 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. It\u2019s part of the job of a product manager to say no<\/a>, and you\u2019ll 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\u2019s 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<\/a> and here<\/a>.<\/p>\n\n\n\n You should let everyone know – and I mean everyone – why scope creep is damaging. I\u2019d like to leave you with something to think about, saying no is imperative for the success of the product you\u2019re 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.
In theory, there\u2019s 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<\/a> – 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\u2019s likely that the others will as well. What do I mean by this? If you cut a project\u2019s time, you won\u2019t be able to maintain its scope. If quality is paramount, then you might have to cut scope. Adding to a project\u2019s scope, then it will take longer to complete and cost more, or quality will suffer.<\/p>\n\n\n\nWhat causes scope creep?<\/h2>\n\n\n\n
Let\u2019s say you\u2019re 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\u2019s 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\u2019ve occasionally described product management as a bit like living with a devil on one shoulder and an angel on the other. They\u2019re certainly around when scope creep is in the air. One of them (and you decide which one) says: \u201cHey, this makes sense. While you’re working on this, you could add these other things. It\u2019s 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?.\u201d
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\u2019t fit into the time. And as long as they\u2019re having retros and moving forward nothing will get forgotten. <\/p>\n\n\n\n![\"A](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2022\/10\/Production-line-1-1024x792.png\")
<\/figure>\n\n\n\nWho else is responsible for scope creep?<\/h2>\n\n\n\n
Why is it a problem?<\/h2>\n\n\n\n
How can scope creep be prevented?<\/h2>\n\n\n\n
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\u2019t 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\u2019re not sidetracked away from the product\u2019s 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\u2019s also a good thing. Then, if someone wants to add a button somewhere, you\u2019ll 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\u2019re 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\u2019s started. Make them wait for the next sprint. If everyone understands how the release process works it shouldn\u2019t cause an issue.
Personally, I wouldn\u2019t bother to track scope creep. I\u2019ve 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\u2019s parameters or by changing the size of user stories.<\/p>\n\n\n\nCan scope creep ever be a good thing?<\/h2>\n\n\n\n
For this reason, I think it\u2019s always advisable to build a little flexibility into the time you spend on a sprint – because you risk compromising quality if you don\u2019t. Go into a sprint knowing you\u2019ve got the space for a bit of extra work should the need for it arise. <\/p>\n\n\n\nAn example of scope creep<\/h2>\n\n\n\n
I\u2019m 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\u2019t 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.<\/p>\n\n\n\nHow to push back politely – a two-pronged approach<\/h2>\n\n\n\n
1. Learn to say no<\/h3>\n\n\n\n
2. Educate<\/h3>\n\n\n\n
Here\u2019s a final summary to help you:<\/p>\n\n\n\n\n
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<\/a> and see how it connects to idea management and your roadmap.<\/p>\n\n\n
![\"Free](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2023\/04\/OKR-banner_Blogs-1280x300-1-1024x240.png\")
<\/a><\/figure>\n<\/div>","protected":false},"excerpt":{"rendered":"