Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Best practice(s) related to management of plans in RTC (6.0.2)

 Hello,

I was wondering if RTC afiliados could share their experiences related to the management of plans in RTC.

Especially, what of the following approach is the most effective and are there known constraints/limitations?

  • Approach #1: For every iteration (sprint), create a separate plan asset.
  • Approach #2: Reuse the same plan asset (e.g.. iteration backlog) iteration over iteration simply by modifying the settings (change of iteration) of the plan when an iteration ends.

I'm actually tending for option #2 (I just have two plans for the "lowest" level of my timeline: "Current Iteration" and "Next Iteration"). In the past, every iteration had its plan (but I don't really see the need to keep the plans for the former closed iterations).

Any feedback is welcome; pointers to best practices are welcome too.

Regards,
Olivier.

0 votes



3 answers

Permanent link
Since plans are cheap objects, I typically create a new plan for each iteration. This also allows to go ahead some iterations or back. If you are using plan snapshots, you want to keep the plans as long as you might have a need to check it.

3 votes


Permanent link
Another advantage of creating a new plan for each iteration is that it is often useful to add custom pages to a plan, to record information about that iteration, and you would want to keep access to those custom pages of the previous iterations (and not overwrite them with content from a later iteration).

1 vote


Permanent link
Hi,
for me that depends very much on your iteration structure I would say.
If you have a lot of rather short and flat iterations (e.g. 2 weeks) like I currently have it for managing work, I use as well a plan that is just "current iteration" and is reassiged with every new sprint.
The need for actively viewing past iterations in my setup is very small, and we as well do not have a long planning ahead (that is managed in the backlog with tags.) I think it is important to say that we rather manage activities and not traditional work packages for development in our team.
In such a setup I have as well already used in addition an release backlog that is grouped by iteration to have an overview over the past and future iterations at a glance.
The limits: no easy access to content of past iterations. I would like to know if this can have negative effects on performance over time for what reason ever.

In a setup with longer iterations or if you reflect product releases in your iteration structure explicitely, having explicit dedicated plans at least for each release would definitely be the better solution.

As well, if I want to get a "different view" on things I always create dedicated Plans to experiment instead of just playing around with new views in an existing plan.

1 vote

Comments

To my knowledge, there is no significant overhead in have a large number of plans (if someone has information to the contrary, please post here).   But if you do not store any custom pages with a plan, and you browse the old plans very infrequently, then I agree that it is fine to just have an appropriate set of "current" plans, and then just configure some personal plan as needed to view the non-current plans.  
 

Your answer

Register or log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 1,221

Question asked: Feb 09 '16, 1:11 a.m.

Question was seen: 3,679 times

Last updated: Feb 14 '16, 11:28 a.m.

Confirmation Cancel Confirm