Features vs User Stories

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 :)

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

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.

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.

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.

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.

It depends on how need to level their requirements. I like to think of User Stories as in the voice of a user and features are in the voice or language of classical requirements (MoSCoW.)

     User Stories: As a ____, I want ___, so I can ____, describe the business value.

     Features:  The system shall ...  (see MoSCoW)

I don't like how some tools try to make them hierarchal. Their true relationship cardinality can be anything; 1 to 1, 1 to many, or many to many.

In some environments, there are legal requirements to keep and manage classical requirements.