Requirements will change and grow over the course of any software project. This is a natural aspect of software development. In fact, if a project doesn’t experience some requirements evolution, the team likely is ignoring reality and risks releasing an irrelevant product. The prudent project manager anticipates and plans to accommodate some requirements growth.
Scope creep (also known as feature creep, requirements creep, featuritis, and creeping featurism), however, refers to the uncontrolled growth of functionality that the team attempts to stuff into an already-full project box. It doesn’t all fit. The continuing churn and expansion of the requirements, coupled with inadequate prioritization, makes it difficult to deliver the most important functionality on schedule. This demand for ever-increasing functionality leads to delays, quality problems, and misdirected energy.
Scope creep is one of the most pervasive challenges of software development. The techniques I described in the first two articles in this series (adapted from my book More about Software Requirements) provide several ways to define a project’s scope. In this final article in this series, I’ll give you some suggestions about how to manage the insidious scope creep.
The first step in controlling scope creep is to document a clearly stated and agreed upon scope for the project. Without a scope definition, how can you even tell if you’re experiencing scope creep? Project teams following an agile development life cycle should write a brief scope statement for each iteration. This helps make sure that everyone understands the goal of the iteration and what functionality the team will—and won’t—implement during that iteration.
An ill-defined scope boundary can have serious consequences. In one situation I know of, a customer had hired a package-solution vendor to migrate three sets of existing data into the new package. Partway through the project, the customer concluded that six additional data conversions were required. The customer felt that this additional work fell within the agreed-upon scope, but the vendor maintained that it was out of scope and demanded additional payment. This scope ambiguity, and the resulting conflict, was one factor that led to the project being cancelled and a lawsuit being filed. Not the desired outcome.
The second step for managing scope creep is for the business analyst or project manager to ask “Is this in scope?” whenever someone proposes some additional product capability. This could be a new or extended use case, a set of functional requirements, another user story, or a new feature or report. Note that the project scope could also encompass activities and deliverables besides the software products themselves. Perhaps your customers suddenly decide they want an online tutorial to help users learn the new system. This doesn’t change the software deliverables, but it certainly expands the scope of the overall project.
There are three possible answers to the question, “Is this in scope?” If the new capability is clearly in scope for the next release, the team needs to address it. If it’s clearly out of scope, the team does not need to address it, at least not now. They might schedule the new capability for a later release.
Sometimes, though, the requested functionality lies outside the scope as it’s currently defined, but it’s such a good idea that the management sponsor should expand the project scope to accommodate it. Less frequently, a proposed change could even modify the strategic product vision in some fundamental way. The question to consider is whether the proposal to expand the scope of the current release will significantly enhance the success of that release.
Electing to increase project scope is a business decision. When weighing whether to increase project scope, the key stakeholders need to consider cost, risk, schedule, and market or business implications. This demands negotiation between the project manager, management sponsor, and other key stakeholders to determine how best to handle the scope alteration. Referring to my three-level model of business, user, and functional requirements, the stakeholders must decide whether proposed changes in user or functional requirements will become the project manager’s responsibility through a scope expansion (Figure 1).
Following are some possible strategies for accommodating a scope increase:
- Defer some lower-priority or less time-critical functionality that was planned for the current release or iteration to make room for the proposed scope additions.
- Obtain additional development staff to handle the additional work.
- Obtain additional funding, perhaps to pay overtime (OK, this is just a little joke), outsource some work, or leverage productivity tools.
- Extend the schedule for the current release to accommodate the extra functionality. (This is not a joke.)
- Compromise on quality by doing a hasty job that you’ll need to repair later on (not your best option).
Increasing the project’s scope—or, even more profoundly, the product vision—always has a price. The people who are paying for the project must make a considered decision as to which scope management strategy is most appropriate in each situation. The objective is always to deliver the maximum customer value as soon as possible, while achieving the defined business objectives and success criteria, within the existing constraints.
There’s no point in pretending the project team can implement an ever-increasing quantity of functionality without paying a price. In addition, it’s always prudent to anticipate a certain amount of scope growth over the course of the project. A savvy project manager will incorporate contingency buffers into project plans so the team can accommodate some scope growth without demolishing its schedule commitments. This isn’t simply padding or a fudge factor. Thoughtful contingency buffers are simply a sensible way to deal with the reality that things change and projects grow.
Effective scope management requires several conditions be met:
- The requirements must be prioritized so that the decision makers can agree upon the capabilities to include in each release or iteration, and so they can evaluate change requests against the priorities of unimplemented requirements in the backlog.
- The size of the requirements must be evaluated so that the team has an approximate idea of how much effort it will take to implement them.
- The team must know its average productivity (or velocity, in agile terms) so it can judge how many requirements or user stories it can implement and verify per unit time.
- The team must assess the impact of change requests they have a good understanding of what it will cost to implement each one.
- The decision makers need to be identified and their decision-making process established so they can efficiently decide to modify the scope when appropriate.
Don’t be victimized by the specter of creeping scope or attempt in vain to suppress change. Instead, establish a clear scope definition early in the project and use a practical change control process to cope with the inevitable—and often beneficial—requirements evolution.
Check out Part 1, Defining Project Scope: Context and Use Case Diagrams
Check out Part 2, Defining Project Scope: Feature Levels and System Events
Learn how product development teams can leverage analytics to improve efficiency and quality in “The Essential Guide to Software Development Team Metrics.”