Playing with icescrum, I realised that I do not understand the difference between user stories and user features.
Can someone explain the difference?
0
Add a comment
|
4 Answers
A feature is a distinct element of functionality which can provide capabilities to the business.
A story is a small aspect of a feature which you can use to get feedback from your stakeholders and find out if you're doing anything wrong.
For instance, a feature might be "allow users to comment on articles". The stories associated with that feature might then be:
- save comments
- filter comments for rude words
- limit comments to 400 characters and feed back to users
- add captchas to stop bots spamming the site
- allow users to log in via Google id
etc.
At each stage we can then get feedback as to whether the direction we're taking is useful.
Some teams don't bother splitting features into stories. That's OK.
-
13Aren'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... Commented Dec 28, 2011 at 11:37
-
4I 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.– LunivoreCommented Dec 28, 2011 at 13:01
Features == User Stories.
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. Commented Mar 15, 2011 at 16:11
-
2I don't think you can say they are the same, even if they are related terms. What about features that span several user stories?– sleskeCommented Jan 3, 2012 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. Commented Jan 4, 2012 at 13:56
-
1@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.– sleskeCommented Jan 5, 2012 at 8:19
-
BTW, related question & answer: stackoverflow.com/questions/1714557/…– sleskeCommented Jan 5, 2012 at 8:32
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.
The two terms are closely related, but there are some differences.
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).
