Aren't those associated stories actually user story tasks? I would say they are. A user story would be: As a user I would like to comment on articles so that we as users can improve article content or express concerns. This user story would be broken down to tasks that you described...
–
Robert KoritnikDec 28 '11 at 11:37

3

I consider a task to be something that needs to be done in order to get feedback, but on which you can't get feedback alone - for instance, creating a database table. Any of these stories, except for the first, could potentially be removed while still leaving value in shipping. Tasks are usually horizontally sliced in my world. But, if you have different definitions, that's OK. Granularity isn't a completely discrete thing, every goal is a subgoal of another, and I think you should do whatever is pragmatic for you. I find this breakdown useful, as have many of my teams.
–
LunivoreDec 28 '11 at 13:01

The verbiage is dictated by the given Agile methodology being employed.

The different methodologies use
different terminology to refer to
features. It is up to the team to
decide which methodology or
terminology to use. Extreme
Programming (XP) uses the terms User
Stories or Stories to represent
features; Scrum uses Product Backlog
to describe a feature list;
Feature-Driven Development uses
Feature; and DSDM uses Requirement.
Similarly, there are various
lightweight versions of the Unified
Process, or Agile UP, that use
Requirement and/or Use Case to define
incrementally deliverable
functionality. Ultimately, the goal is
the same - to deliver business value
regularly in small increments, and
sooner rather than later.

+1, this explains it well. I would not necessarily say feature == user story, except when you talk about business value or client value. In other cases, respective term might not have a meaning.
–
murrekattMar 15 '11 at 16:11

1

I don't think you can say they are the same, even if they are related terms. What about features that span several user stories?
–
sleskeJan 3 '12 at 13:38

@sleske A user story in a pure Scrum approach should be value add to the user and thus a feature. If we are going to catalog features as overarching Epics that is fine but the end result is user stories which deliver value.
–
Aaron McIverJan 4 '12 at 13:56

@AaronMcIver: Yes, that is true. However, sometimes the miminum amount of functionality that is truly useful to the user (=feature) is too much for a user story (or even for an iteration). In that case you must break down the feature into several stories.
–
sleskeJan 5 '12 at 8:19

I like this from the 1st link : "Features can be tested by the end-users, user stories is not necessarily fully testable for the end-user."
–
BЈовићMar 15 '11 at 15:06

1

@Mike Lewis Fair disagreement; however if you are breaking out user stories so you can mark items as done as one of the articles indicated; you might as well wrap your user stories into an epic, which can then span multiple sprints...which again seemed to be the complaint in the user story != feature approach. The bottom line is that you can call it a feature; you can call it a user story; you can call it a widget...the work needs to be done and however you want to store this data in a categorical manner is up to you.
–
Aaron McIverMar 15 '11 at 15:06

2

@VJo If a user story is not testable by the user...then it is not in the form of a user story...it is in the form of a developers story.
–
Aaron McIverMar 15 '11 at 15:06

A User Story is an informal statement in the language of the customer which captures the intent of something that the customer wishes to achieve. You can think of a User Story as an Informal Requirement Statement.

A Software Feature is a distinct characteristic of the software that contributes to the overall design and functionality of the software.

A couple of key considerations:

A Story may describe a Feature, but a feature never describes a Story.

A Story might not directly describe a Feature.

A Story may imply the inclusion of a number of Features.

A Feature - either singly or as a member of a collection of Features - may capture the intent of a Story.

With all of this in mind, I tend to think of Stories as descriptions. Basically informal requirements which tell me what the customer wants. Features on the other hand I tend to think of more as a specification which tells me how a system should work in order to meet the customers requirements.

First, they come from different domains. The term "feature" is a fairly general term for some part of the functionality of a software, whereas "user story" was invented for and is really only used in the context of agile software development.

In practice, they very often coincide, in that one user story consists of implementing a certain feature.

However, in some situations they can be different:

Often, a feature is too much work for a single user story. User stories should not be too big (generally not more than a few days, max 1-2 weeks of work). Obviously many features are much larger. In that case a feature will be implemented across many user stories. Some people use "epics" to group user stories together, in that case you could say that the feature is an epic.

Non-functional requirements (performance, security, compatibility etc.) can also be handled as user-stories (though this is not universally accepted). In that case the result of the user story would not normally be called a feature (unless you call "our application rarely crashes" a feature).

I have worked in an organization where the term user story referred to the format in which you describe the features (software functionality) and stories (detailed features that are small enough for a sprint backlog). This definition does conform the rule: feature == user story and user story != feature.

This doesn't add anything new over the existing answers, and is mostly an anecdote, and no explanation is given for the 'rule'. Please don't add 'me too' answers if they don't add anything of value to answer the question asked.
–
Martijn PietersJan 5 at 10:27