Project Areas are the same than applications?
How should I determine what is the best number of project areas for the following example?
In a organization there are WIs type Task, Change Request, New Development, Support, Business need, Risk, Bug. The final user must access to the system in order to be able to open Change Requests and New Developments.
In this organization they manage about 50 differents applications and the software life cycle is the same for all.
Should we have every WIs in a unique project area?
Should be better to split WIs about manage (Bussines Need, Change Request, ...) from develop area (Task, Bug)?
Is there any performance negative impact having a lot of WIs in a project area instead of two or more.
Accepted answer
My general rule is "use a single project area until you identify a significant reason to require a second one".
There is no significant performance benefit that I am aware of that results from separating your work item types into different project areas. So if the only benefit you will get from having two project areas is that the "select work item type" list for the "create work item" operation will be shorter for developers, then I definitely recommend sticking with a single project area.
There is no significant performance benefit that I am aware of that results from separating your work item types into different project areas. So if the only benefit you will get from having two project areas is that the "select work item type" list for the "create work item" operation will be shorter for developers, then I definitely recommend sticking with a single project area.