[rspec-users] Stories VS Scenarios

Ben Mabey ben at benmabey.com
Fri Oct 5 15:10:11 EDT 2007

Thanks for the reply.  This helps a lot.  It really is just one 
iteration and so I will be placing this all in the same story. I guess I 
was just over thinking it because I am used to breaking my specs up 
often via different contexts. Thanks again,

Pat Maddox wrote:
> 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.
> Pat
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list