It's all about the answers!

Ask a question

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

Olivier Béghain (1082133) | asked Feb 09 '16, 1:11 a.m.

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.


3 answers

permanent link
Ralph Schoon (63.2k33646) | answered Feb 12 '16, 2:06 a.m.
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.

permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 12 '16, 11:54 a.m.
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).

permanent link
Thomas Kirstätter (181619) | answered Feb 13 '16, 6:33 a.m.
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.

Geoffrey Clemm commented Feb 14 '16, 11:28 a.m.

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 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.