Managing Project Scope Creep

   Agile Software Development

When building software, there is always a desire to want more. Whether that is better performance, more product features, or any other things that deviate from your original roadmap, your original project scope is now being challenged. Introducing any of these after an initial backlog has been created can cause a project to go over budget and/or beyond your initial timeframe if not properly managed.

Changes to your backlog or roadmap itself are not necessarily bad. Agile supports change. If data or customer feedback now shows that new features are more important to implement than others, they should be implemented. But, that also means a tough conversation needs to be had. Other features must be bumped, timelines must change, or resource allocation may need shifting.

Product Owner NEEDS more!

In software development, scope creep presents itself in many forms and from many different players. Often times, product owners get a bad rap for constantly wanting new stuff in addition to what was originally agreed upon. As a Product Owner, I admit, it’s easy to allow oneself to ask. The problem with asking is, a lot of times, the team doesn’t want to say no and disappoint, so they will take this on. The sheer act of asking can cause team members to context switch and scramble to provide estimates without truly thinking through the risks. By taking on a few extra features, you have potentially added more dependencies, introduced new bugs, and added more maintenance. But the PO isn’t the only guilty party.

Developers ENJOY more!

Developers regularly add scope to projects. This usually doesn’t come in the form of new features for the user, but more often as “nice to have” performance tweaks, changes, and upgrades to pieces of the tech stack. These “easy” changes, however, often result in endless refactoring. A good project manager usually can stay on top of some of these things. Other times, I find the changes are outside my level of expertise and only find out about them reactively. While the latest, greatest, fastest technology may be nice to have, implementing these changes mid-project or mid-sprint can cause havoc for other developers, the QA team, and potentially the business when things start to break. It is important that developers also have their enhancement requests prioritized against feature development, so that the tweaks can be implemented when most appropriate and while introducing the least amount of risk.

Stakeholders WANT more!

It is also common for stakeholders or business sponsors to want to change a project’s scope. Here is the setting: it is UAT time. A story was finished to implement a phone number field, with basic acceptance criteria of:

  • Must be numeric
  • Must be 10 characters

Before the feature is even fully demoed, someone chirps in with “Well we have talked about allowing international customers sometime down the road. How much work is it to change this to validate international numbers and select the country from a drop down?” Depending on the rank of the person who is requesting this, it’s easy to reply with a simple “that is easy enough!” But, even “easy enough” requires work from the PO, development, and QA teams at minimum. So, a better approach is to let the person know it can be discussed in planning, so that a priority can be added to the feature. If it truly needs to get done next, that is ok. Something else will need to be bumped to accommodate.

Design SEES more!

From user experience designers to graphic designers and everything in between, attention to detail is everything. They make good products great — from look and feel to usability. However, after design specs have been finished and approved, designers can have a tendency to continue to improve their creations. While everyone wants the best possible solution to be developed, at some point, a design has to quit changing. Even small tweaks in color, imagery, and spacing can lead to major refactoring efforts and added testing. Product Owners can easily be swayed by new designs, too. Having a project manager that can explain the level of effort for these changes and how it affects the timeline is key.

There will be times when requirements were left out of original design specs by accident and need to be added. This is especially true when a developer is blocked from delivering a given feature, because they do not understand how the user interface should look or behave. Modifying a mockup or comp to enable a developer to move forward is not be scope creep.

QA FINDS more!

A key role to any project team is the quality analysts and testers. They have the ability to find things that neither the developers nor the product owners planned for. This is awesome and helps save a lot of production issues upon release. While finding bugs pre-launch is tremendously important, it is also important for QA’s findings to be prioritized amongst new features. It is one thing if a piece of functionality doesn’t work as the acceptance criteria and requirements requested and needs a tweak. It is another when QA uncovers a large, underlying issue that was completely unknown to the team during regression/ end-to-end/ manual/ automated testing. Again, finding these issues early is great, but doesn’t necessarily mean just because it is a bug that it is more important than other new features. If the bug affects a a “must have” feature and requires a decent amount of developer work, a change in features or a shift in your timeline may be necessary.

Conclusion

There is always more you can add to any project. While scope creep presents challenges, it also enables important conversations to happen. Ensuring you have a strong project manager and product owner on your team to facilitate these discussions will help avoid missed “go live” dates, extraneous feature development, and blown budgets.


Like What You See?

Got any questions?