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.
3 answers
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).
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.
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.
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.