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
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
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 <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 >