About default processes and process templates

TFS 2018

Azure Boards offers various processes to choose from for managing work items. Selecting the right process is essential for optimizing the workflow and ensuring the success of a project. In this article, we explore the different processes available Azure Boards and provide guidance on how to choose the most suitable one for 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.

The work tracking objects contained within the default processes and process templates—Basic, Agile, Capability Maturity Model Integration (CMMI), and Scrum—are the same and summarized in this article.

Default processes

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 provides the most support for formal processes and change management.

If you need more than two or three backlog levels, 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, customize a process, and then create the project. Or, 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.

• Add work items from the product backlog or Kanban board. The product backlog shows a single view of the current backlog of work that can be dynamically reordered 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.
• 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 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.

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. Update the status of a work item using the Kanban board or the taskboard by dragging it to its corresponding state column.

Change the workflow to support other states, transitions, and reasons. For more information, see Customize your work tracking experience.

Work item states

When you change the state of a work item to Removed, Closed, or Done, the system responds as follows:

• Closed / 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.

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. Use a record to create queries or reports.

If you need to permanently delete work items, see Remove or delete work items.

WITs added to all processes

The following WITs are added to all processes except the Basic process.

Your team can create and work with these types using the corresponding tool:

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, 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 WITs as you would any other WIT. For more information, 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.

Related articles

• Customize your work tracking experience
• Upload and download process templates