User story decomposition
Hi,
I'm looking for help/confirmation about user story.
i read several books but had some issues to get confirmation and to reach some scrum forums/communities.
let say i have a feature "Create Account" which consists of several user stories:
1. as unknown user i want to create candidate account so that i can store my resume to apply to a job offer
2. as administrator i want to create consultant account so that employee can manage candidates
3. as consultant i want to create candidate account so that i can retype candidate resume into system
4. as administrator i want to create candidate account so that i can retype candidate resume into system
..
this is a short example, but i would like to know if it's correct or not, because user stories 1,3,4 are same or very close.
i would like to know if such decomposition is correct or not.
if not what is the best way to do it (please be concrete) ?
i still have some problem to know when to stop or not with decomposition especially when several roles/actors can perform the same user story.
thank a lot for your help.
A.
Yes, stories 1, 3, and 4 are very close. However, they are also small, independent of each other, and are quite likely to be testable, which are important criteria for well-formed user stories.
So basically they look OK.
My advice though would be to write Acceptance Criteria for each of the stories before you go any further with decomposition. This will make you think about what you have from a new angle, particularly their testability, and how well they are likely to support your Definition of Done.
A,
It's very tough to communicate about User Stories over the internet because there is so much context that can be missed. It's also tough to say whether your splitting is "correct" or incorrect. I think it's also important to point out that User Stories are not a part of Scrum. User Stories are but one technique to represent Product Backlog Items in Scrum, and while it is the most popular method used, it is not the only method. In short, the User Story practice is completely independent of Scrum.
The first thing I would say about your descriptions above is that the sentences you listed are not really user stories. They are "user story descriptions." which means they are 1/3 of a user story. For more on what I mean there, see this article: http://www.scrumcrazy.com/User+Story+Basics (also see the good user story links at the bottom of the article)
Second, I would ask this question. If you have 3 stories that are essentially the same, is there a material benefit in making them 3 different stories? If so, what is it? (It's hard to tell that without knowing your particular context)
For instance, you could describe your user story as:
Card-Description: "Create Account"
Conversations: <Then have some conversations with the team to help create test confirmations like the below. Hopefully you can have a Scrum team and some users participate in these conversations>
Confirmations:
1. Test that an unknown user, a consultant user, and an administrator user can create an account.
2. Test that the user must enter first name, last name, and a email address(with valid email format) in order to create an account.
3. Test that a user is unable to create an account if they don't enter the required information from #2 above.
4. Test that a confirmation email message is sent to the user.
5. Test that the user's new account is not accessible until the user confirms their account by clicking on the link sent in the confirmation message.
> i still have some problem to know when to stop or not with decomposition
This is something that varies with every team, and with how large the stories are in terms of effort. Many teams just starting off with user stories will want to make sure that their stories are no bigger than about 1/2 a sprint. Teams trying to get good at User Stories will often shoot for stories that are a few days of effort, or as few as 2-3 days of effort each.
Teams trying to get good at User Stories will often shoot for stories that are a few days of effort, or as few as 2-3 days of effort each.
I should then add... It's important to split and groom stories as a team, because the amount of "estimated effort" in a user story is a discussion best had with the development team who has the last say on estimates.
For more information on backlog grooming, see:
http://www.scrumcrazy.com/What+does+Product+Backlog+Grooming+Look+Like%…
Hi Mr. Bradley,
Posted By Charles Bradley - Scrum Coach and Trainer on 09 Dec 2012 08:02 PM
Confirmations:
1. Test that an unknown user, a consultant user, and an administrator user can create an account.
2. Test that the user must enter first name, last name, and a email address(with valid email format) in order to create an account.
3. Test that a user is unable to create an account if they don't enter the required information from #2 above.
4. Test that a confirmation email message is sent to the user.
5. Test that the user's new account is not accessible until the user confirms their account by clicking on the link sent in the confirmation message.
Although your example seems to be simple, I would like to ask you what was your approach when creating the above test cases. I'm interested on learning how to properly create Acceptance Criteria/Confirmations for user stories.
Piovezen,
These kind of acceptance criteria are typically created as part of backlog grooming. You are right that these are simple examples, but real life acceptance criteria can get more complicated for sure.
So, for more info on backlog grooming, see:
http://www.scrumcrazy.com/What+does+Product+Backlog+Grooming+Look+Like%…
For more info on other ways of expressing confirmations/AC, see:
http://www.scrumcrazy.com/Presentation+-+Story+Testing+Patterns