What is the different between RRC and RTC user story?
Accepted answer
One pattern for this is to think of an RTC "story" work item as what you might commonly put on an index card or post it note for agile teams. This is an easy translation of how work is a scrum team might work today without a work item management tool.
Once you have that in place, leveraging other RRC visual requirement types (Wireframes, BPM, Use cases...) can greatly help explain what this text based story (in RTC) really means. Leveraging the OSLC relationship types to between RTC stories and RRC requirements then becomes VERY powerful. (as Story cards only contain text).
One you have this relationship established ...take a look at aligning RRC collections with RTC plans. This is EXTREMELY powerful to help identify traceability gaps between requirements and implementation storys.
Please note: There is not one answer here. It really depends on how the team wants to use stories/ epics. Another critical factor her is how the team uses visual requirements to help complement the use of stories.
Once you have that in place, leveraging other RRC visual requirement types (Wireframes, BPM, Use cases...) can greatly help explain what this text based story (in RTC) really means. Leveraging the OSLC relationship types to between RTC stories and RRC requirements then becomes VERY powerful. (as Story cards only contain text).
One you have this relationship established ...take a look at aligning RRC collections with RTC plans. This is EXTREMELY powerful to help identify traceability gaps between requirements and implementation storys.
Please note: There is not one answer here. It really depends on how the team wants to use stories/ epics. Another critical factor her is how the team uses visual requirements to help complement the use of stories.
2 other answers
Here is a quick summary of how the RRC product team uses artifacts in RRC and work items in RTC together to do user story-driven development:
The user stories in work items are used for planning, estimating, prioritizing and tracking the work of the development team. But they are not sufficient for everything:
- We need to think through and discuss the user needs / requirements behind the user stories.
- We need to express scenarios; individual user stories are often part of a larger scenario/epic.
- A simple hierarchical view in RTC does not always offer the best representation for understanding, annotating and grouping, especially for the period of time before organizing them in the product or release backlog. We may leave some scenarios or aspects of scenarios only partially defined for now; we haven't decided how to group/divide them into user stories.
- User stories in work items often are "closed and forgotten". When we are working on a multi-release scenario, we find it is helpful for product managers, UX and developers to "think in a document" that lasts beyond a release (or even a sprint).
- Sometimes a user story a feature team is working on (one expressed in a work item) will prompt creation of artifacts in RRC for exploring technical options, documenting APIs, etc.
At Rational we have three flavors of Agile: Core Agile, Disciplined Agile Delivery (DAD) and Agility@Scale (A@S).
In Core Agile (which is almost identical to Scrum), you are supposed to be a small team, face to face, with continuous access to your product owner. In such a scenario, you don't need to document requirements other than User Stories and their Acceptance Criteria. In this scenario, RTC alone is good enough.
Within A@S there are eight complexity factors. If a team is facing one or more of these complexity factors, Rational provides practices and tools to manage those. RRC directly helps seven of the eight complexity factors (some could argue all eight): Domain Complexity, Geographical Distribution, Team Size, Organizational Complexity, Compliance Requirement, Enterprise Discipline and Organizational Distribution. (the eight is Technical Complexity, which usually maps to RSA for tool support)
So basically, when you have more complexity, having a richer set of requirements than a User Story provides becomes very helpful. RTC is not good at this type of information, while RRC has amazing traceability, rich text, process diagrams, UI Diagrams, etc to help explain that richer set of requirements to combat the above seven complexity factors.
In the A@S scenario, here is how I explain it:
1. Stories in RTC are Plan Items. We use them to ensure our team is well managed and making great progress.
2. Stories in RRC are the rich details, useful when facing seven of the eight complexity factors in A@S.
3. If your team needs Core Agile, then you can probably have higher productivity and great quality with just RTC.
4. If your team needs DAD or A@S, using RRC will likely improve both productivity and quality.
Now, this leads me to a question for the RTC/RRC gurus out there:
Is there an easy way to do this scenario?
1. I create an iteration (sprint) plan in RTC. I assign Stories from my (release or product) backlog to that plan.
2. I auto generate the exact same stories into RRC so my requirement specialists can add acceptance criteria, rules, terms, flows, etc to clarify any that need it.
I believe I can auto generate Stories from RRC to RTC, but logically I need to reverse this...
In Core Agile (which is almost identical to Scrum), you are supposed to be a small team, face to face, with continuous access to your product owner. In such a scenario, you don't need to document requirements other than User Stories and their Acceptance Criteria. In this scenario, RTC alone is good enough.
Within A@S there are eight complexity factors. If a team is facing one or more of these complexity factors, Rational provides practices and tools to manage those. RRC directly helps seven of the eight complexity factors (some could argue all eight): Domain Complexity, Geographical Distribution, Team Size, Organizational Complexity, Compliance Requirement, Enterprise Discipline and Organizational Distribution. (the eight is Technical Complexity, which usually maps to RSA for tool support)
So basically, when you have more complexity, having a richer set of requirements than a User Story provides becomes very helpful. RTC is not good at this type of information, while RRC has amazing traceability, rich text, process diagrams, UI Diagrams, etc to help explain that richer set of requirements to combat the above seven complexity factors.
In the A@S scenario, here is how I explain it:
1. Stories in RTC are Plan Items. We use them to ensure our team is well managed and making great progress.
2. Stories in RRC are the rich details, useful when facing seven of the eight complexity factors in A@S.
3. If your team needs Core Agile, then you can probably have higher productivity and great quality with just RTC.
4. If your team needs DAD or A@S, using RRC will likely improve both productivity and quality.
Now, this leads me to a question for the RTC/RRC gurus out there:
Is there an easy way to do this scenario?
1. I create an iteration (sprint) plan in RTC. I assign Stories from my (release or product) backlog to that plan.
2. I auto generate the exact same stories into RRC so my requirement specialists can add acceptance criteria, rules, terms, flows, etc to clarify any that need it.
I believe I can auto generate Stories from RRC to RTC, but logically I need to reverse this...
