Project management and navigation glossary

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

This glossary describes terms used when navigating in the web portal for Azure DevOps. See also:


An interactive list of work items that corresponds to a team's project plan or roadmap for what the team plans to deliver. The product backlog supports prioritizing work, forecasting work by sprints, and quickly linking work to portfolio backlog items. You can define your backlog items and then manage their status using the Kanban board.

Each product backlog can be customized by a team. Learn more: Create your backlog.

Analytics views

Analytics views provide a simplified way to specify the filter criteria for a Power BI report based on the Analytics service. The Analytics service is the reporting platform for Azure DevOps Services.

Area path

Area paths are used to group work items by team, product, or feature area. Iteration paths are used to group work into sprints, milestones, or other event-specific or time-related periods. You can use area paths to define a hierarchy of paths. To learn more, see About area and iteration paths.

Boards (Kanban)

An interactive, electronic sign board that supports visualization of the flow of work from concept to completion and lean methods. Learn more: Kanban basics.


A collection is a container for a number of projects in Azure DevOps. A default collection is created when you sign up with Azure DevOps Services or install Team Foundation Server. Within Azure DevOps Services, a collection corresponds to an organization. For on-premises TFS deployments, you can add and manage collections to specify the logical and physical resources available to the projects within the collection.

Learn more: About projects and scaling your organization, Manage organizations or Manage project collections in Team Foundation Server.


Dashboards are user-configurable interactive signboards that provide real-time information. Dashboards are associated with a team and display configurable widgets to show information. To learn more, see Add and manage dashboards.


Extensions are simple add-ons that are used to customize and extend the DevOps experience of Azure DevOps. They're written with standard technologies—HTML, JavaScript, CSS—and can be developed using your preferred development tools. Hundreds of extensions are available from the Visual Studio Marketplace, Azure DevOps tab.


Tagging an object as a favorite is a method used to support quick navigation by yourself or other team members. You can tag work item queries and build definitions as personal and team favorites. Other objects you can tag as a favorite for yourself only include code branches, delivery plans, test plans, and teams or projects. To learn more, see Set personal or team favorites.


Tagging specific work items or pull requests to follow them is a method used to receive email updates about changes that are made to them. To learn more, see Follow a work item or pull request.

Git repository

A Git repository supports a distributed version control system for tracking changes, reviewing contributions to the code, and more. Each developer has a copy of the source repository on their dev machine. You can add multiple Git repositories to a project. Learn more: Git Repositories.


Git in Visual Studio and Azure DevOps Services is standard Git. You can use Visual Studio with third-party Git services, and you can also use third-party Git clients with Azure DevOps Services.


With notifications, you receive an email when changes occur to work items, code reviews, pull requests, source control files, and builds. For example, you can get notified whenever a bug that you opened is resolved, or when a work item is assigned to you. You receive notifications based on rules or subscriptions made by you, for your teams, or for the project. Learn more: About notifications.


Pipelines are artifacts that you define to run concurrent builds or deploy concurrent releases. Two types of pipelines are supported, private and hosted. To learn more, see CI/CD concurrent jobs.

Pipeline concept end-to-end

Plans (also known as delivery plans)

A plan is a configurable view that displays work from multiple teams and projects laid out within a calendar based on each team's iterations. Each row in the view represents the work from a team's product or portfolio backlog. Each card corresponds to a work item, such as user story, feature, or epic. To learn more, see Review team delivery plans.


A process defines the building blocks of a work-tracking system. To customize a process, you first create an inherited process from one of the default system processes, Agile, Scrum, or CMMI. All projects that use the process see the changes you make. To learn more, see About process customization and inherited processes.


A project, which was previously known as a team project, provides a repository for source code. A project provides a place where a group of people can plan, track progress, and collaborate on building software solutions. A project is defined for an Azure DevOps Services organization or within a TFS project collection. You can use it to focus on those objects defined within the project. To learn more, see About projects and scaling your organization.

Public projects

A project created within an Azure DevOps Services organization that is visible to the whole world. Everyone in the world can discover them and perform limited operations. You can use the Azure DevOps CLI to discover a list of projects. Administrators can control who gets to fully contribute. Administrators can switch a project from private to public, and vice-versa, as described in Change the project visibility.


Queries are used to find and list work items. Queries support managed searches, which are used to triage work, versus ad-hoc searches, which are used to find a specific work item. Flat-list queries also support status and trend charts. To learn more, see About managed queries.


A source control folder or container you configure to help you track file changes in. You can have any number of repositories on your computer, each stored in their own folder. Each repository is independent, so changes saved in one repository don't affect the contents of another. Learn more: Create a new Git repo.

Sprints (also known as iterations)

A sprint is a time period of usually two to three weeks that's used to group work items to be completed during that time period. Sprints are used in Scrum methods to support sprint planning, sprint burndown, and other Scrum processes. Sprints are defined via iteration paths. To learn more, see About area and iteration paths (aka sprints).

Sprint backlog

An interactive list of work items that have been assigned to the same sprint or iteration path for a team. The sprint backlog supports teams that use Scrum methodologies. Learn more: Sprint planning.


A taskboard is an interactive board of work items that you can use to review and update tasks defined for the sprint backlog. The taskboard supports teams that use Scrum methodologies. To learn more, see Update and monitor your taskboard.


A team corresponds to a selected set of project members. With teams, organizations can subcategorize work to better focus on all the work they track within a project. Each team gets access to a suite of Agile tools. Teams can use these tools to work autonomously and collaborate with other teams across the enterprise. Each team can configure and customize each tool to meet their work requirements. To learn more, see About teams and Agile tools.

Team Foundation Version Control (TFVC)

A centralized version control system. With TFVC, devs have only one version of each file on their dev machines. Branches are path-based and created on the server. Historical data is maintained only on the server. Learn more: Use Team Foundation Version Control.


Widgets display information and charts on dashboards. Many of them can be configured. Many widgets display information available from one or more data stores or charts created by the system. To learn more, see Widget catalog.

Work items

A work item represents an object stored in the work item data store. Each work item is based on a work item type—such as a user story, feature, bug, task, or issue— and is assigned an identifier which is unique across all projects in an organization or project collection. The work item types available to you are based on the process used when your project was created. Each work item supports capturing information, adding attachments, linking to other work items, and more. Learn more: About work items.

Work item types (WITs)

A WIT specifies the fields, workflow, and form used to track an item of work. Each WIT is associated with more than 30 system fields and several more type-specific fields. You use work items to plan and track the work required to develop your project. For an overview of predefined WITs provided with the default processes, see Choose a process.