Agile201 provides an alternative robust definition and explanation for how Features should be managed.
What is a Feature?
A Feature is a user component that is designed to support multiple individual stories, but is not asked for explicitly. For example, a user interface (UI) might be a Feature:
- A UI typically supports many stories.
- A UI has requirements of its own (for responsiveness, consistency, usability, integrity, etc.) that go beyond any single story it supports (or, typically user type of user skill level).
- Conflicts between the requirements of individual stories need to be managed by the implementation team.
- There may also be conflicts with stories from previous releases, which also have to be taken into account.
- Creating a Feature may also create additional back-end commitments for support, upgrades, and so on.
In other words, a Feature is related to at least one story, but it can’t be explained or justified by any particular story, or even the stories as a whole.
The risks of Feature development
Including Features in a release raises important concerns:
- The Feature demands attention and effort for its own sake, including a level of conceptualisation, design, implementation and testing that goes beyond any single story.
- The complexities of engineering the Feature to support many stories may not be justified by any particular story, so an additional dimension of complexity needs to be taken into account.
- When individual stories are developed, the team needs to make sure that the needs of other stories (past and present) are respected.
- When a Feature is modified or updated as part of a new story, it may be necessary to perform a kind of regression testing to check that the other stories it supports have not been disrupted.
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.
Translating Features into stories
In order to keep the development process as simple as possible, Features, like Epics, should be translated into one or more stories. In this case, it is a story that no single user, stakeholder or customer is asking for. So Feature-based stories fall into the category of Strategic stories.
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 (i.e., the stories is supports) 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.
For more on the Agile201 approach to Features, see here.