How do I set up my project and team areas if every team contributes to every project?
In question https://jazz.net/forum/questions/61929 it is recommended to use a single project area with a team area for each team. I would absolutely agree to that recommendation if I can bring all this in ONE hierachy, meaning I have "n" projects consisting of "m" teams each with "o" team members working for that project.
However we have the problem that there is no such clear assignment of persons to projects. For us it is "n" projects and "m" teams, and each team contributing to almost every project.
So it is unclear for me how I could get this n:m relation into a hierarchy in a single project area.
Karsten
However we have the problem that there is no such clear assignment of persons to projects. For us it is "n" projects and "m" teams, and each team contributing to almost every project.
So it is unclear for me how I could get this n:m relation into a hierarchy in a single project area.
Karsten
Accepted answer
I do not (yet) see any need for two project areas for this ... just create both your Planning Projects and Implementation Projects in a single project area. This maximizes your ability to share information between the planning teams and the implementation teams.
The way I recommend for deciding how to lay out your RTC project area is to answer the question I raised above, namely, "how do you want a team figure out what work it is going to be doing for the next iteration". The layout of your project area will follow from your answer to that question.
For example, one approach for your scenario would be to have each project planning team identify the set of prioritized features they want for its next release (as Story work items, for example). This would be done in the project planning team areas, and the stories would be filed against the appropriate planning project. Then to break those stories down into high level tasks that would need to be performed, set the priority of those tasks to be the priority of the parent story, and file those tasks against the appropriate implementation team area. An implementation team team then has a backlog of tasks. Each implementation team would then size the high priority tasks, and then identify the set of tasks they think they can get done for their next iteration based on their current capacity. At this point, there would probably need to be some negotiation between the various project planning teams once they see which of their desired features would be completed (the result of those negotiations would be modifications to the feature/task priorities, resulting in a rework of the implementation team plans). In addition, there could be negotiations around adjustments to the number of people assigned to each implementation team, which affects how many tasks can be completed by a given implementation team, which in turn affects when a given feature will be available.
Once you have the process defined, you will then be able to identify what kinds of reports, queries, and plans you will use for your planning/development process, which then can be mapped to the planning and implementation team areas.
The way I recommend for deciding how to lay out your RTC project area is to answer the question I raised above, namely, "how do you want a team figure out what work it is going to be doing for the next iteration". The layout of your project area will follow from your answer to that question.
For example, one approach for your scenario would be to have each project planning team identify the set of prioritized features they want for its next release (as Story work items, for example). This would be done in the project planning team areas, and the stories would be filed against the appropriate planning project. Then to break those stories down into high level tasks that would need to be performed, set the priority of those tasks to be the priority of the parent story, and file those tasks against the appropriate implementation team area. An implementation team team then has a backlog of tasks. Each implementation team would then size the high priority tasks, and then identify the set of tasks they think they can get done for their next iteration based on their current capacity. At this point, there would probably need to be some negotiation between the various project planning teams once they see which of their desired features would be completed (the result of those negotiations would be modifications to the feature/task priorities, resulting in a rework of the implementation team plans). In addition, there could be negotiations around adjustments to the number of people assigned to each implementation team, which affects how many tasks can be completed by a given implementation team, which in turn affects when a given feature will be available.
Once you have the process defined, you will then be able to identify what kinds of reports, queries, and plans you will use for your planning/development process, which then can be mapped to the planning and implementation team areas.
Comments
1 vote
showing 5 of 17
show 12 more comments
Comments
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Aug 23 '13, 1:44 a.m.Karsten Angstmann
Aug 23 '13, 10:01 a.m.Karsten Angstmann
Aug 23 '13, 10:13 a.m.