Help with planned for, timeline, and iteration planning
Wow, there is a lot going on with this area of RTC! I've read many different project planning articles and questions related to iteration planning and I think I'm getting there but still have some questions. I think these are more of the "why did they do it that way" variety, but it's also likely my understanding is still not there.
1. If I associate a timeline with a work category, what is the expected result in a work item? I was thinking that selecting this work item category on the WI would then result in a filtered list of available iterations but I'm not seeing that, I see all iterations.
2. Is it my imagination or is the association of a "release" very loose? When I first started playing with iterations, timelines, plans, and releases, I thought they would tie together more closely with a release. From what I can tell, the only thing a release gives you is something that you can associate a WI with via "Found in". I.e., is the association between a timeline and a release purely semantic (i.e., naming a timeline "release 1" and creating a new release called "release 1")?
3. I get iteration planning and I get the association in "planned for" with the iteration being planned. But why aren't the plans shown in the "planned for" list in a WI rather than the iterations? Even selecting the help link on the field brings you to a specific plan. As above, I get how this is working (I think) but think I'd understand it better to know why it's like that.
4. Why don't iterations (or even plans) "complete"? Is the proper way to complete them to send them to archive?
5. I've noticed that it's very easy to change an iteration plan which is a good for our team since we change plans twice daily (lol). But seems like that could be problematic in some situations. Is there a way to give a plan a final blessing at which time its planned items list is frozen?
Thanks for your help!
- Andy
Accepted answer
Hi Andy.
Let me try to answer your questions one by one:
1. There is no direct association between time line and Category. Both are related through the Team Area. The important artifacts in planning are Team Area and Iteration. Categories are just a way to say what all features a team would work on. So associating the filed against will not filter out the list of Iteration listed in planned for.
2. Again Release is not related to Time Line artifact at all. Release in our Project area is used to associate a build with. For example when we have say 4.0.4 release we associate the approved GA build for 4.0.4 with 4.0.4 release. From Planning perspective it does not have any significance, its just a defect attribute.
3. Plan artifact in RTC is sort of equivalent to a Work item query view. The parameters for this work item query are team area and iteration. So it will pick all the relevant work items which are planned for a specific Iteration and is worked on be a specific team. This plan artifact also holds the configuration on how it should display the work items. So a work item cannot have a attribute like Found In which point to a release. The values of Planned for and Filed against attributes of a work item decided which plan the work item will be visible in.
4. Plan Artifact as I explained in question 3 is just a Work Item query configuration with some more intelligence. You can delete the plans for the past release, but that will not affect any of the work items.
5. You can take a Snapshot of the plan at any time you want. It will capture the state of the work items at that moment. This snapshot can be used in the future for comparison purpose. This can be done from the snapshot tab in the plan. This is available in Plan Web client only.
I hope I have answered your questions.
Comments
One addition to point 2.:
A release can be very useful when you are using RTC not only for work item management but also for Build and source control management. When you run a build from RTC Build engine you will get a build result and within that build result you will find a "Create Release of this build". If you do that, it will create a Release in the project area and will connect it to the build result. After that this release will be available for selection of the list "Found in" in the work items. If you choose such a release link when editing a work item or for example submitting a bug it will be link directly to the corresponding build. That is valuable for the developers, as they now have direct access to the source code that was used in the built.
1 vote
I tried to describe some of the basics how things relate in https://jazz.net/library/article/589 it is more aimed at planning however.
Thanks, Aradhya, that clarifies it for me. I had noticed how similarly these interact to queries so your explanation makes a lot of sense.
Henning, excellent point about build results. It certainly sounds like something we could use in our process, thank you!
Ralph, I just read the article - it's an excellent synopsis I'm going to pass on to our team (who are not familiar with RTC, yet). I love the brevity, it's a very high "word to helpful info" ratio, thanks!