Creating an app or website is an enormously exciting process. It's normal for there to be functional and design requirements, and it's also normal for those requirements to change. However, when the requirements of a project continuously increase without documentation, risk management or discussion, a project will become difficult to manage. This situation is called, 'scope creep'. Scope creep isn't limited just to software development, but regardless of the final product, scope creep can be a nightmare for all involved and even cause the product to fail.
When a project's requirements grow unchecked, this increases the development time. In turn, this increases the cost of implementation and muddies the waters of what is to be delivered and why. Put simply: too many feature requests can derail a project.
Why does it happen
During development of a software application, product owners and other stakeholders can often get very enthusiastic about the power of the system being made. This can lead to various ideas or additions to the product. Another way this can happen is when necessary features were missed during scope or not realised until development starts.
Product designers and project managers naturally want to ensure that product owners are happy with the outcome of development, so the first impulse to these change requests is to simply accept them and add them onto the existing stack of work. This is a mistake, regardless of how big the ticket is, because any change to the implementation will affect the backlog, time, cost and final deliverable. The habit of allowing change requests to slide in unchecked will eventually lead to scope creep and, eventually, a project in need of rescue.
3 ways to avoid scope creep
Nominate a product owner
It's normal for products to have multiple stakeholders involved in the scoping and development process, and because they are human beings, they'll have opinions and attitudes which are uniquely theirs. Whilst everyone is entitled to their opinions, it's important to nominate a product owner for the purposes of the project who gets to make the call on what features stay in and what features will have to wait. This also helps the product designers and squad leads because it makes communication faster and easier.
Continuously review the backlog and track changes
Any changes which are made to the project should be logged and tracked in the backlog. The backlog is the ordered list of everything that is needed in a given product, and is the source of truth for the developers and designers. If it isn't documented in the backlog, then it will not be built. At WorkingMouse, we provide an estimate against this backlog before development starts so product owners can get a scientific breakdown of the time and costs to create an application. Feature requests or changes mean that the backlog needs to be updated, with the circumstances of the update recorded. In turn, this also changes the time and cost estimate.
Provide an estimate for changes
Depending of the scale of the change request, a Squad Lead is able to provide a product owner a few options for development. The first is to extend development time to allow for the implementation of the new ticket. The second is to swap the new ticket with an old one, essentially just re-allocating existing resources. The third option is to delay the development of the new feature until a later build, reserving it for a future scope.
This may be a tough decision and will depend on the project's budget, deadline and, of course, any technical hurdles the developers and designers may have to overcome in order to make the feature a reality. A good squad lead will confer with their team and provide an honest explanation of the options and their consequences before development of that feature starts.
Scope creep can sneak up on project managers and product owners alike, and once it starts, it can be difficult to steer a project back on track. The best way to deal with scope creep is to prevent it from happening in the first place, by being aware of the signs, keeping a project schedule and ensuring that the backlog is properly maintained throughout development.
