My background is the book BDD in action.

How one goes from Feature to Stories? More specifically I would like to understand the following:

1- When does one provide the decomposition into stories? Do you do it while spotting the examples that illustrate your feature ?

2 - If so how do you proceed in your development then: Do you first start to on work on the stories while leaving your feature pending ? Do you right the feature scenario first and then, move on the stories that comes out of it, while leaving the feature test pending ?

The key here is the process, if i do a decomposition of a feature into stories, before writing my actual scenario that spot those stories, i might be writing stories that are not relevant to the feature isn't it?

This though make me think that stories must be fleshed out in the same way as unit test/integration test are fleshed out of a user stories?

However if one does that well it is difficult to plan a feature for scrum iteration.

I understand that it is just a planning tool, but it would be interesting to understand how this planning is actually used in the context of dealing with a feature.

I believe one should not do too much upfront planning, not commit to things without being sure, but in the mean time, it seem to me that the decomposition into the different process (stories) involve into the feature process requires some upfront planning.

I would appreciate a clarification on that point.

  • After some digging on the subject, i think my problems came from my comprehension of user story as a planning tool. With my updated understanding, user story are part of a feature in terms of multiple scenarios ? This shall be represented as a tag on the scenario. If this user story is also present in another feature, then the tag will remind that, it is tested already in another feature? Please let me know if i got it right?
    – MaatDeamon
    Jul 21, 2014 at 17:58

1 Answer 1


Ultimately, user stories translate into software requirements, and so do features.

All high-level descriptions of software should ultimately translate into individual software requirements that are Specific, Measurable, Assignable, Realistic, and Timely. If you get this right, then you're doing it "correctly," assuming your requirements gathering process is sufficiently thorough.

A user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. Typically a User Story takes the form:

"As a <role>, I want <goal/desire> so that <benefit>"

For example:

As a Customer Service Representative, I want to search for my customers by their first and last names, so that I can find them in the system if they don't know their account number.

This translates into the requirement:

The Customer Service screen shall provide the capability to look up customers by first and last name.

User Stories don't necessarily have to derive from features. Most customer service representatives already know that they need a tool to look up customers, irrespective of any feature list that may or may not be created yet.

Further Reading
User Stories

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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