It would be great if the problem always showed up as “scope giant leap,” wouldn’t it? You were planning to introduce one new feature for the next major release, but suddenly, somehow, your team finds itself working on seven features all at once—all while under the pressure of meeting the original release date. How did this happen? Simple: The process suffered a little bit of scope giant leap. Solution? That’s also simple: “Let’s just stop working on those extra six features that weren’t part of our original plan.”

But it never happens that way. That’s why it’s called scope creep. Just one little extra bit of work here, a tiny new commitment there, an innocent promise to add a few more whatchamacallits to that part of the product… and suddenly you’re short on resources, your development team is exhausted, and you’re in danger of missing an important deadline.

How can you keep this from happening? How can you prevent these little steps in the wrong direction, these seemingly innocent additional requests and promises, from adding up to a situation that overwhelms your team and slows your product’s progress?

Here are five ideas for combating scope creep. (And make no mistake: It is combat, because you’ll be fighting off these requests from everywhere, all the time.)

5 Ideas for Combating Scope Creep

1. Share your product roadmap (early, frequently, and with everyone involved).

If you build it correctly, your product roadmap will reflect both your strategic blueprint for the product and the realities your team will be working with in terms of resource, budget, and time constraints.

When everyone on your cross-functional team can see this high-level view of your product’s plans, priorities, and the strategic thinking behind it all, they will be more likely to understand how a request for what might seem to be a small additional bit of functionality will, in reality, have to disrupt some other part of the product’s progress.

So the more often you refer to and share your product roadmap with your organization, the clearer it will be to everyone that your finite resources for this project can’t afford scope creep.

2. Determine exactly what will constitute scope creep on your plan.

There are the obvious, easy-to-spot types of scope creep. One idea leads to another, and another, and another. You can’t do them all, not in the time you have or with the number of coders on your team. That’s scope creep everyone understands (even though some people will still try to persuade you to engage in it.)

But then there are subtler forms of scope creep. For example, “I know we agreed on doing basic platform support for our app’s first release—just to let users access it with iOS or Android—but maybe we should go for optimum support, and include Windows phones, a desktop version, etc.”

That’s scope creep, too, and it can be an enormous time and resource drain—even though it can sound like just a more robust version of your original plan.

One of the sneakiest ways that scope creep can slip in to your product development process is when it comes disguised as something else, like improving or “fleshing out” something you had already agreed upon.

So you’ve got to define for your team exactly what every step of your plan includes. Anything outside or in addition to that original plan? You can treat it as a change request and review it. But unless and until you give it the green light, it’s scope creep.

3. Build “scope monitoring” into your routine.

One of the easiest ways to fall victim to scope creep is by losing sight of your original strategic plan and the priorities you’ve set for your product. When that happens, and someone comes along and says, “Hey, maybe we could tell the developers to go for optimum platform support instead of our original basic plan,” you’re vulnerable to saying, “Sure. Why not?”

So refer regularly to your strategic plan. Pop open your product roadmap often, and share it with your team, so you can all stay connected to your original strategic thinking and regularly review that thinking against the day-to-day work you’re all engaged in. If that work is moving the plan you all agreed on down the field, great. If it’s not, you could be suffering scope creep.

4. Discourage your developers from over-delivering.

We know: This sounds awful. But as a product manager, one thing you should always remember is that your developers will often care deeply about the work they’re doing and will want it to be perfect. And in an ideal world—a world without budgets, or deadlines, or customers eagerly waiting for a finished product they can buy—you’d want your dev team building to perfection.

Unfortunately, though, you are always going to be working against the clock (and the accounting team), so you’ll need your developers to stop short of perfection and do the greatest work they can in the time they have allotted to them.

As difficult as it might sound, in some cases, your product will need to be only as good as your team can make it before launch. And if they want to make it better than that, well, that’s scope creep, too.

5. Make it easy to suggest and track great ideas for later.

One final suggestion for avoiding scope creep is to encourage your cross-functional team to contribute their product ideas and requests, and to make it as easy as you can for them to do so.

Then make a practice of periodically reviewing these ideas with your team, vetting and scoring them according to your key metrics, and, when it makes sense, updating your product roadmap to accommodate strategically viable items.

When you communicate to your executive stakeholders and the other teams across your company that you are open to product suggestions, but that those suggestions will have to wait their turn to get their fair hearings, you will be reinforcing to everyone in the organization your commitment to adhering to the scope of your product’s existing plan.

And that simple statement, along with the other tips here, can help you grow a company culture that understands the dangers of scope creep and actively discourages everyone from engaging in it.

Post Comments

7 Comments

  • Matt Harrell
    July 17, 2018 at 10:08 am

    Good stuff. What tools and processes do you recommend for monitoring bugs/sugs and making sure that the list doesn’t end up as bottomless pit?

  • Ben Miller
    July 17, 2018 at 4:45 pm

    Thanks for the comment Matt. We use Jira in conjunction with ProductPlan to keep track of our high-level goals as well as our lower-level initiatives (bug fixes/new features). We also reserve a lane on our roadmaps dedicated to bugs/minor improvements to make sure that we are actively making a dent in the list.

  • Jay
    July 19, 2018 at 7:36 am

    Ben, do you allow a set generic period per week (or sprint) for bug fixing, or do you push the features implementation back if the bugs list becomes substantial? I’d be interested to hear how you manage that.

  • Ben Miller
    July 19, 2018 at 9:28 am

    Thanks for the question Jay! For us, it all comes down to prioritization. We are committed to providing maximum customer value, so our backlog is prioritized around this key objective. Bug fixes certainly provide value, but if a new feature or initiative takes priority, then we will prioritize that in a given sprint. In that case, some low-priority bug fixes might get pushed to the next sprint. Note that this is not a traditional scrum approach, as most scrum teams have much less tolerance for keeping bug fixes in the backlog.

  • Srujana Jammalamadaka
    August 30, 2018 at 8:54 pm

    Thanks Ben for the article! Do you maintain separate roadmaps to showcase to different audience (strategy & development teams) ?

  • Ben Miller
    September 4, 2018 at 2:51 pm

    Hi Srujana. Thanks for the question. There are a few ways to answer this and it really depends on your organization (and how closely your teams work together). I’ve definitely seen individual teams create their own roadmaps with ProductPlan, and with features like Master Plans and Connections (dependencies), you can easily see how one team’s initiatives might affect those of another. On the other hand, if your teams collaborate frequently and you can keep the roadmap relatively lean, I might put both teams’ initiatives on the same roadmap. In ProductPlan, you can use tags to keep track of what each team is working on within the same roadmap. Or, you can reserve lanes for certain teams on the roadmap. Then if you want to filter things out and only view the initiatives of one team on the roadmap, you can use Custom Views. Hope this helps!

  • Anonymous
    September 4, 2018 at 4:31 pm

    Thanks Ben. This surely helps!

Leave a Comment

Your email address will not be published.