Agile refers to them as a User Story and Issue, respectively, whereas Scrum refers to them as a Product Backlog Item and Impediment, respectively. As far as work item types are concerned, the only differences are the type names of the Requirement and Issue work item categories. TABLE 3-1 Work item categories available across the different processes.Īs you can see, the Agile process is very similar to the Scrum process. The work item types that are available to the project are based on the process used when the project was created, as you can see in Table 3-1. Each work item is based on a work item type and is assigned an identifier that is unique within an organization (or project collection in Azure DevOps Server). Each work item represents an object stored in the work item data store. You can use work items to track anything that your team needs to track. Work items, and the metrics derived from them, can be visible within various queries, charts, dashboards, and analytics. Work items track what a team and team members have to do, as well as what they have done. They identify and describe requirements, tasks, bugs, test cases, and other concepts. Work items are the core elements of planning and tracking within Azure DevOps. Process templates are expressed in XML and support customization through the modification and importing of XML definition files. A process template is the legacy way of defining the building blocks of the work item tracking system. It’s available in Azure DevOps Services and Azure DevOps Server, but not for legacy Team Foundation Server versions.
A process defines the building blocks of the work item tracking system, supports the inheritance process model, and supports customization through a rich UI. Note A process is different than a process template.
After creation, the project will use the work item types, workflow states, and backlog configurations as defined by that process. When creating a project, a process must be selected, as you can see in Figure 3-1. CMMI provides the most support for formal processes and change management. The Agile process is a bit “heavier” but supports many agile method terms. Basic is the most lightweight and closely matches GitHub’s work item types. These system processes differ mainly in the work item types that they provide for planning and tracking work. Scrum For teams that practice Scrum and track Product Backlog items (PBIs) on the backlog and boards Here are the system processes available when creating a new project:Īgile For teams that use agile planning methods, use user stories, and track development and test activities separatelyīasic For teams that want the simplest model that uses issues, tasks, and epics to track workĬMMI For teams that follow more formal project methods that require a framework for process improvement and an auditable record of decisions Some of them are intended to match the Scrum Guide, like the Scrum process. Some of them are lightweight, like the Basic process. Some of them are more formal, like the Capability Maturity Model Integration (CMMI) process. These system processes are designed to meet the needs of most teams. Several processes are available out of the box.
In Part II of this book, “Practicing Professional Scrum,” I will delve even deeper into how the backlogs and boards explicitly support Scrum.
I will also show you how to create an inherited process to customize Azure Boards’ behavior. In this chapter I will dive into Azure Boards and discuss the various processes that can be selected, focusing on the Scrum process. It also serves as the basis for any process model customization that a team might want to perform. This process defines the building blocks of the work item tracking system.
The look and feel of Azure Boards is partially driven by the process that a team selects when they create the project. It’s the service that provides the work items, backlogs, boards, queries, and charts-all the building blocks that a team needs to visualize and manage their work. As I mentioned in the previous chapter, Azure Boards is the Azure DevOps service that helps teams plan and track their work.