It's all about the answers!

Ask a question

Giving PO more control over the backlog plans


Maggie Stearns (1063027) | asked Dec 21 '10, 1:44 p.m.
Hi Forum Friends:

I have summarized our needs below relating to Agile planning in RTC.
Im wondering if you can propose a solution for us. We are using 2.0.0.2iFix4. I also understand that there are some
changes in RTC3.0 that might convince us to upgrade before making any changes to the
current configuration. My next action is to see how this works in 3.0.

Thanks,
-Maggie

We are currently using the standard Scrum project process in RTC. I have a Product Owner (PO)
who would like us to configure RTC to accomplish these items:
1. Enable only PO to modify the Planned For field of a story and epic
2. Enable only PO to modify the Description field of a story and epic
3. Enable only PO to change Priority for stories and epics
4. Enable only PO to change ranking for stories and epics. (We utilize the default setting that ranking is based on Priority)
If a team member were to change the ranking of a bunch of items, nobody would know that this happened, therefore
we consider the need to secure this very important.
5. For a release plan that includes Epics and stories (we realize this
is not typical; usually release backlogs dont contain epics), enable us to view the
ranked stories only (and not display epics).

How can we implement these? Below is a description of what we currently understand about each item above:

1. RTC allows us to define what role(s) can modify the Planned For field. There is however, a side-effect.
Work items include all types of work items not just stories. So if we define that only a PO can modify the
Planned For field, then team members cant set Planned For field for other types of work items such as
their own tasks and defects.
2. Same as for #1.
RTC allows us to define what role(s) can modify the description field. There is however, a side-effect.
Work items include all types of work items not just stories. So if we define that only PO can modify the
Description field, then team members cant set description field for other types of work items such as
their own tasks and defects.
3. Same as for #1.
RTC allows us to define what role(s) can modify the Priority field. There is however, a side-effect.
Work items include all types of work items not just stories. So if we define that only PO can modify the
Priority field, then team members cant modify Priority for other types of work items such as
their own tasks and defects.
4. In a test project, I modified the permissions on Save Plan to remove the Team Members ability to
save a plan, but that does not prevent team members from changing rank via drag and drop. (You get
a banner saying that you dont have permission to save the plan, but the ranking is changed.)
Any other way to prevent team members from changing rank? What about a new field added only
to Stories that only POs can modify. Then can we change rank to be based on this new field instead of Priority?
5. I wish there was a way to exclude epics from the display of a backlog plan.
Possible options?:
1. Move epics out of the release backlog and back into the product backlog
2. Make the priority of epics unassigned so that they appear lower in the list
3. Create a new priority level called Epic and place that a level below Low so that it appears between Low and Unassigned items in the plan.

A question regarding dependencies and ranking:
In our Agile planning meeting on 11/18 the question came up:
Q: If I drag and drop a story someplace else, does it also pull over stories that it depends on?
A: Yes
I do not see this behavior. I just created a story with two child stories and defined that the
parent story depends on both child stories and I made them all low priority. I dragged the
parent story to be above an existing high priority story and it changed the story to have a
high priority, but not the two children.

Be the first one to answer this question!


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.