Skip to main content

Features vs User Stories

Last post 01:34 pm June 4, 2019 by Barry Sayers
6 replies
06:52 pm January 22, 2015

I'd like to just understand the difference here, as on the project we're on now, we never refer to 'Features'. We only have User Stories, and Tasks (Incorrectly, I believe).

Am I right in saying that a feature could be a parent of multiple User Stories, and then Tasks are the children of the User Stories? It's just a hierarchy, really?

For example, I want to build a site that sells shoes.

My features might be:

Display informative Home screen
User Registration
User Login
Display Products
Display Shopping Cart
Add products to Shopping Cart

And then, User stories would be developed off those:

Display informative Home screen
- As a User, I want to access the Home scree, so that I can enter the website
- As a user, I want to be able to see specials, so that I can see the current deals

User Registration
- As a user, I need to be able to register as a new user, so that I can have more access to the site
- As a user, I want to be able to register with my Google account

User Login
- As a user, I need to be able to login with my username/password, to gain access to the site
- As a user, I want to be able to login with my Google account, to gain access to the site
Display Products
-

Display Shopping Cart
-
Add products to Shopping Cart
-

etc etc.

As a development team, our biggest issue with the BAs and Testers, is that they can't really test the user stories, because some might be incomplete for this sprint.

I think that we should rather deliver features, which would include all user stories - BUT ... features can span sprints, so this is an issue.

So how do features work in good scrum practise?


10:44 pm January 24, 2015

Hi,
In scrum, I think we usually use "Epic" and "Theme" instead of "Feature". "Theme” is a collection of related user stories.
Whenever a user story which you estimated that cannot completed in single sprint, you should call it as "Epic" instead. That mean you should split is into smaller user stories.
A theme can be done in 2 or more sprints. So you must prioritize and choose user stories for a sprint as long as we have a potentially shippable product increment at the end of sprint :)






10:58 am January 25, 2015

Feature instance refers to the strategy layer while user stories and tasks - to execution. Actually "feature" is not a standard term for the Scrum, hence not mandatory. However, it might be used by PO to handle high level plans along with terms like "Theme", "Initiative", etc.

Regards,
Max


09:30 am January 26, 2015

Craig,
remember that concepts like features, user stories, tasks, epics etc. are not part of the Scrum framework, but "complementary practices". This means you can use them as you see fit. In the end they are all Product Backlog Items, so only the rules from the Scrum framework concerning Product Backlog items apply to them.
This also means they have to provide acceptance criteria in order to decide if they are done or not. The user stories you provide look like it should be possible to test them. Try to find acceptance criteria to support your testers.
It also can help to deliver your whole features within one sprint (Backlog sorting according to business cohesion). The Scrum Master can ask the team why they cannot deliver them within one sprint and make a list of reasons why. Then he can work with the team to remove these reasons.


12:22 am January 27, 2015

The Product Backlog lists all features, functions, requirements, enhancements, and fixes. As Ba Luu and Maxim indicate these can be decomposed into User Stories. So features would be a higher level description of desired product aspects.

The level of decomposition and the name you give it is not that important. Key is that you decompose the Product Backlog items to be small enough to be delivered in 1 increment. In 1 sprint. According to your Definition of Done. And to the acceptance criteria as Ludwig mentioned.

Your DoD probably has non-functional rules like: technology to be used, architecture compliance, performance and privacy requirements, company practices.

I agree with Ludwig: in your examples, your functional acceptance criteria are easy to be defined for the User Stories. It can be as easy as showing the functionality to 'The End User' or to a representative like the Product Owner. And ask him if the implementation covers the envisioned product need.

===

In your question, I get the impression that the testers and the BA’s are not part of the Development team. Is that correct? If so, think about the meaning of cross-functional teams.

And in your question, you don’t mention a Product Owner. A part of the PO role is to prioritize and group the Product Backlog items to business value. So, formally, the Development Team has no saying over build sequence, except maybe for technical dependencies.

However, the Development Team has the final word and responsibility to dedicate what can be done in 1 sprint including testing.


09:08 am March 11, 2019

A story = a feature. The confusion is likely caused by poor agile implementations such as SAFe. They typically will need to use agile terminology (so that it feels agile, but it isn't), and will need to alter the meaning of those concepts such as stories to fit with their flawed model. They thus therefore have to introduce new things such as features.

Agile for instances promotes cross-functional teams where each team has all the skills required to produce an increment (eq story).  SAFe contradicts this basic agile principles and allows organizations to remain as they are; working with component-teams instead (backend-team, frontend-team, UX-team,..) which on their own cannot produce anything meaningful to the customer. So their definition of an “user”-story is very flawed, in fact 'their' user-story don’t mean a damn thing to the end-customer. Their features do.

Scrum is a 'rather' good implementation of agile, where a story is something meaningful to the customer. So agile is very simple, but the implementations and different interpretations make it very hard and confusing.


11:20 am June 4, 2019

Before Agile we had Features, Requirements and Tasks (see proprietary project management tools for details).

Features are still the outcome of work done by teams to create product solutions for a Customer, Business or Market problem. That work is organised into engineering Tasks that are targeted at meeting the criteria defined by the Story wording format, instead of the product requirement format, of the consumer, or consuming system's, scenario as a value goal, that can be inspected and measured as quickly as possible to decide how much it contributes towards a solution for the problem at hand.

Epics are better seen as raw Stories that need to be broken down with more understanding of what is useable and inspectable quickly. Having Epics in development for long periods of time is an excuse for poor planning, so break them down into valuable chunks, leaving no more than a memory.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.