Scope Creep... It Happens To Us All

What the hell is scope creep, you ask? In the IT world it is used to describe the features and functionality that hangs on the fringe of requirements. It isn't a phrase that is used a lot when the project is on target, but when there is a risk of missing the deadline this phrase is tossed around a lot!

Basic requirements are necessary for any developer/tester to get an idea of the scope. Those requirements are what ground development because there will always be something cool to develop or a new feature that can be added. These requirements, which should be derived by a business need is what allows us to understand the needs of the business and satisfy their request. It also helps when there is a need to estimate the amount of time it will take to finish a project.

It seems simple enough, but when the basic requirements are missing or vague it becomes very easy for the scope of a project to loose focus. Without requirements the developer is free to code whatever they like, the tester doesn't have a clue what they should be testing, and Product keeps asking for more, which inevitably causes the project to loose scope and everyone who is a part of it to loose focus. Suddenly new functionality and enhancements are being added and so starts scope creep.

Here is a super simple look at how scope creep can be avoided from each perspective

Developers:
1) Before you code it, ask yourself, "Is this necessary to meet the requirement?"
2) Ignore the Product people buzzing in your ear about additional functionality. OK, maybe ignore is a little harsh. Entertain the idea and if it has merit, include the appropriate people to discuss it.

Testers:
1) Before you allow anything into test, require requirements!
2) The moment someone asks about adding a requirement ask yourself "Does this fit in the scope of the originally outlined project?"

Product:
1) The moment you think to yourself, "It would be nice if..." or "Can we also..."; shut up, unless you are willing to risk the project deadline not being met or are willing to trade out previously assigned and estimated functionality.

Back to the reason I originally started writing this:

Scope creep happens to all of us. Lemme give you a for instance. I recently sat down on my computer to work on a project on TrailCentral. On TrailCentral I assume the roles of Product, Developer, and Tester so you would think all three degrees of my personality would be on the same page, but you'll see that wasn't the case.

My original requirement was that I wanted to add the ability for people to sort the county trail list by name, city, difficulty, or ranking. Seems simple enough and I started to develop it. Since I recently started to program using AJAX, I decided that I would do this using AJAX. Seemed reasonable and well within the requirement so I kept on programming. Then I got an idea in my head. I thought it would be cool if visitors could use this page to get driving direction to each trail listed. Suddenly, my focus shifted and so started my scope creep.

I'm new to developing with AJAX and Javascript in general so this idea was good on paper, but I wasn't having much luck making it work. So instead of refocusing on the original requirement, I buried myself in trying to figure it out. I read all sorts of Google API documentation and read countless javascript tutorials. Two days later I continued to beat my head against the wall. Finally, the tester in me took over and I asked "Does what I'm trying to do fit the original scope of the project?" The answer was simply, "Hell no!"

So after two extra days of work I pulled all the code I was working on for the driving directions and I started testing the code I had added to allow users to sort the trail list, which was working a couple days ago with only a couple hours of work.

This is just an example of how scope creep happened to me. If it happens to me this easy when I have control of Product, Development, and Test; it is easy to understand how scope creep can work its way into projects that have multiple people working on the project.