Note
Access to this page requires authorization. You can try signing in or .
Access to this page requires authorization. You can try .
Default processes and process templates
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Azure Boards offers several processes for managing work items. Selecting the right process helps optimize your project workflow and sets your team up for success. This article describes the processes available in Azure Boards and helps you choose the one that fits your project.
When you create a project, you choose a process or process template based on the process model for which your organization or collection was created. Before you choose a process for your project, you should understand the following terms.
| Term | Description |
|---|---|
| Process model | Refers to the model used to support projects created for an organization or project collection. Only one process model is supported for a project at a time. |
| Process | Defines the building blocks of the work item tracking system and supports the Inheritance process model for Azure Boards. This model supports customization of projects through a visual editor in the Azure DevOps web portal. |
| Process template | Defines the building blocks of the work item tracking system and other subsystems you access through Azure DevOps. Process templates are only used with the Hosted XML and On-premises XML process models. You can customize projects by modifying and importing process template XML definition files. |
The default process types are Basic, Agile, Capability Maturity Model Integration (CMMI), and Scrum. The work tracking objects in the default processes and process templates are the same. This article summarizes them.
Tip
With Azure DevOps Server, you can select either the Inherited process model or the On-premises XML process model. For more information, see Choose the process model for your project collection. To access the latest versions of the default processes or process templates:
Inherited process model: Open the Processes page. For more information, see Manage processes.
On-premises XML process model:
- Install or upgrade to the latest version of Azure DevOps Server.
- Download the zipped template file using the Process Template Manager. Use a version of Visual Studio at the same version level as Azure DevOps Server. You can install the latest version of Visual Studio Community for free.
- Access the latest default process templates installed on Azure DevOps Server, for example:
%programfiles%/Azure DevOps Server 2020/Tools/Deploy/ProcessTemplateManagerFiles/1033. For descriptions of each file and folder, see Overview of process template files.
Default processes
The default processes mainly differ in the work item types they provide for planning and tracking work. Use the following guide to choose the process that fits your team:
- Choose Basic for the simplest experience - track work as Epics, Issues, and Tasks.
- Choose Agile if your team uses Agile methods and you want to track User Stories with separate development and test activities.
- Choose Scrum if your team follows Scrum and tracks Product Backlog Items and Bugs.
- Choose CMMI if your team needs formal change management, an auditable record of decisions, and tracking for Requirements, Change Requests, Risks, and Reviews.
Choose the right process
If you're not sure which process fits your team, use the following scenarios as a starting point:
| Scenario | Recommended process | Why |
|---|---|---|
| You're new to Azure Boards or want the lightest-weight tracking. | Basic | Three work item types (Epic, Issue, Task) and a simple To Do / Doing / Done workflow. |
| Your team practices Agile, tracks user stories, and separates development from test work. | Agile | User Stories with separate Bug tracking; richer states (New, Active, Resolved, Closed, Removed). |
| Your team practices Scrum with sprints, product backlog items, and impediments. | Scrum | Product Backlog Items and Bugs on the board; Approved and Committed states map directly to Scrum ceremonies. |
| You work in a regulated environment that requires formal change control, an auditable record of decisions, and risk and review tracking. | CMMI | Adds Requirement, Change Request, Risk, and Review work item types and supports formal change-management activities. |
Important
You can't change a project's base process after the project is created. You can customize an inherited process to add fields, states, and work item types, or you can create a new project on a different process and move work items between projects.
Note
Choosing or customizing a process requires membership in the Project Collection Administrators group. For more information, see Default permissions quick reference.
| Process | Work item hierarchy |
|---|---|
| Basic Choose Basic when your team wants the simplest model that uses Issue, Task, and Epic work item types to track work. Tasks support tracking Remaining Work. |
👁 Diagram shows Basic work item types in a hierarchy. |
| Agile Choose Agile when your team uses Agile planning methods, including Scrum, and tracks development and test activities separately. This process works great for tracking User Stories and, optionally, bugs on the board. You can also track bugs and tasks on the taskboard. For more information about Agile methodologies, see Agile Alliance. Tasks support tracking Original Estimate, Remaining Work, and Completed Work. |
👁 Diagram shows Agile work item types in a hierarchy. |
| Scrum Choose Scrum when your team practices Scrum. This process works great for tracking product backlog items and bugs on the board. You can also break down product backlog items and bugs into tasks on the taskboard. This process supports the Scrum methodology as defined by the Scrum organization. Tasks support tracking Remaining Work only. |
👁 Diagram shows Scrum work item types in a hierarchy. |
| CMMI Choose CMMI when your team follows more formal project methods that require a framework for process improvement and an auditable record of decisions. With this process, you can track requirements, change requests, risks, and reviews. This process supports formal change management activities. Tasks support tracking Original Estimate, Remaining Work, and Completed Work. |
👁 Diagram that shows CMMI work item types in a hierarchy. |
If you need more than two or three backlog levels, add more based on the process model that you use:
- Inheritance: Customize your backlogs or boards for a process
- Hosted XML or On-premises XML: Add portfolio backlogs
Main distinctions among the default processes
The default processes meet the needs of most teams. If your team has unusual needs and connects to an on-premises server, customize a process and then create the project. You can also create a project from a process and then customize the project.
The following table summarizes the main distinctions between the work item types and states used by the four default processes.
| Tracking area | Basic | Agile | Scrum | CMMI |
|---|---|---|---|---|
| Workflow states | - To Do - Doing - Done |
- New - Active - Resolved - Closed - Removed |
- New - Approved - Committed - Done - Removed |
- Proposed - Active - Resolved - Closed |
| Product planning (see Note 1) | - Issue | - User Story - Bug (optional) |
- Product backlog item - Bug (optional) |
- Requirement - Bug (optional) |
| Portfolio backlogs (see Note 2) | - Epic | - Epic - Feature |
- Epic - Feature |
- Epic - Feature |
| Task and sprint planning (see Note 3) | - Task | - Task - Bug (optional) |
- Task - Bug (optional) |
- Task - Bug (optional) |
| Bug backlog management (see Note 1) | - Issue | - Bug | - Bug | - Bug |
| Issue and risk management | - Issue | - Issue | - Impediment | - Change Request - Issue - Risk - Review |
Note
- Add work items from the product backlog or board. The product backlog shows a single view of the current backlog of work that you can dynamically reorder and group. Product owners can prioritize work and outline dependencies and relationships. Each team can configure how they want bugs to show up on their backlogs and boards.
- Define a hierarchy of portfolio backlogs to understand the scope of work across several teams and see how that work rolls up into broader initiatives. Each team configures which portfolio backlogs appear for their use.
- Define tasks from the sprint backlog and taskboard. With capacity planning, teams can determine if they're over capacity or under capacity for a sprint.
Workflow states, transitions, and reasons
Workflow states support tracking the status of work as it moves from a New state to a Closed or a Done state. Each workflow consists of a set of states, the valid transitions between the states, and the reasons for transitioning the work item to the selected state.
Important
Workflow transitions: The default workflows in Azure DevOps support any-state-to-any-state transitions. You can customize these workflows to restrict specific transitions based on your team's requirements. For more information, see Customize your work tracking experience.
Visualizing workflows: To view the supported workflow transitions for each work item type, install the State Model Visualization Marketplace extension. This extension adds a State Visualizer hub under Boards where you can select a work item type and view its complete workflow state model.
The following diagrams show the typical forward progression of those work item types used to track work and code defects for the three default processes. They also show some of the regressions to former states and transitions to removed states.
Each image shows only the default reason associated with the transition.
Most work item types used by Agile tools, the ones that appear on backlogs and boards, support any-to-any transitions. Update the status of a work item by using the board or the taskboard. Drag a work item to its corresponding state column.
Change the workflow to support other states, transitions, and reasons. For more information, see Customize your work tracking experience.
How Removed, Closed, and Done states behave on backlogs
When you change the state of a work item to Removed, Closed, or Done, the system responds as follows:
ClosedorDone: Work items in this state don't appear on portfolio backlog or backlog pages, but they do appear on the sprint backlog pages, board, and taskboard. When you change the portfolio backlog view to Show backlog items - for example, to view features alongside product backlog items - work items in theClosedandDonestates also appear.Removed: Work items in this state don't appear on any backlog or board.
Note
The default CMMI workflow doesn't include a Removed state. To take a CMMI work item out of active tracking, set its state to Closed and choose an appropriate reason (for example, Deferred or Rejected). You can customize an inherited process to add a Removed state if your team needs one.
Your project maintains work items as long as the project is active. Even if you set work items to Closed, Done, or Removed, the data store keeps a record. You can use this record to create queries or reports.
Note
Completed or closed work items don't display on the backlogs and boards after their Changed Date value is greater than 183 days (about a half a year). You can still list these items by using a query. If you want them to show up on a backlog or board, you can make a minor change to them, which resets the clock.
Note
Completed or closed work items don't display on the backlogs and boards after their Changed Date value is greater than a year old. You can still list these items by using a query. If you want them to show up on a backlog or board, you can make a minor change to them, which resets the clock.
If you need to permanently delete work items, see Remove or delete work items.
Work item types added to all processes
The following work item types are added to all processes except the Basic process.
Your team can create and work with these types by using the corresponding tool. These work item types remain in the schema for historical compatibility. Microsoft Test Manager and the Team Explorer My Work experience are legacy tools that are largely replaced by the web portal.
| Tool | Work item types |
|---|---|
| Microsoft Test Manager (legacy) | Test Plan, Test Suite, Test Case Shared Steps, Shared Parameters |
| Request Feedback | Feedback Request, Feedback Response |
| My Work (from Team Explorer, legacy), Code Review | Code Review Request, Code Review Response |
You can't manually create work items from these type definitions. They're added to the Hidden Types category. Work item types added to the Hidden Types category don't appear on the menus that create new work items.
Work item types that support the test experience
The link types shown in the following image connect work item types that support the test experience and work with Test Manager and the web portal.
👁 Diagram that shows test management work item types.
From the web portal or Microsoft Test Manager, you can view which test cases are defined for a test suite and view which test suites are defined for a test plan. However, these objects aren't connected to each other through link types. Customize these work item types as you would any other work item types. For more information, see Customize your work tracking experience.
If you change the workflow for the test plan and test suite, you might need to update the process configuration as described in this article. For definitions of each test field, see Create a query based on build and test integration fields.
Related content
Feedback
Was this page helpful?