@sorokinmike Sorry not to answer....your comment got lost. Yikes! Rally doesn't provide a separate field for acceptance criteria; we consider it part of the description of the story. The way we use it here (and the way I did it when I was a customer) is to simply make a bulleted list of AC inside the description field.
1. Since user stories are typically short and concise, how are they structured from a documentation stand point? Do we create one document per module having all possible user stories for that module or is each user story a seperate document?
1. How you handle doco depend on the needs of the team and stakeholders. The imp. thing is to associate together the story itself, the acceptance criteria, sizing, scheduling, & tasks. I personally tend not to be a fan of documents as the best place for all that. Yet some companies do require documents. Because we want it to be easy to re-prioritize and schedule stories in a backlog, it can help to use a tool that enables that, like Rally ALM. Yet, no 1 right way: Ask the team.
2. Identify the story in a way that helps you track it and report on it as you need to. Will depend on your team to some extent. I like to use a natural-language Name that helps everyone talk about the story meaningfully. Use whatever scheme makes sense to create unique IDs. The Rally ALM tool automatically assigns unique IDs to stories, and also helps you manage the stories in terms of priorities, acceptance criteria, tasks, and test cases.
Great video! I especially liked the focus on the what vs. how. Thanks for taking the time to post it :-)
smamol 9 months ago
Where do I put the acceptance criteria in Rally? I see no specific input field for that.
sorokinmike 1 year ago
@sorokinmike Sorry not to answer....your comment got lost. Yikes! Rally doesn't provide a separate field for acceptance criteria; we consider it part of the description of the story. The way we use it here (and the way I did it when I was a customer) is to simply make a bulleted list of AC inside the description field.
RallySoftware 3 months ago
Ronica, thank you very much for the video, I'm using it in me software engineering classes here in Brazil and I wrote portuguese subtitles for it.
So, if you are interested in uploading the subtitles, please let me know so I can send you the file.
mauricioseiji 1 year ago
nice girl,warm
martpast1 1 year ago
I have 2 questions regarding user stories.
1. Since user stories are typically short and concise, how are they structured from a documentation stand point? Do we create one document per module having all possible user stories for that module or is each user story a seperate document?
2. How is each user story uniquely identified?
nirmaljeetm 2 years ago
@nirmaljeetm
1. How you handle doco depend on the needs of the team and stakeholders. The imp. thing is to associate together the story itself, the acceptance criteria, sizing, scheduling, & tasks. I personally tend not to be a fan of documents as the best place for all that. Yet some companies do require documents. Because we want it to be easy to re-prioritize and schedule stories in a backlog, it can help to use a tool that enables that, like Rally ALM. Yet, no 1 right way: Ask the team.
ironica99 2 years ago
@nirmaljeetm To answer your second question:
2. Identify the story in a way that helps you track it and report on it as you need to. Will depend on your team to some extent. I like to use a natural-language Name that helps everyone talk about the story meaningfully. Use whatever scheme makes sense to create unique IDs. The Rally ALM tool automatically assigns unique IDs to stories, and also helps you manage the stories in terms of priorities, acceptance criteria, tasks, and test cases.
ironica99 2 years ago