It's all about the answers!

Ask a question

CLM Planning

Liora Milbaum (513284117) | asked Jul 20 '14, 12:01 p.m.
 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?


sam detweiler commented 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.

Accepted answer

permanent link
N Z (3622127) | answered Jul 20 '14, 6:09 p.m.
 While integration within products and to a lesser extent across products is one of the strengths of the Rational toolset, the reality is the integration across products while useful, is fairly weak. Don't expect too much!
Liora Milbaum selected this answer as the correct answer

One other answer

permanent link
Robin Bater (3.4k47) | answered Jul 21 '14, 3:16 p.m.
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.

Liora Milbaum commented Jul 22 '14, 12:33 a.m.

Thanks Robin, interesting approach. I would give it a deep thought.


Your answer

Register or to post 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.