Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Playing with icescrum, I realised that I do not understand the difference between user stories and user features.

Can someone explain the difference?

share|improve this question

migrated from stackoverflow.com Mar 16 '11 at 17:18

This question came from our site for professional and enthusiast programmers.

    
The question is really for area51.stackexchange.com/proposals/16601/… but it isn't even in beta. –  BЈовић Mar 15 '11 at 14:55
    
Clearly subjective, as we have two answers in direct opposition. It may be too late as one of those answers is already accepted, but voting to move to programmers.stackexchange.com –  Don Roby Mar 15 '11 at 22:13
    
@Aaron, @Mike Lewis, Both of you are close: Features == User Stories but Features !== User Stories. –  zzzzBov Mar 16 '11 at 22:02
    
@zzzzBov So, how to differentiate them? –  BЈовић Mar 17 '11 at 6:58
add comment

5 Answers

up vote 6 down vote accepted

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.

share|improve this answer
    
That's my understanding as well. Thanks –  BЈовић Mar 18 '11 at 12:31
4  
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 Koritnik Dec 28 '11 at 11:37
1  
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. –  Lunivore Dec 28 '11 at 13:01
add comment

Features != User Stories.

http://iserialized.com/features-vs-user-stories-in-scrum/

and

http://blog.mattwynne.net/2010/10/22/features-user-stories/

These are one of my favorite reads for this topic.

share|improve this answer
1  
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 McIver Mar 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 McIver Mar 15 '11 at 15:06
add comment

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.

share|improve this answer
    
+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. –  murrekatt Mar 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? –  sleske Jan 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 McIver Jan 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. –  sleske Jan 5 '12 at 8:19
    
BTW, related question & answer: stackoverflow.com/questions/1714557/… –  sleske Jan 5 '12 at 8:32
show 1 more comment

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).
share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.