Projects and teams in Azure DevOps
Configure projects and teams in Azure DevOps
One project or many?
The default advice is fewer projects. A single project with multiple teams keeps work items, repositories, pipelines and artifacts in one place where they can reference each other; multiple projects create boundaries that must then be crossed deliberately.
| Choose many projects when | Because |
|---|---|
| Hard security isolation is required | Project is a real permission boundary |
| Separate process templates are needed | Process is set per project |
| Work genuinely never crosses | No linking cost to pay |
Otherwise prefer one project and multiple teams, since a team is a lightweight slice — its own backlog, iterations, dashboards and area paths — without the isolation overhead.
Teams and area paths
A team is defined by the area paths it owns. That is what makes a work item appear on one team's backlog and not another's, and it is why area path design is really team design.
What crossing a project boundary costs
Cross-project work item linking, cross-project pipeline resources and separate permission models all add friction. That friction is exactly the point when isolation is genuinely required — and pure overhead when it is not.
Primary sources