Welcome to the Jazz Community Forum
Restricting who can define and commit work
I am working on a large project where we do six month releases broken into two week sprints. We use epics to denote release-level work and stories to denote sprint-level work.
We would like to restrict who can create and commit epics and stories. Our first thought was to limit who is able to create epics and sprints by role (e.g. 'project lead', 'component lead'). But this has a drawback: It means that only a small number of people are able to define content and these people could be a bottleneck. Our second thought was to say "anyone can create epics and stories but only certain people can commit epics and stories to actual releases and sprints" but it seems like RTC only allows us to modify "Planned for" for all work items, not just for a certain type. This means that if we lock down "Planned for", normal developers couldn't assign a lowly defect to a sprint (which we want to allow).
We would appreciate any guidance or best practices on how to do this.
We would like to restrict who can create and commit epics and stories. Our first thought was to limit who is able to create epics and sprints by role (e.g. 'project lead', 'component lead'). But this has a drawback: It means that only a small number of people are able to define content and these people could be a bottleneck. Our second thought was to say "anyone can create epics and stories but only certain people can commit epics and stories to actual releases and sprints" but it seems like RTC only allows us to modify "Planned for" for all work items, not just for a certain type. This means that if we lock down "Planned for", normal developers couldn't assign a lowly defect to a sprint (which we want to allow).
We would appreciate any guidance or best practices on how to do this.
3 answers
Hey Bill, you're right, you can't configure "modify 'planned for'" based on role and work item type. In CLM, we've taken the approach of limiting creation of Plan Items and Stories to PMC and Component Leads. We accept Enhancements from the Community, but it takes one of us to promote it to the plan as a Story or Plan Item.
You could imagine writing a pre-condition that implemented the role-based check, but a quick look around didn't find a very good example to work from.
Scott
You could imagine writing a pre-condition that implemented the role-based check, but a quick look around didn't find a very good example to work from.
Scott
In CLM, we've taken the approach of limiting creation of Plan Items and Stories to PMC and Component Leads.
Thanks Scott.
Follow-up: What role do product managers play in terms of creating epics and stories and setting their attributes (e.g. priority)?
Thanks, Bill
Our Product Managers are members of the PMC, so they have that role in RTC. The intention is that they actually do the majority of the creation.
Scott