What is a Feature?

Feature – a term with different meanings

There are various translations for the English term feature: Feature, characteristic, peculiarity, trait or characteristic.¹ Tall buildings, for example, are a feature in a skyline.²

In journalism, a feature is a form of presentation that includes features of a reportage and a documentary and is established in German-speaking countries in radio and newspapers and internationally also in TV.³

In the IT context, the BABOK Guide as a guide for business analysts defines features as “distinguishing characteristic of a solution that implements a cohesive set of requirements and which delivers value for a set of stakeholders”. It is therefore a particular characteristic of a software, hardware or service.

Distinction between feature and related terms

There is a whole range of terms that come up in the course of requirements engineering in product and software development and thus in the context of features. Often the exact delimitation is unclear: Is a feature bigger or smaller than an epic? What is a theme and what is a task? Below you will find “one” possible delimitation:

• In a literal sense, a user story describes a story of a user. It is a tool to describe desired functionalities of a system from the user’s point of view in a short, simple documentation.
• A task is an activity to implement a user story.
• An epic is a large, comprehensive use story. Size refers either to the effort required to implement the desired functionality or the ability to break the epic into meaningful, smaller use stories. In fact, there is no fixed measure of when to speak of one or the other.
• A theme is a grouping of user stories based on a common theme. It is a label and facilitates communication about content that has a common theme.

And how does a feature differentiate itself from these terms? Generally speaking, a feature is a characteristic feature or salient aspect of something. Specifically, it could highlight a functionality of a product that addresses a specific business value. Example: Charging a mobile phone by induction and not by means of a Europe-wide standardised connector.

If an epic describes what a user wants to achieve with a product, then the feature could be the description of the function that makes this possible. In that case, a feature would be smaller than an Epic. If, however, a feature describes what special characteristic a product has, then it would be larger than an Epic, as long as the latter merely describes a large, extensive user story. And last but not least, there are representatives who simply use both terms synonymously. Some tips can be derived from this ” tangled mess”:

Tips for dealing with features

The following tips can prove useful in the practice of product and software development when dealing with features:

• If you want to use both feature and epic as terminology, clearly define what you mean by this and which entity is larger.
• Alternatively, in the course of requirements engineering, you can dispense with one of the two terms (probably feature, as it is less clear and less frequently used).
• In itself, a backlog is simply a container in which work is collected and prioritised. In practice, it has proven useful not to manage themes as independent elements in backlogs. The same could be useful for features, especially if they are distinguishing characteristics of a solution that implement interrelated sets of requirements – which you can manage in the backlog. It is conceivable, however, that you could assign appropriate attributes to individual backlog items as needed.
• Use features as an instrument in product marketing or marketing. In this way, it becomes a label for a characteristic trait and possibly, in the sense of the Kano Model, a performance or even an enthusiasm factor.

Notes (some links German):

[1] Different translations
[2] Definition & Meaning
[3] The journalistic form for presentation

The SAFe framework, by the way, defines the term slightly differently: “A feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI)”.

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

Boost your backlog

The destructive path to requirements