Configure projects and teams in Azure DevOps

One project or many?

Starting with one project is a recommended approach: it minimizes administration and provides the most optimized cross-link experience.

Choose multiple projects when	Why
Access must be prohibited or managed for select groups	Access and permission administration is project-scoped
A business unit needs a distinct custom work-tracking process	A process is selected per project
An entirely separate business unit needs its own policies and administrators	Teams, dashboards, and settings are administered within a project
Customizations need a safe test project	Changes can be validated away from production work
Work is open source or the organization has a very-large-scale layout	A separate project can provide the required operating scope

A project scopes stored data, access, administration, and process assignment; it is not automatic hard isolation. Organization membership and visibility settings still matter. Several projects can use the same inherited process and receive its customizations.

Teams and backlog contents

Each team gets backlogs, boards, dashboards, and configurable assets. The team's selected area and iteration paths determine which work items appear on its backlog and board.

Those paths are not the only inputs: active backlog levels, workflow state and parent-child status, and bug behavior can also affect the view.

What crossing a project boundary costs

Cross-project work is supported, but it is more explicit. A single project provides the optimized cross-link experience. Cross-project pipeline resources require a project reference and resource authorization, while access, teams, dashboards, and settings remain project-scoped administration. Project boundaries do not remove Git support.

Primary sources

Projects and teams in Azure DevOps

Configure projects and teams in Azure DevOps

One project or many?

Teams and backlog contents

What crossing a project boundary costs