What are some ways to prevent or mitigate feature creep?
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Thank you for using the term "feature creep," which actually differs slightly from but usually is more accurate than the more commonly used "requirements creep." In order to reduce feature creep, it might help to define it and understand where it comes from.
Feature creep is the accumulation of small changes to the established feature requirements that can potentially push a project off track. Conventional wisdom says that feature creep is caused by unclear requirements. The testing community says creep comes from requirements which are not testable, usually because they are ambiguous or otherwise unclear. I'm going to disagree and state quite explicitly that most feature creep is caused by requirements that are wrong or overlooked.
What changes is not so much the requirements as the awareness of requirements that could and should have been identified already but were not. Proposed features keep changing in response to the changed awareness of the requirements. To better understand why I say this, we need to take a look at two very different views of requirements.
A widely held model that is institutionalized in the International Institute of Business Analysis's Business Analysis Body of Knowledge (BABOK) is that high-level objectives decompose into detailed solution requirements features for a product, system or software that when implemented will presumably achieve the objectives. According to this model, the only difference between business and product requirements is the level of detail.
Thus, the BABOK model says high-level vague requirements are business requirements and detailed requirements are product requirements. Conventional business analysis generally assumes that business objectives are easily identified. The bulk of business analysis work focuses on defining the features of the product that are required to meet those objectives. The model further says that design is the engineering or technical detail describing how to construct the product.
I disagree. I find that much of the feature creep I see is created by flaws in the BABOK model. As an alternative, I talk about "REAL business requirements," which I define as business deliverable whats that provide value by achieving objectives when satisfied by product, system or software hows. The whats are observable business deliverables (in the broadest sense -- at work and personal, for profit and not for profit) that when completed achieve the objectives and thereby provide needed value. REAL business requirements are from the perspective of and in the language of the businesses and stakeholders, which includes users and customers.
REAL business requirements usually can be accomplished in many possible different ways. A product, system or software is a high-level design of one of those possible ways how to accomplish the REAL business requirements' whats. In this view, product feature requirements are from the perspective of and in the language of the product. Rather than being a decomposition into different levels of detail, product requirements are qualitatively different from and represent a response to REAL business requirements. As in the BABOK model, engineering and technical design then describe how to construct the product, but unlike the BABOK model, the product is also a design how.
A product and its features only provide value to the extent their implementation satisfies REAL business requirements. My analysis finds that while product requirements' clarity certainly is important, a lot of feature creep comes from product requirements that fail to satisfy REAL business requirements, regardless of how clear they are. Usually the REAL business requirements have not been defined adequately because conventional wisdom mistakenly thinks product requirements are the only requirements.
REAL business requirements are not high-level and vague, but like product requirements, they need to be defined in detail. No matter how far down in detail they are driven, REAL business requirements remain business deliverable whats that provide value when met and never turn into product hows. Defining the REAL business requirements deliverable whats in adequate detail is the secret to designing product requirements hows that do not creep so much.
What is a test case? What is a requirement?
Problem pyramid discovering REAL software requirements
Is a requirements freeze in a software project a bad idea?
Four tips for gathering requirements for the new Business Analyst
Dig Deeper on Software Requirements Management
Related Q&A from Robin F. Goldsmith
Using a WBS can help make a big task like requirements easier. Expert Robin Goldsmith explains how developers and testers can make the most of this ...continue reading
How do you engage high-level business executives in the process of writing business requirements?continue reading
Why don't users seem to appreciate typical software QA testing status reports?continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.