#featuritis

But what is feature creep?

                                 source: http://zanesafrit.typepad.com

Feature creep (aka scope creep, requirements creep or my personal favourite, ‘featuritis’) happens when a new function is requested AND either nothing is removed to make way for it, or the client drops a considerably smaller feature than the one they have just introduced.

And what is feature creep not?

Change in scope. It is crucial to realize that -especially in an agile environment- change is a substantial factor in projects and our goal is not to avoid but manage it. If a new feature comes in, another one with the same size should be removed or the team will not be able to deliver on time and budget.

Define the undefined. In agile project management we must first and foremost have a high-level understanding of what the project is about, defining the exact functions step-by-step as we progress throughout the project.

Why is it happening? 

Feature creep may be driven by a client's growing "wish list" or by developers or designers themselves, as they see opportunity for improving the product. Either way it mostly comes from a wrong assumption that more features will create happier customers.

                     Source: http://thelogbox.com/blog-feature_creep/

Why do we think more feature will help?

Users will need it

How do you know? Have you tested it with customers or are you guessing?

Competitors have it

It doesn’t mean you need it! If you copy your competitors’ bad features, you will deliver the same bad product - with delay.

It can be optional

If it’s optional, it’s not that important. If it’s not that important why do you want to implement it? Even optional features make users feel overwhelmed, let’s focus on delivering core values on an exceptional level.

How can you handle it?

To some extent, feature creep is natural, especially in agile environments where we don’t have hundreds of pages of project specification.

But if you want to keep this creep in control you basically have 3 options:

Say yes

Say no

Compromise

Say yes

The biggest problem with allowing feature creep is that it’s like the trojan horse. If you let one in, other soldiers will follow and believe me, it’s a lot harder to stop an army than a sole warrior.

Never allow a feature creep without a thorough evaluation with your team. Although you can say yes, if it doesn’t require more resource than a couple of hours, like a small change in design or smaller modifications in the code without changing the business logic.

Say no

Sometimes the best answer from the project’s perspective is ‘no’, but as an agency, it can be difficult or damaging to give a definite no to your client.

You have to say no when the feature is just unrealistically big and there is no way to squeeze it into the itinerary without risking the delivery. These are two very clear situations when saying no is the better choice but there are more sneaky ones, which you have to look out for.

Make an agreement

Aim for a win-win situation. Or rather a not-to-lose-too-much situation. The team and the client together might find another way that solves the original problem (the reason why the feature request came up) which takes less resource so it can be completed within the original project timeframe.

Of course each project manager has their own methods, so take a look at some other ways to avoid feature creep.

In the agile manifesto, one of the twelve principles is: “simplicity - the art of maximizing the amount of work not done - is essential” - always think of this before you want to add more features to your product.

All in all, there is no ultimate practice for handling feature creep but it’s always beneficial to think it through thoroughly before implementing a new feature and it’s always worth testing whether the problem you have been asked to solve really exists and whether the new feature really holds the solution.

So did you have any experience with feature creep so far? If so, share your insights and learning in the comments below.