Multiple Projects Vs Multiple Streams (and multiple teams)..
hi,
I have a scenario, we have one big project and within this project there are multiple sub-systems. like one project is for portal, one is in EGL, one in HATS etc. I would like get feedback from the experts that what approach should be considered
1. Create one project with create multiple teams (like portal team, HATS team, EGL team ) and then create multiple streams. each stream is owned by the relevant team to avoid unauthorized change.
2. the second approach is to create separate project for each sub-system with typically one team.
regards,
Qaiser
I have a scenario, we have one big project and within this project there are multiple sub-systems. like one project is for portal, one is in EGL, one in HATS etc. I would like get feedback from the experts that what approach should be considered
1. Create one project with create multiple teams (like portal team, HATS team, EGL team ) and then create multiple streams. each stream is owned by the relevant team to avoid unauthorized change.
2. the second approach is to create separate project for each sub-system with typically one team.
regards,
Qaiser
Accepted answer
I recommend always creating a new team area within an existing project area whenever possible, unless you have identified a compelling reason for creating a new project area. For example, if you want a completely different set of work item types in the new effort, then you probably need a new project area. But otherwise, a new team area allows you a much closer/simpler collaboration with other efforts in that project area. In particular, it minimizes the amount of information you need to duplicate and maintain, and allows you to do things like create a single query that spans both efforts. If there are multiple project areas you could join, pick the one with which you expect to have the closest collaboration.
One other answer
Either approach is good, it really comes down to how many people are involved and much collaboration there is between the sub-systems. If you end up having common code it's a real pain to migrate to a different project entirely but fairly easy between streams.
We tend to favor your first approach until there is a good organizational or security reason for having a separate project because it's easier to manage. (I just completed a project with that kind of organization and it worked very well.)