Pat, 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, Ben
Pat Maddox wrote: > On 10/5/07, Ben Mabey <[EMAIL PROTECTED]> 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 >> [email protected] >> 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 > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
