Creating Agile Stories....RRC vs RTC
Our adoption to the Jazz platform is a major change for the our team. Initially we were purely waterfall and now doing agile scrum.
Currently we have implemented the RTC and RRC tools. My question is related to the creation of epics and user stories. Our Business Analysts are the ones creating most of the artifacts in RRC. Currently, our process is creating the user story in RRC and then implementing it into the RTC team backlog by linking it with a newly created story work item. So far, it works great for the BAs, but sort of a pain for the team because they have to click into the story and then click the implemented link to go into RRC and read the story/acceptance criteria. This is also true for the initial epics created. The epic would then eventually be broken down into stories, which would then still be linked into RTC from RRC. 1- Does it even matter which way we choose? Is it just preference? 2- Should we be creating stories in RTC and linking them into RRC? What are the advantages/disadvantages? 3- If we continue this path, do you see any problems with agile planning/utilizing the jazz tool in the RTC side? thanks! |
Accepted answer
Ralph Schoon (63.5k●3●36●46)
| answered Mar 21 '14, 3:42 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Jonathan,
as far as I understand what you are doing, this is the way the tools where designed to work. You can user RTC without formal requirements management, in which case you would only use Stories and Epics for the agile requirements management (not sure if it is called that way). If you do more formal requirements management, you do that in RRC. Once the requirements are done, you need to implement them and create work items linked to the requirement. The work items are used to track the work. To look at the requirement you follow the link to the requirement. the tool makes this really easy to do e.g. using hovers. I guess which type of work item you link to depends on how you do the requirement management. If it is very detailed, you might link to a task. Linking to a story or epic makes sense to me, if you use agile approaches. Jonathan Schneider selected this answer as the correct answer
Comments We are literally creating the user story in RRC, then once they BA has all the acceptance criteria, they move it to the RTC backlog with JUST the name of the story (title of work item). So when you hover, it has nothing except the general work item fields, no description or acceptance criteria.
RRC allows to create work items e.g. from a collection of requirements. These work items will have a link back to the requirement. I assume you do something similar. This allows the developer to go back to the requirement for details.
Yeah, it seems that it is mostly preference on what works best. I guess we will just try it out and see if we need to switch.
|
One other answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Mar 21 '14, 2:22 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
This is the way I'd suggest thinking about it:
A requirement is a definition of what the system should do (but not how it should do it). A work item is a definition of a change you want made to the system. Every new requirement or change to an existing requirement requires a change to the system, so a work item will need to be created to track the implementation of that change. So why bother with the requirement if you are going to need to create a work item anyway? The answer depends on whether you are going to maintain a set of requirements that document at a high level everything the system should do. If the answer is yes, then you'll want to use RRC to maintain that set of requirements. If the answer is no, you can skip RRC, and just create your RTC work items. To expand a bit on this, consider the RTC "story" work items. They seem a lot like requirements, but its best not to think of them that way ... instead, think of them as a high level way of defining a change request, i.e. "change the system so that this story is supported". The difference can be understood when you have a new story that effectively changes some aspect of an old story. If you were storing the stories as RRC requirements, you wouldn't create a new story (requirement), but instead, you would just update the old story (requirement), creating a new version of the requirement, and then link the new version of that requirement to a new RTC work item to actually make that change. If you were storing the stories as RTC work items, you wouldn't update the old RTC story (work item) ... you would just create the new story (work item), and start working on it. So the RTC-only approach is simpler... just say what you want changed in a new work item, and implement it. But what you lose is a set of requirements that document at a high level what your system does. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.