Scope vs. Impact

In software development, project managers are often tasked with building or modifying features that add scope to an application. Scope is something that most project managers are painfully aware of, as it frequently increases costs and complexity. In an Agile environment, new features are broken down, refined, estimated, and then developed. Typically, these new features necessitate new code, which restricts their impact on the site. During architecture and development, though, a good Agile team will reuse code whenever possible. Object-oriented programming allows for the reuse or extension of existing code to handle new situations in the future. If code is reused from other features, however, a change to any of these features can significantly impact the work required to implement them.

Let’s back up, though. What is scope?

The Project Management Institute (PMI) defines scope as:

Everything required to complete a project, including tasks, time, and resources.

While this may sound generic, remember that PMI is not specific to software development. PMI provides guidelines for project management.

According to the Institute of Electrical and Electronics Engineers (IEEE), the scope is refined in this manner:

The scope covers the entire software lifecycle, from inception to retirement, managed through defined processes and utilizing appropriate methods and tools. The goal is to apply systematic, measurable, and repeatable approaches to develop high-quality software products on time and within budget.

This is better, but to continue this exercise, we need to narrow the scope down to the team level. The only way to do this is to allow the development team to define what the scope truly is.

When determining the scope of a new or changing feature, the team must note what is being added, any dependencies, how it will be used, and who will use it. Typically, these tasks are performed during the feature’s architecture, but the team should review them during the refinement and estimation phases. Why? Because some developers may have insight into better, more efficient ways to implement the changes. Notably, it is advisable to document the scope early.

So what does this have to do with the impact? What is impact?

After a scope is defined, the impact can be determined by identifying the areas of an application or feature that run the risk of being affected by changes. If the addition of code is remote (i.e., it doesn’t touch existing functionality), then the impact would be negligible. If the new feature borrows or extends code from another feature, it is essential to note this for future development. A change to one can have a significant impact on everything it touches.

A good analogy of scope vs. impact is:

Let’s say NASA has determined an asteroid is going to impact Baltimore.

First, the asteroid should be taken into account. Where is it striking? How large is it? What is its composition?

The scope of the impact is the specific point where the asteroid strikes the city. The impact can be derived from the size and composition.

If the asteroid were striking M&T Stadium but were only a few meters across, it would undoubtedly destroy parts of the stadium, but the impact would likely be localized.

If the asteroid were the size of the stadium itself, however, the impact would be significantly more severe. Depending on the consistency of the asteroid (i.e., Ice versus Iron), the collateral damage can change considerably.