Choose a process flow or process template to work in Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018
Anytime you create a project, you must choose a process or process template based on the process model selected for your organization or collection. When choosing a process for your project, it's important to understand the following terms:
- A process model refers to the model used to support projects created for an organization (Azure DevOps Services) or project collection (Azure DevOps Server). Only one process model is supported for a project at a time. A comparison of the three process models—Inheritance, On-premises XML, and Hosted XML—is provided in Customize work tracking.
- A 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 WYSIWYG user interface.
- A 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 customize projects by modifying and importing process template XML definition files.
For guidance on configuring and customizing your project and teams to support your business needs, review Configuration and customization of Azure Boards.
For details on creating a project using the process of your choice, see Create a project. To learn more about process models, see Customize your work tracking experience.
With Azure DevOps Server, you can choose between using the Inherited process model or the On-premises XML process model. For details, see Customize your work tracking experience, Choose the process model for your project collection. To access the latest versions of the default processes/process templates:
- For Inherited process model: Open the Process page from organizations settings. To learn more, see Manage processes.
- For the 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. You'll need to use a version of Visual Studio that is at the same version level as Azure DevOps Server. You can install the latest version of Visual Studio Community for free.
- You can access the latest versions of the 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.
To access the latest versions of the default process templates:
- Install or upgrade to the latest version of TFS.
- Download the zipped template file using the Process Template Manager. You'll need to use a version of Visual Studio that is at the same version level as TFS. You can install the latest version of Visual Studio Community for free.
- You can access the latest versions of the default process templates installed on TFS 2018 here:
%programfiles%/TFS 16.0/Tools/Deploy/ProcessTemplateManagerFiles/1033. For descriptions of each file and folder, see Overview of process template files.
The work tracking objects contained within the default processes and process templates—Basic, Agile, CMMI, and Scrum—are the same and summarized below. The Basic process is available from Azure DevOps Server 2019.1 and later versions. For simplicity, they're referred to as a "process."
To view and manage Inherited process models, see Manage processes.
Choose a Basic, Agile, Scrum, and CMMI process
The default processes differ mainly in the work item types (WITs) they provide for planning and tracking work.
Basic is the most lightweight and is in a selective Preview. Scrum is the next most lightweight. Agile supports many Agile method terms, and CMMI, which stands for Capability Maturity Model Integration, provides the most support for formal processes and change management.
The Basic process is available with Azure DevOps Server 2019 Update 1 and later versions.
Choose the process that provides the best fit for your team.
Choose Basic when your team wants the simplest model that uses Issues, Tasks, and Epics to track work.
Tasks support tracking Remaining Work.
Choose Agile when your team uses Agile planning methods, including Scrum, and tracks development and test activities separately. This process works great if you want to track user stories and (optionally) bugs on the Kanban board, or track bugs and tasks on the taskboard.
You can learn more about Agile methodologies at the Agile Alliance.
Tasks support tracking Original Estimate, Remaining Work, and Completed Work.
Choose Scrum when your team practices Scrum. This process works great if you want to track product backlog items (PBIs) and bugs on the Kanban board, or break down PBIs 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.
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.
If you need more than two or three backlog levels, you can add more based on the process model 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 are designed to meet the needs of most teams. If your team has unusual needs and connects to an on-premises server, you can customize a process and then create the project. Or, you can create a project from a process and then customize the project.
The following table summarizes the main distinctions between the WITs and states used by the four default processes.
- To Do
Product planning (see note 1)
- User story
- Bug (optional)
- Product backlog item
- Bug (optional)
- Bug (optional)
Portfolio backlogs (2)
Task and sprint planning (3)
- Bug (optional)
- Bug (optional)
- Bug (optional)
Bug backlog management (1)
Issue and risk management
- You can add these WITs from the product backlog or Kanban board. The product backlog shows a single view of the current backlog of work that can be dynamically re-ordered and grouped. Product owners can quickly prioritize work and outline dependencies and relationships.
Also, each team can configure how they want bugs to show up on their backlogs and boards.
- With portfolio backlogs you can define a hierarchy of backlogs to understand the scope of work across several teams and see how that work rolls up into broader initiatives. Each team can configure which portfolio backlogs appear for their use.
- You can define tasks from the sprint backlog and taskboard. With capacity planning, teams can quickly determine if they are over 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.
For Azure DevOps Services and Azure DevOps Server 2019, the default workflow transitions support any state to any state transition. You can customize these workflows to restrict some transitions .See Customize work tracking objects to support your team's processes.
Also, you can view the supported workflow transitions for each work item type by installing the State Model Visualization Markeplace extension. This extension adds a new hub under Boards labeled State Visualizer. On that page you can choose a work item type and view the workflow state model.
The following diagrams show the typical forward progression of those WITs 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 WITs used by Agile tools, ones that appear on backlogs and boards, support any-to-any transitions. You can update the status of a work item using the Kanban board or the taskboard by dragging it to its corresponding state column.
You can change the workflow to support other states, transitions, and reasons. To learn more, see Customize your work tracking experience.
Removed, Closed, and Done states
When you change the state of a work item to Removed, Closed, or Done, the system responds like this:
- Closed or Done: Work items in this state don't appear on the portfolio backlog and backlog pages. However, they do appear on the sprint backlog pages, Kanban board, and taskboard. Also, when you change the portfolio backlog view to show backlog items, for example, to view Features to Product Backlog Items, work items in the closed and done state appear.
- Removed: Work items in this state don't appear on any backlog or board.
Work items are maintained in a project as long as the project is active. Even if you set them to Closed, Done, or Removed, a record is kept in the data store. You can use a record to create queries or reports.
Completed or closed work items don't display on the backlogs and boards once their Changed Date is greater than 183 days (about a half a year). You can still list these items using a query. If you want them to show up on a backlog or board, then you can make a minor change to them which resets the clock.
Completed or closed work items don't display on the backlogs and boards once their Changed Date is greater than a year old. You can still list these items using a query. If you want them to show up on a backlog or board, then 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 WITs are added to all processes except the Basic process.
Teams create and work with these types using the corresponding tool:
- Test Plan, Test Suite, Test Case Shared Steps, and Shared Parameters: Microsoft Test Manager.
- Feedback Request and Feedback Response: Request feedback.
- Code Review Request and Code Review Response: My Work (from Team Explorer) and Code Review Request.
Work items from these type definitions aren't meant to be created manually and are then added to the Hidden Types category. Work item types added to the Hidden Types category don't appear in the menus that create new work items.
WITs that support the test experience
WITs that support the test experience and work with Test Manager and the web portal are linked together using the link types shown in the following picture.
From the web portal or Microsoft Test Manager, you can view which test cases are defined for a test suite. And you can view which test suites are defined for a test plan. However, these objects aren't connected to each other through link types. Customize these WITs as you would any other WIT. See Customize work tracking objects to support your team's processes.
If you change the workflow for the test plan and test suite, you might need to update the process configuration as described here. For definitions of each test field, see Query based on build and test integration fields.
You can customize a process before or after you create a project that uses the process. The methods you use depend on the process model you use. To learn more, see Customize your work tracking experience.
- Upload/download process templates
- Changes made to process templates
- Configure features after an Azure DevOps Server upgrade
If you have more questions, see Azure DevOps support page.
Submit and view feedback for