Thanks for creeping up on us...

The definition of the term "Feature Creep" (aka "requirements creep" or "scope creep") refers to the tendency for product or project requirements to multiply during development beyond its original scope, leading to features that weren't originally planned.

Why does Feature Creep happen?

It happens because typical waterfall models of software design rarely offer the client glimpses into the product as it progresses to its final stages. When the client does see some form of prototype, they actually have a bunch of requirements brought to life. This challenges the way the client and the developers originally envisioned the solution and the way they thought the solution would be used. Also at this time the developers and client are together (another rare occurrence with a waterfall type model). A situation has now just been created where clients can use the product and provide instant feedback. This feedback sparks a dialogue and this dialogue starts the creative process, which accelerates idea creation, discussion, rejection and acceptance and maybe even innovation. Thus new features and new versions of existing features tend to 'creep' into the plan because original requirements and newly discussed ideas are qualified further through actual experience with a solution.

Is this bad?

Typically, a project scope increase consists of either new products or new features to an already approved product designs, without corresponding increases in resources, schedule, or budget. As a result, the project team risks drifting away from its original purpose and scope into unplanned additions. As the scope of a project grows, more tasks must be completed within the budget and schedule originally designed for a smaller set of tasks. Thus, scope creep can result in a project team overrunning its original budget and schedule.

Feature creep is bad when it isn't controlled, but when controlled it can be powerful. Markets and competitors change so quickly, why wouldn't you want to drop a lower business value feature for something more impactful? Isn't the goal to provide the best solution you can to the end user, in the time they expect it? If what you are working on isn't the most important thing, why continue working on it? If using a prototype has provided clarity to your objective, why not refine your objective?

So Feature Creep is good?

We think that when using agile and lean methodologies for web development, feature creep can be a good thing. If you have a qualifying practice in your process, you prioritize features according to your measurement of value, and your specification is aligned with your objectives, then the limiting factors become the cost and completion time. You should be able to evaluate your work at any stage and further refine and change your solution to ensure you accomplish your objectives, provided you have clarity in the effects of deviating from an agreed plan.

[Source: Wikipedia]

I didn't understand a word you just said. Can you draw me a picture?

Sure, I think Dilbert really captures the humorous aspects of feature creep.

Dilbert Does Feature Creep

[Source: Dilbert]

We work on our process so that we can control things like feature creep, and avoid our company fulfilling cartoons like this: