It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787

question asked: Dec 08 '09, 1:53 p.m.
question was seen: 4,866 times
last updated: Dec 08 '09, 1:53 p.m.

Related questions

FAQ - How this Forum works

What is the best practice for defining projects and teams

0
James Leone (136●1●35●13) | asked Dec 08 '09, 1:53 p.m.
Hello,

I'd like to hear about the best way to define projects and teams. Are there general guidelines or "best practices" regarding these?

For example, in our company each product release varies in terms of feature scope, duration, and people. Throughout the project, we have internal releases of course, but the culmination of the project is one release that gets submitted to the FDA. We consider each product release a "project" with it's own project manager, teams, etc. Often times we have a few people that work on different teams within a project (or across projects/releases). All of these teams are working on the same codebase (just different streams).

My question is, should I have one RTC "project" per "product release" or should there be one master RTC project with defined releases and many teams/sub-teams beneath that?

What are the pro's and con's of each approach?

If we have separate RTC Projects for each "product release" can work items be transferred between RTC projects? There are many times in a project that we have to cut scope, therefore we will need to push some of the backlog work items to the next release. If I setup one RTC Project per product release, we will need to move work items across the projects.

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Dec 09 '09, 12:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
My recommendations:
Create as few project areas as you can get away with.
So try everything in one project area until you encounter a good reason
to create another project area.

Some reasons for creating a new project area:
- A team requires a different process configuration that cannot be
overridden in a team area (e.g a different set of work item types).
- The team wishes their information to be read-protected from access by
members of other teams.

So in your case below, I don't see any reasons to have more than one
project area. In particular, it is very unlikely that you would want to
create a separate project area for each release.

Cheers,
Geoff

jleone wrote:
Hello,

I'd like to hear about the best way to define projects and teams. Are
there general guidelines or "best practices" regarding
these?

For example, in our company each product release varies in terms of
feature scope, duration, and people. Throughout the project, we have
internal releases of course, but the culmination of the project is one
release that gets submitted to the FDA. We consider each product
release a "project" with it's own project manager, teams,
etc. Often times we have a few people that work on different teams
within a project (or across projects/releases). All of these teams
are working on the same codebase (just different streams).

My question is, should I have one RTC "project" per
"product release" or should there be one master RTC project
with defined releases and many teams/sub-teams beneath that?

What are the pro's and con's of each approach?

If we have separate RTC Projects for each "product release"
can work items be transferred between RTC projects? There are many
times in a project that we have to cut scope, therefore we will need
to push some of the backlog work items to the next release. If I
setup one RTC Project per product release, we will need to move work
items across the projects.

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.