If I look at the definition that we provide for a Feature on ADM Help I see this
Feature. A service that fulfills a stakeholder's needs. Each feature description should include its underlying benefit and acceptance criteria. Features can be split as necessary to be delivered by a single agile release train. In ALM Octane, features can be broken down into several user stories, as they are usually too big to be worked on directly. Taken from https://admhelp.microfocus.com/octane/en/16.0.100-16.0.400/Online/Content/UserGuide/articles_release_quality.htm?Highlight=feature%20and%20stories#Backlog_Items
If I consider this definition against a Feature being a discrete unit of value then I see several compatible phrases -
- A Service that fulfills a stakeholder's needs - We can equate this service with value
- Underlying benefit - again, we can equate this with value
If we are advocates of the Flow Framework (https://flowframework.org/) then I see a phrase that conflicts with this
- they are usually too big to be worked on directly
If Features are too big to be worked on directly then we can expect them to be a large number of story points. But how much larger? If we want them to flow then they will all need to be of a similar relative size we can't expect a 20 story point Feature to flow in the same way as an 80 story point Feature.
We can overcome this by arbitrarily splitting stories into smaller units, so in the example above we could split our 80 story point Feature into four 20 story point Features. But then would the value only be delivered when all four of these smaller Features has been delivered? In attempting to manage the size of Feature flow items we have created dependencies between them.
So - are Features discrete units of value or is it more important that they are flow items? What do you think?