Creating Agile Stories....RRC vs RTC
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
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.
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.
The only benefit I see is being able to hover, like you mentioned, if we create it FIRST in RTC then link it back to RRC.
All in all, I also think our method is sort of waterfallish because of gathering all this upfront requirements and not letting the team do the work.
Thoughts?
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.
I won't comment on 'waterfallish'. My view on requirements is that they typically define what needs to be implemented and not how. If you need more details or want to use features like screen flows, you need to use RRC and then you need to use an implemented by link to a task or other work item in RTC.
I guess there is no one size fits all approach.
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.
We still do very formal requirements. Until that changes, I can see the method we are doing the correct way until more of an informal user story driven environment happens.
Thanks!
One other answer
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.