What is a feature?
One of the most hard-to-define terms in Agile is ‘Feature’. Just asking how the word is used in various flavours of Agile or by different authors, the answer quickly becomes complicated:
- ‘Feature’ may be treated as synonymous with ‘Story’ – or with ‘Epic’ or ‘Theme’!
- ‘Feature’ may be used as a container-concept for a number of related user stories, though the relationship between these stories isn’t made very explicit.
- In Feature-Driven Development, a feature is similar in size and purpose to a user story (‘Calculate total price’ or ‘Validate user password’). However, it doesn’t need the user to be identified.
- Just occasionally a feature is a smaller component of a Story.
- A feature may also an attribute of a system, which users may or may not value.
And so on. In short, there is no agreed definition for the word ‘Feature’, and perhaps there never will be. After all, Agile is meant to be flexible, so perhaps its language need not be semantically precise, only pragmatically useful. Its purpose is to help us to deliver the required result, not to define the process in exquisite detail. So perhaps too earnest a search for precision is misplaced.
Or perhaps not. It’s unlikely that ‘Feature’ is going to go away, so it would help to be able to shepherd it into a more useful niche. In that case:
- To allow Feature to remain undefined would only perpetuate the confusion that already surrounds this term.
- To treat Feature as a synonym with Story, Epic or Theme would effectively eliminate it as a meaningful term while making the other terms more vague.
- It’s important not to treat it as uniquely associated with any particular development method, tool or technique.
- And finally, there are still gaps in the ‘standard’ Agile conceptual framework that could be usefully filled by such a helpful term.
Regarding the last of these points, the most obvious omission in Agile terminology seems to be the lack of a single term for a functional part of a system – a user component – where multiple stories intersect. For example:
- If you look at any piece of user-oriented software, a great deal of attention is paid to the user interface.
- You could, in principle, build a separate UI for each user function, but that would be confusing for users and very bad engineering.
- Especially in a commercial environment, one vital feature of any UI is its responsiveness to users with very different interests and very different skill levels.
- This is needed because such software needs to support many different stories – stories for complete beginners, stories for specialist users, stories for complete experts, and every skill combination in between.
- But precisely because it needs to work seamlessly for all user types and skill levels at the same time, this UI is far more than the sum of its user stories. It also needs to integrate all the different needs and uses into a single, unified interface.
- This demands a level of conceptualisation, design and engineering that goes beyond any single story.
- On the other hand, developing a single, integrated UI might not be justified by any single story – it may only be when all the stories are taken together and a single solution that deals with them all at once that it becomes a viable item.
- This then is what Agile201 defines as a Feature – a (conceptually) higher-level object that stands at the intersection of multiple user stories without being reducible to them.
One merit of this definition is that the idea that the system design might be ‘greater than the sum of its parts’ is re-introduced into Agile – the idea that there are some things about development that shouldn’t be explained in terms of the individual user. Maybe they could be, in some very indirect way, but they really shouldn’t, because that would be putting the Agile cart before the engineering horse.
In the case of a complex user interface, individual user classes really don’t care whether other user classes find the interface useful or easy to use. But someone has to care about general ease-of-use and the provision in simple form of a complex suite of capabilities – otherwise it won’t satisfy anyone. And that is the developer’s job – to create the whole that encompasses all the parts, without getting lost in them.
Hence the value of defining this entity by a new term. And Feature seems to do the trick. It’s quite like the FDD notion of a Feature, but I think it adds a little. And as other usages suggest, this places it somewhere between epics and user stories, but by adding the ‘sum of its parts’ element, it does not merely leave it sliding vaguely between them.
Features and back-end functions
This definition also allows a way in for all those back-end changes that need to be done, whether users want them or not –
- O/S changes.
- System management tooling.
- Development upgrades (e.g., move to a new IDE).
Like the UI, these components and functions exist largely for the sake of providing functionality, but they cannot be sensibly mapped onto any single area of activity. So they too are features.
The value of features
This definition does not imply that ‘technical’ or ‘architectural’ items are justified without regard for user or stakeholder value. In fact it clearly implies that it should always be possible to list the Stories that will be served by a given Feature. After all, there is no whole that is greater than the sum of its parts (in this case, Stories) if there are no identifiable parts!
So perhaps, whatever the syntax and format for Features, it should end with a ‘so that…’, just like a User Story. But in this case, the ‘so that’ should probably point not at an individual user or Story but at some higher functional goal – the reason the system needs to provide this kind of functionality at all, for example.