What is the best practice for defining projects and teams
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.
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
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:
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.