The feature is not an integral part of most agile delivery methodologies. Its concept is way older than agile itself: it describes what a system or product does, is, has, can. For instance, let’s say when a system sends an email to a user upon a password change, that is a feature of the system. However, feature in agile software development does not have a universally accepted, single definition.
It is always important to keep in mind that ‘agile’ is rather an approach than a standard methodology, therefore there is room to define feature in different ways. Some people use this term when others would rather use epic, thus, for a collection of stories. Another example is its definition in the Scaled Agile Framework (SAFe):
A Feature is a service that fulfils 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).
(© Scaled Agile, Inc.)
This is a very specific definition, and even though slightly similar to the original meaning, they are not interchangeable.
Is there a difference between a story and a feature?
Definitely yes. The story expresses a business goal, the feature expresses a system or product capability, quality or way of work. A feature might be exactly described by a story (like in the above example), but systems have features which are specified by multiple stories (just like an epic) or not even specified at all (e.g. the visual design of an enterprise workflow system is usually up to the team which implements it).
Whichever definition we find more useful, it is important to share our understanding with our teams and stakeholders. Otherwise, we may face confusion around epics, themes, features, initiatives, programs, releases, etc. These all can be containers/groups of user stories.