CLM Planning
CLM 4.0.4, practicing Agile
Stories work items are linked to Requirement artifacts.
In the initial state, my stories are in the product backlog. During the Release planning meeting, I move Stories from the Product Backlog to the Release Backlog.
Is there a way to move the linked requirements from the Product collection to the Release collection as soon as I move the linked stories?
Thanks,
Liora
Accepted answer
One other answer
Agreed there is no automated approach but we have seen other ways of working with content in RTC and RRC.
One alternative approach to creating a new Requirements Collection, might be to tag those requirements that are in the Product Backlog Collection with a Release tag, indicating which ones are delivered in which release, because it is quite common for a set of requirements to be implemented over a number of Releases and Sprint.
So requirements in the collection with multiple tags, e.g. Release 1.1, Release 1.2, might indicate that that requirement was implement over a number of releases, where the stories in the RTC plan indicate which portion of the high level requirement was implement in which sprint. This would eleviate the need for creating additional collections.
Now another alternative might be to manage Backlog Epic, Stories and Tasks in RTC and use RRC for those requirements and design content that might span multiple releases like non-functional requirements, requirement scenarios, use cases, design, architectural documents, and user interface content so that is not a one to one mapping between content in RTC and RRC.
RRC is also good for glossary terms and reusing content between various content.
One alternative approach to creating a new Requirements Collection, might be to tag those requirements that are in the Product Backlog Collection with a Release tag, indicating which ones are delivered in which release, because it is quite common for a set of requirements to be implemented over a number of Releases and Sprint.
So requirements in the collection with multiple tags, e.g. Release 1.1, Release 1.2, might indicate that that requirement was implement over a number of releases, where the stories in the RTC plan indicate which portion of the high level requirement was implement in which sprint. This would eleviate the need for creating additional collections.
Now another alternative might be to manage Backlog Epic, Stories and Tasks in RTC and use RRC for those requirements and design content that might span multiple releases like non-functional requirements, requirement scenarios, use cases, design, architectural documents, and user interface content so that is not a one to one mapping between content in RTC and RRC.
RRC is also good for glossary terms and reusing content between various content.
Comments
sam detweiler
Jul 20 '14, 12:23 p.m.do you mean 'automatically'? I don't think so.
In my mind the release collection becomes the product backlog in RTC.
all requirements (product collection)
set we agree to deliver at this time (release collection)
equals dev product backlog, which are then distributed across the sprints for this release.
you don't want development just doing anything, you want then focused on what u are committing to NOW.
there should be regular reviews (monthly like sprint standups) to insure that what your company has committed to deliver (externally) remains on track, and the backlog should be adjusted accordingly.
1 vote