development speed - How do you prepare for feature creep?

How can I prepare for feature creep during preproduction?

Feature creep is when you are in the production phase and decide "It would be cool if this were a feature!" That adds n hours to the development time which were not accounted for, and unless you are Blizzard, do not have the time for. You cannot anticipate it being a cool feature during preproduction, because the feature is only discovered during production.

What can I do during preproduction to account for or prevent or prepare for feature creep?

Should I allow feature creep and cut less desired features? Or will this create a problems since the architecture is not designed for the new features? Should I say no features unless they fit into the existing architecture?

I know this is a broad question, but I hope it doesn't get closed as such. This is a major issue in game development, and should be considered.

Answer

While of course there are no hard rules when it comes to pre-production, there are a variety of heuristics to help. Some feature creep is natural and necessary - no plan survives first contact with reality, and you may not know what would be "cool" until you see it.

First, stage your development. Draw up your outline into a feature map, and then look for ways to group your features into testable iterations, each with a deadline. Once you begin an iteration, resist adding new features to it. Any unforeseen technical needs should of course go into the current iteration, but new ideas for features should go into a list for future consideration. You can then consider whether or not to add it to an iteration once the current one is complete.

This follows from the MoSCoW method, whereby you categorize features like so:

• Must haves - features that are vital for the current iteration to be stable, which is to say testable. If the iteration won't work without it, it's a must have.


• Should haves - features which will have to get done at some point, but if the iteration goes over time can be pushed into the very next iteration. Things required by a publisher, for example, could go here.


• Could have - features which you think may be important to the current iteration but could be dropped from the project. These are the all important polish features.


• Won't have - items that potentially feed the backlog, features identified in this iteration to be considered for later iterations.

Ideally you want development to be a progressive refinement, not all-or-nothing. Working within a final deadline the least important features ought to be pushed to the end, so whatever you don't get to will be stuff that's okay to cut. Make sure to estimate how long each feature will take to develop and refine those estimates as you go. Never compress the schedule to make room for more features. Resist pushing deadlines (iteration or final) into the future - move or cut features instead, if possible. If you're coming up to your deadline and the game is still an unsaleable mess, then you know it's time to seriously reevaluate your decisions and consider cannibalizing the project before it turns into a time/money pit.