[rspec-users] Stories VS Scenarios

Pat Maddox pergesu at gmail.com
Fri Oct 5 15:02:19 EDT 2007

On 10/5/07, Ben Mabey <ben at benmabey.com> wrote:
> Hi all,
> I have read Dan North's post 'Whats in a Story?'
> (http://dannorth.net/whats-in-a-story) but I am still having a hard time
> knowing when I should break requirements up into separate stories or
> keep them as scenarios.  I am currently trying to write a story
> (stories) for the registration process of a site.  The registration
> process is a multistep process that changes based on the type/role of
> user that is signing up.  So depending on the user's role (given by the
> user on the first step) I will be asking different questions.   Should I
> write stories for each of these roles or should these just be scenarios
> of the following story:
> Story "Signin process", %{
>   As a person
>   I want to sign up for an account
>   So that I can view and contribute content
> }, :type => RailsStory do
> Scenario "An individual looking for support" do....
> Or should I break them up into individual stories for each role?
> Story "Signin process for an individual", %{
> ....
> In all cases the underlying WHY is always the same.  So for that reason
> I think they should be in the same story.  However, these paths may be
> more complicated with there own sub-scenarios (paths) so I am wondering
> if they each merit their own story.  Any suggestions on how to approach
> this?  One story or many?
> Thanks,
> Ben
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

The way I look at it is that a story represents a single chunk of
business value.  I realize that can be pretty nebulous :)

One way to approach it is to imagine you're working on this project
with a customer.  You guys have a few discussions and decide that you
want people to be able to login to your site.  In this case you find
that you want two types of users, perhaps a basic user and an admin.
In talking with your customer, you'll determine whether that
functionality goes together or not.  By that I mean, can you
separately prioritize them, and perhaps move one of them to a later
iteration if you had to?  If so, then they're separate stories - they
represent two distinct units of business value to the customer.  If
the customer has to have both basic users and admin in the same
iteration, then they're the same story.

Generally, I would define logging in as different scenarios of the
same story.  However I can see that perhaps they could be separate.
Though I think that would be a unique situation for a customer, and is
unlikely to make sense if you are your own customer in this case.


More information about the rspec-users mailing list