Are you a product manager dealing with the development of new apps?
One of the hazards of the job is a tendency for scope creep to make an appearance at some point. It often comes in a little at a time, then suddenly in the form of a major change in direction.
As users of the agile development methodology, we’re used to things changing on a software build — it happens no matter which method you favor, but agile by its very nature was designed to allow for short “sprints” of work which provide for the project to be regularly reassessed and any needed changes made.
That’s not to say you won’t find scope creep happening on an agile project too. It does, and given the nature of agile, sometimes it’s more difficult to pick out upfront.
What Is Scope Creep?
Simply put, scope creep is when your project grows beyond what was initially anticipated while still in progress. This can lead to extended timelines and added cost to finish a project, though it’s not always a bad thing.
Sometimes scope creep is a good indicator that valuable insights are being made as you progress which wasn’t necessarily apparent when you began the project. Agile method projects are great for this because sprints allow room for changes without blowing out the budget on rework.
Scope creep can happen for a number of reasons, but here are some of the most common in app development:
- Changes have happened in the market, such as moves made by competitors which mean different features are needed.
- The scope was not very well-defined in the first place, perhaps with a “we’ll know it when we see it’ view. This can lead to the “never ending project”, which continues to grow.
- Suggestions for changes based on user feedback.
- Stakeholder requests, especially if you’re in a larger enterprise where different department heads have skin in the game as far as the new software goes.
Unexpected complexities or dependencies becoming apparent as the development unfolds.
Whatever the cause of scope creep, you should know how to identify it and how to assess the impact of it on your desired outcomes. You don’t want your release delayed, unnecessary iterations to be made or for your software to be put at risk. Identifying scope creep as early as possible gives you the option of making decisions before a project has blown out completely.
Source: VireoMD
Is It Scope Creep?
Sometimes as the product manager, it’s not always apparent that requests are amounting to scope creep, especially if you’re having an agile product build done. You might assume that requests will fit in with a new sprint and sometimes that’s absolutely right, so how will you know that scope creep is happening?
Here are a few points which can indicate scope creep:
Changes Part-way into a Story
You’re requesting changes after the development team has already begun development of the story your changes affect. (In agile, a “story” is a tool used to create a description of a software feature from the perspective of the end user.
Depending on how far into development they are and what your request entails, it could amount to scope creep. If you’re not sure, just ask, the project manager will tell you if that request that you think sounds simple actually involves major work.
On the flipside, in the agile world (and this is an advantage over other methods!), it’s not scope creep if you’re making the request before work has begun on the story. Planned work is always laid out at a high level across the project, but specific details are left until work is planned on the individual story.
It’s Outside of Planned Contingency
On most agile projects, experienced developers will tell you to allow around 20% contingency for newly-discovered scope deemed necessary for the final product. If you’re requesting changes which blow this out, you might have some serious scope creep happening. (Though of course, with the sprint-driven nature of agile projects, you may need to ask if your requests are going beyond that 20%).
You’re Swapping in New Work
This scenario would be scope creep if that new work is proposed to replace work that has already been completed. This might be seen if there is some kind of market change and stakeholders decide “actually, we don’t want feature X anymore, can we replace is with Y?” The time has already been used to develop feature X so developing Y is a new request which could either add time or have to be traded against other future features.
You’re Requesting to Swap in Something Bigger
If you or your stakeholders decide that you’d actually like feature Z instead of Y after all, and Z happens to be a much bigger deal to build, then you’ve probably got scope creep. Replacing a simpler feature with something more complicated will likely be one of those scenarios that extend your build time and probably your costs too.
This is another case where your developers should be there to give you pointers. A seemingly simple feature idea may involve some complicated background work.
How to Manage Scope Creep
Scope creep which blows out budgets or adds a lot of time to software release dates brings headaches to product managers as well as software developers. If you own the project, part of your responsibility is staying on-time and on-budget, right?
This means it’s in the best interests of the project to assess and manage any scope creep. Sometimes you’re really going to need that extra scope, but sometimes it comes down to managing expectations and getting out an app which meets the end goals of the business.
Here’s how you could manage (or minimize) scope creep:
Be Clear About Requirements
Before going into any building project, make sure you have clearly defined your goals for the software. Communicate your vision and expectations as simply and clearly as possible with your development team and try to avoid the “we’ll know it when we see it” scenario. This helps your developers to be able to advise you and know at least a rough outline of where they’re going.
Manage Those Stakeholders
Easier said than done sometimes, we know! In larger companies, there are often competing priorities and agendas. Cultivating good relationships with your stakeholders is a good start, allowing you to understand where they’re coming from and have frank discussions about why something needs to be in-scope. Fact-based solutions tend to be your friend here — is it going to blow the budget or time constraints?
Ask Plenty of Questions
Your development team is there to help you. Ask questions and get their views on ideas and requests. They should be able to help you decide whether something is blowing scope.
Keep Everyone in the Loop
Most good development teams will use some kind of project management software which includes keeping you as the product manager in the loop. Use it to stay on top of what is happening and to keep any stakeholders informed. It helps to keep scope manageable if everyone understands where things are at and what the process is for any changes.
Final Thoughts
Scope creep is a hazard of any development project and is something that product managers are going to have to deal with at some point.
In the agile world, people often make the mistake of thinking that there won’t be any such thing as scope creep, but the reality is it exists just as it does for any other methodology.
Keys to managing it include communicating very clearly with your development team and managing your stakeholders well. Keeping scope under control often comes down to managing those relationships.
Koombea provides agile development expertise and years of experience helping product managers manage scope. Talk to us about your needs today.
