Daily news, dev blogs, and stories from Game Developer straight to your inbox
Killing Feature Creep Without Ever Saying No
Why is your favorite game late? Why is your own project slipping? Chances are good that one of the reasons is an acute case of feature creep. Feature creep -- requirements changing during development -- is a major risk for virtually every game project. If uncontrolled, changing requirements can overwhelm even the best-planned effort, and quickly put your project in trouble. By completely understanding your original design, all change requests, and the people involved, you can avoid feature creep without ever saying 'No' to a request.
October 20, 2000
25 Min Read
Why is your favorite game late? Why is your own project slipping? Chances are good that one of the reasons is an acute case of feature creep. Feature creep -- requirements changing during development -- is a major risk for virtually every game project. Various project size changes lead to increased complexity, effort, schedule, and budget. Given the average complexity of a game project, it's safe to say that almost all of us have experienced feature creep. If uncontrolled, changing requirements can overwhelm even the best-planned effort, and quickly put your project in trouble.
Case Study: Too Eager to Please
You are probably involved with managing projects because you are good with people. You probably like to make people happy. That same attribute that serves you well, however, can also get you into big trouble. Take, for example, one of my first projects.
My company was hired to build a creativity-based kids' product for a major toy corporation. Eager to please a new client, we committed to a fairly short schedule and an aggressive list of features. The design wasn't finalized before we started development, and I didn't resist any feature requests. I didn't want the client to think we couldn't deliver what they wanted. After all, none of the individual requests was anything very complicated. More image processing effects, fancy scene transitions, a rollover help system -- anything they wanted, we could do without a problem. Until, that is, the engineers on the team started to raise concerns that they were running out of time to get everything implemented.
In my initial scheduling, I hadn't planned on anything that wasn't in the original specification. I had failed to realize that the original specification was filled with design holes that would require filling with new dialog boxes, help messages, error messages, and other completely necessary features. Each day seemed to add "just a small request," until we realized we would be late for our first major milestone. In an effort to get the project back on track, I tried to work with the client to cut features from the product. This only managed to upset the client, without achieving enough significant cuts to get the project back on track. Ultimately, we shipped the project several weeks late to a client that was less than completely satisfied.
Wanting to avoid my pain, you may be tempted to simply freeze your design and ban feature requests from your project. But when it comes to changing requirements, abstinence is not the answer. In a rapidly changing industry, designs must evolve during development for a product to stay on the cutting edge. When you get feedback from early users such as beta testers, you need to pay attention to the valuable input you are getting. Your goal is to balance flexibility with sound project management. It's not easy, but it can be done.
Case Study: Do You Want to Bet One Month's Salary?
After the failure described above, I was determined to do a better job of preventing feature creep. I was convinced I could do it without being completely inflexible and upsetting the client. At the beginning of the project, however, it looked like my goal would be tough to achieve. The client was asking for a lot of features, and on a very short schedule.
After my previous experience, one thing was clear to me: it's better to have the tough discussions about features at the beginning of the project instead of toward the end of the project. Convinced by a colleague that it was better to do no business than bad business, I risked upsetting the client by raising the feature and schedule mismatch in our first meeting. I realized that the client would not simply want to hear me whine, but would want a solution. Even better would be to offer the client multiple alternative solutions. Armed with a feature list, a short schedule, and a good technical lead that could estimate accurately, I did a preliminary schedule.
At this early stage, most estimates were rough, and covered a range from a low estimate to a high estimate. I understood the product design and it seemed solid, but knew that unexpected issues would come up during development, so I added some extra room to the schedule for an unknown task. I then created three feature lists. We could build the product with all of the features in the long list if we used all the low estimates. Trimming a few features, we could build the medium list if we used an average of the low and high estimates. Trimming a few more features, we could build the short list if we used all the high estimates.
I presented the three feature lists to the client, and tried to explain the different levels of risk in terms they could understand. "If we build the shortest list of features, I am confident we will be on schedule. I'm so confident, that I would bet one month of my salary that we deliver on schedule. In the medium list of features, I would still take that bet, but only if I got 2 to 1 odds. And I wouldn't bet at any odds that we could build the long list of features on schedule." The client opted for the middle set of features, which is what I expected.
In the early meetings to work out design details, I kept an eye on the list of features to make sure it wasn't growing too large. But I also suggested features that I thought would be helpful to the product without adding a lot of work. I knew that I had a little bit of room in the schedule, and I wanted to use that room to build the best product I could for the client. This helped earn the trust of the client. We both felt that we had the same goal: build the best product we can within the required short schedule.
During development, the client requested many minor changes. A few of them I agreed to, since I knew that they really didn't have a big effect on the development effort, and would help the product. But most of the changes I resisted. If I could find an alternative solution, I would present that to the client. They almost always accepted the alternative happily. If I couldn't find an alternative and knew the change would add risk to the project, I simply explained that fact. Given the short schedule and everyone's desire to ship on time, the client understood why I was resisting changes. Since I had offered some features during design and agreed to some changes, the client understood that I had the product's interest at heart.
This project was completed on time and on budget. While not every conversation with the client was easy, in the end we all still respected each other and liked working together. I had learned an important lesson: I had controlled feature creep and also managed to keep the client happy.
Communication and discipline are the keys to successfully managing changing requirements. By completely understanding your original design, all change requests, and the people involved, you can avoid feature creep without ever saying 'No' to a request.
Establish yourself and your team as experts, and recognize the expertise of others. If you have experience and skills producing other similar products, gently try to help everyone you are working with understand your expertise. Obviously, you don't want to appear egotistical and immediately alienate your partners -- publishers, users, teammates, management, and others. But your goal is to have others recognize the expertise you have, so they trust your opinion and input.
Similarly, ask your partners about their past experiences and recognize their expertise. Recognizing the skills that everyone brings to the design table will help all parties trust each other and communicate better.
Understand the project priorities. Everyone wants everything in a product: great performance, a huge list of awesome features, a stable program -- all at a low price and on a short schedule. But ultimately choices will have to be made. Is stability more important than performance? Are features more important than finishing by a certain date? Understanding the project priorities will help you know which feature requests make sense, and which will undermine the product goals.
You may have to use tact to learn the project priorities without upsetting people. Once I realized how important it was to understand a project's priorities, I started asking project stakeholders their priorities at the beginning of projects. To my surprise, I ended up confusing and upsetting a few people. I explained that, of course, we would do our best to deliver all the features performing well, on time and budget, without any bugs. But if push came to shove, I wanted to know if stability was more or less important than performance, or if both should take a back seat to adding one more feature. One client said she was confused, and expected to be involved in those decisions. I tried to explain that the team members would be making dozens of minor choices every day -- which algorithm to use, how many debugging checks to add to the code, and similar choices -- and that neither she nor I would be involved in every one of those minor implementation choices. The client partially understood, but the conversation ended with her still expressing concern that she would be left out of decisions.
In hindsight, I completely understood the client's concern. They absolutely should be involved in any major decisions, and a question about priorities can make someone feel like they won't be involved. But it's still very valuable to know the project priorities. Since my experience, I've taken a more subtle approach to asking about project priorities. I start by explaining my own priorities. My first priority is a stable product with a very low number of bugs at any time. I know this is ultimately the only way to develop a quality product on time. As I talk about my priorities, I gauge the client's reaction as I raise each aspect of the product. Do they enthusiastically agree when I say that stability is a priority? Do they not seem to care when I say memory usage is a lesser concern? Learn the project priorities without making stakeholders feel like they must choose between important aspects of the product, or will be left out of any important decisions.
Plan for the unexpected. Some amount of flexibility to respond to new information during development will greatly help your product. Set up the project so that you have some room to adjust to unexpected requests and problems. Obviously, you must balance the pressure to reduce budgets and schedules with the need to leave room in the development effort. Remember that doing no business is better than doing bad business, and having no room to respond to any feature requests at all is usually bad business.
Get a clear, detailed, unambiguous specification before you agree on a schedule and budget. Schedule, budget, and design must ultimately all work with each other for the project to be successful. If you are not in control of these parameters, at least one must be flexible before you come to agreement on a schedule and budget for the project. For example, you might agree to a schedule and budget, and then design a product that fits those parameters. You can only set up a successful project if you understand in detail what you will be building.
Work through the design as thoroughly as you can, as early as you can. Understand where the design is working, and where it needs more attention. Raise design issues early in the process, preferably before the project budget and schedule are set. If the people you are working with are reasonable, they will respect you for raising concerns early. In one case, I raised concerns that a voice-recognition feature was not designed into the product at all, but merely mentioned occasionally. The client agreed and confessed that the voice recognition was an unrealistic hope added to the design document at the last minute. Discovering that design issue early on likely avoided several changes to the design as the product was built.
Discuss your expectations for change requests and use a formal change control process. When will change requests be made, and by whom? Who approves the change requests? Will the team get a chance to comment on change requests before they are approved? When will users and/or important parties see the product? Will there still be time to make changes once they give their feedback? How will you settle any schedule or budget adjustments that are necessary in order to implement a change? It's always best to agree on the answers to these questions before you are in the middle of a feature request discussion. When in doubt, use a formal change-control process.
A good change control process can go a long way towards controlling feature requests, and typically involves these steps:
Key team members review requested changes. Make sure all of your leads, from quality assurance to art director, have a chance to review a request.
Determine the costs and benefits to the product quality, usability, schedule, budget, performance, complexity, documentation, testing, and so on.
Identify and propose alternatives (more about this below).
Accept or reject the change and notify everyone involved.
Ensure the changes are documented and implemented properly.
The amount of formality required will vary greatly from organization to organization and team to team, depending on team size, team structure, the parties and personalities involved in the project. When in doubt, use more formality than you think you will need. A little extra overhead can bring a huge reduction in risk. And it's always easier to loosen up a formal system than to formalize a loose system.
Beware the insider. Even if you diligently watch every feature request coming in to your team, your project may still be suffering from feature creep. Often your own development team will add features that aren't specified, or develop a feature to a higher level than needed.
On a project for a major new client, a developer decided to implement a dynamic panning system for character dialogue. Depending on where the character was on screen, the audio would be panned to the left or right channel. Was it a good effect? Absolutely! Was it necessary? Absolutely not. Did it adversely affect the schedule? Yes.
Whether motivated by pride, interest in the technology, or competition, many engineers are routinely guilty of "gold-plating" an application. In addition to managing requests coming from outside the team, you need to check in regularly with the team to ensure that they understand the required features, and are not going overboard in their efforts. Looking at the product regularly will help you be aware of what's getting done, and whether it's necessary. Better yet, have a strong technical lead who can closely monitor what team members are doing and ensure that it is appropriate for the product and schedule. In a well-run project, a leader is closely involved with the developers and is involved with all decisions about which features get implemented, and when.
Say "yes" when you can. Agree to any changes that don't increase your work or project risk significantly. Pick your battles and don't argue the minor points, even if you don't completely agree with a minor change. However, watch for a pattern of minor changes that will add up to trouble, and resist any change that won't help the product.
While developing a product recently, I was asked if we could speed up the gameplay in a fishing activity. Knowing that this would help the product and not be a complicated change, I happily agreed. The game was improved, and the client understood that I had the best interest of the product in mind. Therefore, the client was not suspicious of my motives when I later resisted a more significant change that would have added a lot of risk to the project.
Be straightforward and true to your word. Deliver information and some form of the product early to establish as much trust and confidence as possible. When you describe where the product is coming along well and where it is having trouble, and then deliver a version that matches, your partners will understand that you assess and describe the state of the product accurately to them. Demonstrate that you want to deliver as much high-quality work as possible. I usually try to deliver a very early prototype that demonstrates product navigation as soon as possible. I will then follow with one or more pre-alphas, before finally shipping the standard major milestones: alpha, beta, and final.
Seek to understand first. Be sure you understand the change request completely. It doesn't do anyone any good to respond rashly to something you don't completely understand. I have received feedback on a major milestone and worried about changes that I thought made no sense at all. Once my colleagues calmed me down, I called the client and calmly asked to discuss the feedback. It turned out that I completely misunderstood the change requests, and thus I was very glad I had not sent an e-mail objecting to their ideas.
Offer alternatives whenever possible. You may be able to make a different change from the one being requested. Better yet, your alternative may be less costly to the project and just as effective as the original request. To offer successful alternatives, you need to understand thoroughly the underlying problem and the motivation behind the change request.
I had a client who asked to make a whole set of buttons larger. Concerned that an overcrowded screen would result, I asked for the reason behind the request. The client explained that they thought the user might not notice that the buttons were clickable. Rather than increasing the size of the buttons, we brightened the buttons' rollover pictures, and added a rollover mouse cursor. The result: neither of these changes was difficult or resulted in further complications, the product was improved, and the client's problem was solved.
Explain your reasons for resisting a change. You need to speak for the sake of the project. When you explain that you are hesitant to agree to a request because it adds a high level of risk to the project, everyone understands and usually agrees. It usually helps to acknowledge that an idea might help the product, while maintaining your position that you would rather not implement the change in the interest of maintaining the schedule.
Wait for user feedback. Particularly if you think the current design is correct, suggest that you wait for user testing feedback before making the design change. User feedback can often help settle any debate about a program's design.
I recently had an issue involving a button that returned the user to a product's main screen. The client was concerned that the button would not be intuitive and that users would not know to use that button to return to the main screen. Since I was more optimistic, and we were within a few weeks of user testing, I suggested that we wait and see if users understood the button. No one had trouble understanding that the button returned the user to the main screen, and the issue was settled without changing the product.
There's always version 2. It's easier for a client to hear, "That would make a great addition in version 2," than "We can't do that now". Particularly if you know future versions will be delivered, suggest that a change wait for the next version of the program, when you can plan for the work and schedule accordingly. Someone may be willing to wait for a feature, but not willing to give it up entirely.
Don't use your only bullet. If you tell someone you can't do a feature because it can't be done in the operating system, and then they give you a piece of code that shows it can be done, you're in a jam. You would have no credibility if you suddenly started talking about some other reason you couldn't do the change. As long as the justifications are real, give multiple reasons why you are hesitant. If those reasons can be addressed, be prepared to implement the change.
Let's make a deal. One way for people to quickly understand the impact of a feature request is to suggest a feature trade. In order to add something to the product and stay on schedule, you have to give something up.
I was once asked to add multiple colors and fonts to the text editor in a creativity program. I explained that I could do that, but in order to stay on schedule, I would need to cut the ability to move and resize pictures. Given this information, the client decided that a single font editor would be just fine.
Use your superiors; let someone else be the bad guy. It's important that people working together are on positive terms. Rapport is important. If something unpleasant must be said or done, let your boss play the bad guy and do it for you. Don't let a disagreement lead to a personal issue between you and any of your partners on the project.
When all else fails, say you can't agree to the requested change without adjusting schedule, budget, or both. Leave the decision up to the people in power requesting the change. Try to avoid a plain "no" whenever possible. People need to have choices and feel in control. Think about the change request and possible alternatives. Assess the schedule and budget impact of the various possibilities. Present different options to the person requesting the change, and let them decide what to do.
Don't use schedule time twice. If your schedule does slip due to feature creep or any other reason, people who want to add features will see an opportunity. "Since we're adding time to the schedule, let's add that feature we wanted." The temptation to add features is obvious, but the irony and foolishness of such an approach should be equally obvious. You're adding time to the schedule because you need that time to develop the features you already have specified. Don't add "just enough" time, and then immediately take that time away by adding more features.
Beat the Creep
You can have a flexible design and still ship on time. Design as thoroughly as you can up front, and plan for unexpected changes. Understand the people and priorities of your project, and access every change request. Clearly communicate about alternatives and the impact of each potential change. Only implement the changes that will truly help the product. Either make room for the new feature by getting rid of another one, or adding schedule time as a last resort. If you keep feature creep under control, your product design can improve as you build without missing the schedule.
Many cases of feature creep have been documented in articles available on Gamasutra. Some of these include:
Because it was so easy to add commands to the scripting language, the programmer would usually oblige. We added two to three commands to the scripting language daily. In the end, we had over 400 script commands total. So, while we did experience some feature creep, and though these last minute details did push our release date back even farther, we were able to add a lot of detail near the end of Sin's development cycle.
The Psychology of Artists and Programmers
This article describes a classic case of "developer gold-plating":
Game programmers are very competitive with each other, and the score is often measured in features, not in depth of game experience. For example, I know high-profile coders that don't respect Myst because it isn't technically innovative. Lots of artists that I know think Myst is a successful game that has a powerful impact on its users. This extreme focus on the technical abilities of the game leads to ever-greater features, sometimes even at the expense of the overall game experience.
Once we were comfortable with all the additions we made, we decided to try a small public beta test of the Enhancement Pack. This was an extremely successful thing to do, it turned out, as much helpful commentary came back from those involved. In fact, we ran into feature creep quite a lot at the end of this burst of activity, which mainly came from the extremely helpful and interesting suggestions we got from the beta testers. We did suffer a bit of criticism from the existing H2 community over the Enhancement Pack, because we originally predicted that we'd be done just after Christmas. That was a bit optimistic as it turned out, but our mistake was in announcing an approximate release date for the Enhancement Pack. The Heretic II community was not pleased about this, and made no bones about announcing it.
Tiberian Sun started strong and we developed a robust and large feature set we intended to fulfill. The project started smoothly, but as we progressed, the temptation to add new features not included in the design document grew. These features arose out of shortfalls in the original design, omissions from the original design, and input from fans.
Everybody stresses the importance of working off of a design document and not deviating from it. Unfortunately, this just isn't realistic since every product evolves during the course of development and sometimes the original design proves to be lacking. A team has to be able to incorporate new ideas during development if the final project is to be better. However, the flip side of this idea is that the team must be able to cut features diplomatically when it is in the best interest of the project …
Looking back at the project, I think we could have been more aggressive in cutting or changing certain features to make sure their returns were really worth the development investment. I'm a firm believer in the idea that less is more and that fewer but more fully developed features are the way to go. If a feature isn't amazing, you should cut it or make damn sure it becomes amazing before you ship the product.
Drakan was originally slated for release in February 1999, but ended up being released six months later. Even with careful scheduling and task planning, we failed to meet the final deadlines. Part of the problem was that we didn't account for the time the team would spend creating versions of the game for E3 and for magazine and Internet demos. Each demo pulled nearly two weeks of time away from our normally scheduled tasks. The majority of the scheduling problems were due to feature creep and other improvements that were considered necessary during development.
Development was basically broken into two phases. The first eight months were spent developing the graphics engine, application architecture, and assorted tools. We then took a step back and put together a rough project schedule that covered the remaining ten months. At that point we confirmed what we suspected all along: our design was too ambitious, and we were going to miss our deadline by several months. With our set-in-concrete-change-it-and-die ship date, we had no choice but to reduce the feature set and focus on core gameplay. This resulted in some difficult late-night sessions between our team and upper management, as we negotiated which features could be cut and still have a viable game. We ended up breaking features into three categories: required, optional, and later version, with the optional features prioritized by importance to gameplay. While the team was disappointed to let go of so many features, in the end we implemented most of the optional ones, and many others we hadn't considered at the time. Our tight schedule simply didn't allow for much feature creep, and our focus on core gameplay helped us ship on time.
Read more about:Features
About the Author(s)
Scott Crabtree joined Intel in 2005 as an Engineering Manager leading a team focused on the video game industry. He has been making video games for over 20 years, and professionally leading the design and development of games and game technology for over 10 years. Scott started as a Software Engineer and has served often as a Game Designer, Producer, Executive Producer, and Entrepreneur. Scott has spoken at the Game Developer's Conference, been published on Gamasutra.com, and served as technical editor for Andrew Rollings and Ernest Adams on Game Design. Scott is proud to have worked on game development with companies including Microsoft, Mattel, Disney, and more. His most recent published games include Yourself!Fitness and NRL Rugby League for PS2, Xbox, and PC, and Gem Drop and Shape Shifter for mobile phones.
You May Also Like
Accessibility and fancy footwork with GLYDR's John Warren - Game Developer Podcast ep. 40Feb 28, 2024
Exploring the 2024 State of the Game Industry report - Game Developer Podcast ep. 39Feb 2, 2024
Phantom inspiration and the ethical auteur with Xalavier Nelson Jr.Dec 8, 2023
Designing Killer Queen: from playground experiment to modern arcade sensationOct 18, 2023
Get daily news, dev blogs, and stories from Game Developer straight to your inbox
Subscribe to Game Developer Newsletters to stay caught up with the latest news, design insights, marketing tips, and more