It's all about the answers!

Ask a question

Mapping your "projects" into Team Concert


Geoffrey Clemm (30.1k33035) | asked Sep 11 '10, 1:09 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited May 21 '14, 2:24 p.m.
Frequently, I'm asked how "projects" should be mapped into Team Concert.


Accepted answer


permanent link
Geoffrey Clemm (30.1k33035) | answered May 21 '14, 2:12 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The first thing I always say is:
Don't let the term "project area" cause you to map each of your projects into their own project area. In particular, whenever you see "project area", think "process area", i.e. the place where you define a common process for a set of teams. So unless teams need:
- their plans and work items to be readable only by that team, or
- their own set of custom work item types,
put them all in one project area.

So if a project shouldn't be mapped to a project area, what should it be mapped to? The most common answer is "a plan item" (e.g., an epoch or a story work item). The next most common answer is "a team area".

If each of your projects have a distinct set of people, and you want to plan at the project level (e.g. you want to say things like "Tim works 20% on project X and 30% on project Y), then you'll probably want to have a separate team area for each project.

But more commonly, you have a set of people that work on several projects, and you want to orchestrate the work of that set of people as a single plan (so that people don't allocate a particular amount of their time for a given project, but rather float their time between projects as needed to get all their projects done), then I would model that set of people as a "team", and then create a "project" work item type (inheriting from either "epoch" or "story"). Note that an epoch reports on the progress of its child stories, and a story reports on the progress of its child tasks, so you can track the progress of the "project". Also note that in this case, a team outlasts a single project, with team members being added and removed, and is archived only when that team is fully disbanded.

So in general, when your are modeling your work in Team Concert, decide what are your plans and sub-plans, and make those be teams and sub-teams.

WRT categories, their purpose is to automatically direct work to the right team. So you'll need at least one category per team, and starting with just the names of the teams is simplest.If your stakeholders (that submit requests) aren't familiar with your team naming conventions, rename the categories based on concepts that are more familiar to your stakeholders (and you are always free to define multiple categories that map to the same team). In the case
above where you have a given team work on several projects, if your stakeholders are more familiar with projects than teams, then a good approach is to have a category for each project, and then map the each category to the team that is responsible for that project.
Ralph Schoon selected this answer as the correct answer

Comments
Tony DeFarlo commented Sep 12 '10, 7:04 p.m. | edited May 21 '14, 2:13 p.m.

Geoff:

I'm new to RTC, but after experimentation I am in agreement with your points below. However, there is one other aspect to this: timelines. There are reasons why teams may need their own timelines. There seems to be a disadvantage in this though. The plan view will now not showing all the work involved in satisfying an epoch, only a particular teams work. Also, queries don't seem to support displaying the team associated to the epoch.

Any guidance from your experience on when to use team timelines and when to just use the project timeline?


1
Geoffrey Clemm commented Sep 12 '10, 10:20 p.m. | edited May 21 '14, 2:27 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

There was a thread on this topic, titled "How to handle staggered
sprints across teams in same release". An entry from that thread that is
probably most relevant to your particular question is:



The natural way to do this is to create separate timelines for each
schedule. Then each schedule can have its own "current" iteration.

One downside is that currently, a given team area can only be associated
with at most one timeline ... so if a team works on multiple timelines,
you have to duplicate the team area for each timeline that team needs to
work on. Note: work item 99436 requests allowing a team area to be
associated with multiple timelines for planning purposes ... feel free
to add a comment to that work item if you are interested in this
enhancement.

Another downside is that the agile planning views can only be applied to
a single top level iteration. So you can't get an agile planning view
across two iterations if they are in different timelines. Work item
94056 requests that you be able to do so ... as above, feel free to add
a comment to indicate interest/support.

But if in your case, a given team usually just works on a single
schedule, and that you primarily do your planning in the context of a
single timeline, then having a separate timeline for each schedule is
probably the way to go.






Norman Dignard commented Mar 03 '17, 1:11 p.m.

There are other implications to consider -

Does everyone use RTC for source control or some other parties app.  For example system A users RTC, system 2 - git, system 3 -Clearcase - can these be configured/co-exist within the same PA ?

RQM - does each system have their own QM PA?  Configuring QM for  multiple RTC PA's, build results unless v6 fixed this is problematic. 

One other answer



permanent link
Kristie Loupe (6) | answered Mar 03 '17, 12:10 p.m.

Geoffrey, how does my team get access to RQM?

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.