Yes, something like a subset. This article is a good read:
Features vs Stories

Excerpt:

I realized today that I hadn t made explicit the difference in my mind between features and stories and it s an important difference. Essentially, a feature is a group of stories that are related and deliver a package of functionality that end users would generally expect to get all at once. For instance, inline table resizing is a feature (note: this is the ability to drag to resize tables, rows and columns – try it in Word). In the first pass, you d probably have a single story for inline resizing of tables, but it would be too big to estimate. So you break it down into three stories, resize columns, resize rows and resize the table itself.

According to Kent Beck and Martin Fowler stories and features are synonyms:

A user story is a chunk of functionality (some people use the word feature) that is of value to the customer.

What you call a feature is usually referred to as theme or epic. Themes and epics are used to group user stories to bigger feature sets, that make sense on their own.

From a more semantic point of view: feature is a part of the system you are trying to build, user story is a way to describe that part.

Correction:

As Pascal has pointed out - I maybe missed the real meaning of "feature" in that citation ("feature" obviously refers to functionality) Apart of this, I still think that one can use these words (feature and user story) as synonyms in a lot of contexts ("I m working on this story" vs. "I m working on this feature"), since, as Pascal said, a user story is a way to capture a feature. Which means there is a 1:1 relationship between those two. And, as can be seen from my remark about the semantics, this is how I really understand it.

Not at all..

A user story represents small parts of business value. So it is really difficult to say when an user story is a subset of a feature or a feature is a subset of a user story (also keep in mind that the user stories are usually written by the stakeholders, which tend not to know exactly what they want ... :) )

So, if you follow the recommendation of agile to keep the stories short you would fall on the "best" scenario that is the user story being a subset of the feature.

However if your stakeholder write long stories, each story would have a couple of features ( if there is a good communication between the team and the stakeholders this won t happen since the team will break the stories into small ones)

Features are what a system is doing. User stories are just one way amongst others to capture features.

I just came across this topic when i was searching for different ideas on "using multiple roles for similar requirements".

I think that, a feature as a container for related stories helps in prioritizing the requirements because stakeholders usually tell their needs as dependent stories. In a recent project, the customer told me as follows

A member can send messages to the admin Admin can send messages to all members Members can send messages to each other

When i see these requirements, i know that, we should implement a system to enable people to send a message and we should add checks to allow whom to do what.

And also i know that these requirements may have some other implicit requirements such as reading the messages that came, arranging them , may be setting as spam and etc.

So i try to rephrase these requirements as

As a member or admin, i can send messages to other people. As a member or admin, i can read messages that were sent to me.

And as the acceptance criteria, i state in detail who can send to who.

Then i call all these things as "Private Messaging" feature, so that, at some time later, if the client decides that it is an extra cost, he can say "Just drop the private messaging thing" and i can remove all of them from the backlog.