Azure Boards

As I mentioned in the previous chapter, Azure Boards is the Azure DevOps service that helps teams plan and track their work. 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.

The look and feel of Azure Boards is partially driven by the process that a team selects when they create the project. This process defines the building blocks of the work item tracking system. It also serves as the basis for any process model customization that a team might want to perform.

In this chapter I will dive into Azure Boards and discuss the various processes that can be selected, focusing on the Scrum process. I will also show you how to create an inherited process to customize Azure Boards’ behavior. In Part II of this book, “Practicing Professional Scrum,” I will delve even deeper into how the backlogs and boards explicitly support Scrum.

Choosing a Process

Several processes are available out of the box. These system processes are designed to meet the needs of most teams. Some of them are more formal, like the Capability Maturity Model Integration (CMMI) process. Some of them are lightweight, like the Basic process. Some of them are intended to match the Scrum Guide, like the Scrum process.

Here are the system processes available when creating a new project:

• Agile For teams that use agile planning methods, use user stories, and track development and test activities separately

• Basic For teams that want the simplest model that uses issues, tasks, and epics to track work

• CMMI For teams that follow more formal project methods that require a framework for process improvement and an auditable record of decisions

• Scrum For teams that practice Scrum and track Product Backlog items (PBIs) on the backlog and boards

These system processes differ mainly in the work item types that they provide for planning and tracking work. Basic is the most lightweight and closely matches GitHub’s work item types. Scrum is the next most lightweight. The Agile process is a bit “heavier” but supports many agile method terms. CMMI provides the most support for formal processes and change management.

When creating a project, a process must be selected, as you can see in Figure 3-1. After creation, the project will use the work item types, workflow states, and backlog configurations as defined by that process.

Work Item Types

Work items are the core elements of planning and tracking within Azure DevOps. They identify and describe requirements, tasks, bugs, test cases, and other concepts. Work items track what a team and team members have to do, as well as what they have done. Work items, and the metrics derived from them, can be visible within various queries, charts, dashboards, and analytics.

You can use work items to track anything that your team needs to track. Each work item represents an object stored in the work item data store. 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). 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.

TABLE 3-1 Work item categories available across the different processes.

	Scrum	Agile	CMMI	Basic
Work Item Category
Requirement	Product Backlog Item	User Story	Requirement	Issue
Epic	Epic	Epic	Epic	Epic
Feature	Feature	Feature	Feature	-
Bug	Bug	Bug	Bug	Issue
Task	Task	Task	Task	Task
Test Case	Test Case	Test Case	Test Case	Test Case
Issue	Impediment	Issue	Issue	-
Change Request	-	-	Change Request	-
Review	-	-	Review	-
Risk	-	-	Risk	-

As you can see, the Agile process is very similar to the Scrum process. As far as work item types are concerned, the only differences are the type names of the Requirement and Issue work item categories. Agile refers to them as a User Story and Issue, respectively, whereas Scrum refers to them as a Product Backlog Item and Impediment, respectively. Figure 3-2 shows an example of this.

You can also see how heavy and formal the CMMI process is, with official Change Request, Review, and Risk work item types, as well as the antiquated Requirement work item type. I’ve helped hundreds of teams install, understand, and use Azure DevOps and Team Foundation Server and can count the number of CMMI projects I’ve run into on one hand. Conversely, the Basic process has only a few work item types—just barely sufficient to track work and also to more closely match how work is managed on GitHub. It is also the default process, so there are many Basic process projects in existence, if only by accident.

Another distinguishing feature of the different processes is the workflow states for the requirement category work item types. The workflow states define how a work item progresses upon its creation to its closure. You can see this natural progression by process in Table 3-2. Each state belongs to a state category (formerly known as a metastate). State categories enable the agile tools in Azure Boards to operate in a standard way regardless of the project’s process.

TABLE 3-2 Requirement workflow states across the different processes.

Scrum	Agile	CMMI	Basic
New	New	Proposed	To Do
Approved	Active	Active	Doing
Committed	Resolved	Resolved	Done
Done	Closed	Closed
Removed	Removed

Hidden Work Item Types

Team Foundation Server 2012 introduced the concept of a hidden work item type. Work item types that are in this category are not able to be created from the standard user interfaces, such as the New Work Item drop-down list in Azure Boards. The reasoning behind this is that there are specialized tools for creating and managing these types of work items. Besides, creating these types of work items in an ad hoc way outside the context of the tooling doesn’t make sense.

All processes, even the Basic one, support these hidden work item types:

• Shared Parameter, Shared Steps, Test Plan and Test Suite Created and managed by the tools in Azure Test Plans. I will take a closer look at all the testing work item types in Chapter 7, “Planning with Tests.”

• Feedback Request and Feedback Response Used to request and respond to stakeholder feedback using the Test & Feedback extension.

• Code Review Request and Code Review Response Used to exchange messages in legacy Team Foundation Version Control (TFVC) code review in the My Work page in Visual Studio Team Explorer. These code reviews are not to be confused with those related to Git pull requests.

Microsoft knew that teams typically wouldn’t be creating these work item types outside the context of their dedicated tools. They actually did us a favor by hiding them from the various UIs where we create and manage work items. Referring back to Figure 3-2, notice that there weren’t any of these hidden work item types listed.