2

I am working on a product and I am using Pivotal Tracker to write user stories, but I am quite new to BDD and XP, and newer to Cucumber. So I am getting confused by the terminology a little bit. What is the difference between a story and a cucumber feature? Both are simple descriptions consisting of three parts--actor, action and business value. Right? So if I already have a story written in Pivotal Tracker, should I just copy that directly into the Cucumber feature? Can one story have multiple features?

What do you think?

picardo
  • 24,530
  • 33
  • 104
  • 151

3 Answers3

6

A feature is a fully-fledged piece of functionality, ready to go live. For instance, a feature might be a user profile, complete with registration page, validation, pictures, etc.

In BDD-terminology, a story is a small slice through the feature which is functional, and on which we can get feedback. For instance, we might produce the registration without a profile page, and without validation. Validation might be another story. Pictures can be another.

It can take weeks to produce some of the more complex features, taking into account architecture, new technologies, domain learning, etc. - so a story lets us get feedback more quickly than this.

You might be interested in learning about Feature Injection - BDD in the analysis space. We use the template quite a lot for both stories and features:

In order to <achieve a goal>
As <the stakeholder who wants the goal>
I want <something>

I tend not to worry too much about whether what I'm doing is a feature or a story, as long as I'm getting feedback as quickly as possible.

Lunivore
  • 17,277
  • 4
  • 47
  • 92
2

"Story" is a series of development tasks which together accomplish a goal. It is a device used by developers.

"Feature" is, well, a feature that the business stake holders want to see in their application. To implement a feature you might need one story, or many, since typically if a story is "too big" it is broken down into more manageable smaller stories.

BDD is a variant on TDD (Test Driven Development). As I understand it, the semantics of BDD are less implementation oriented than the semantics of TDD, in that you use phrases such as 'the system should load the user' instead of "the user instance should not be null after being loaded by the DAO" -- they describe system behavior (feature set) as opposed to specific details of the actual implementation. In the end though, they all test the same thing if done correctly.

And, on topic, the concept of story is really orthogonal to BDD; there are development practices that have Stories and do not have BDD.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
0

Unfortunately feature is a heavily overloaded word in this space and a Cucumber feature is a very different thing to a fully fledged piece of functionality.

The most interesting difference between a 'Cucumber Feature' and a User Story is that a User Story is a historical document, whilst a Feature describes the current state of the application (assuming the feature has been implemented).

This difference is (IMO) much more important than differences in granularity or size. You can have a Cucumber feature that was driven/inspired by many user stories, and you can have a single user story that has many Cucumber features.

Once a Cucumber feature can be run it is code. This means it is much more prone to being refactored and changed. Each time you run it, it gives you information about the current state of your application. A user story tells you about what your application should do. Or perhaps more accurately, what the authors of the story thought you application should do at the time the story was written.

diabolist
  • 3,990
  • 1
  • 11
  • 15