Azure Boards

By Richard Hundhausen
2/17/2021

Contents

Process Customization

As you’ve learned, each Azure DevOps project is based on a process that defines the building blocks for tracking work. Of the out-of-the-box system processes, the Scrum process most closely matches the Scrum Guide, but not entirely. There has been some drift over the past 10 years.

Fortunately, you can customize the Scrum process to make it more closely match the Scrum Guide, and even your own organization or team’s specific needs. Achieving this requires you to create an inherited process first and then make customizations to that. Any changes you make to the inherited process automatically appear in the projects that use that process. You cannot make changes to the system processes.

You primarily customize a process by adding or modifying its work item types. This is done through an administrative user interface in the web portal.

The general sequence for process customization looks like this:

Create an inherited process Select a system process (for example, Scrum) and create an inherited process (such as Professional Scrum) based on it.
Customize the inherited process Add or modify work item types, work item fields, work item workflow states, and work item form UIs. You can also update backlog behavior.
Apply inherited process to project(s) Create new projects using the inherited process or change existing projects to use the new inherited process.
Refresh and verify Refresh the web portal and explore the changes to the work items and backlogs.

Professional Scrum Process

If your organization or team cares about the Scrum Guide and wants to address the drift between it and the system Scrum process, you should consider following the instructions in this section to create a custom, inherited Professional Scrum process. Doing so is completely optional but may result in a better experience for Scrum teams. It will also help organizations and teams that are just adopting Scrum where precise language and terms are important for establishing a new mental model.

Process customization takes place at the organization level (or at the collection level for the on-premises Azure DevOps Server). You can select any of the system processes and create an inherited process, as I’ve done with the Scrum process in Figure 3-16.

FIGURE 3-16 Creating a Professional Scrum process from the Scrum system process.

After I create the inherited Professional Scrum process and set it to be the default process, I then disable the Bug work item type. This allows the Scrum Team to use the PBI work item type for all work in the Product Backlog. Teams can add a “Bug” tag to those PBIs if they wish.

Next, I update the Product Backlog Item work item type, making the following changes:

Hide the Priority and Value Type fields from the layout I would like to remove these fields altogether, but that customization isn’t allowed in Azure Boards.
Change the Effort label to Size I could also create a new Size field behind the scenes, but I will leave the Effort field in use.
Change the Business Value label to “Value” I could also create a new value field behind the scenes, but I will leave the Business Value field in use.
Rename the Details group to “ROI” The only two fields in this group now are related to ROI. It would be awesome to include a computed ROI field, but that functionality is not available outside of using an extension.

Next, I make changes to the workflow states by adding two new states: Ready (which maps to the Proposed category) and Forecasted (which maps to the In Progress category). I keep the default colors for these new states. Next, I hide the Approved and Committed states, replacing them with the Ready and Forecasted states that I just created, as you can see in Figure 3-17.

FIGURE 3-17 Customizing PBI workflow states in the Professional Scrum process.

For organizations and teams that use the Epic and Feature work item types, you can make similar customizations by hiding those extraneous fields that you don’t use (e.g., Priority, Time Criticality, Value Area, and even Start Date and Target Date). You could also rename the labels and normalize the workflow states, as I did for the PBI work item type.

I also hide the Priority and Activity fields from the Task work item type. The last customization I do is to rename the lowest leaf-level backlog from “Backlog items” to “Stories” (or whatever the organization/team would like it to be called). Leaving it named Backlog items is confusing, because in actuality, all backlog levels contain “backlog items.”

After these changes are made, I can start creating projects based on the Professional Scrum process. If I have any existing projects, I can also change them to use the new Professional Scrum process, which you can see in Figure 3-18. Later, if I make any changes to the Professional Scrum process, all projects based on it will instantly reflect that change.

FIGURE 3-18 PBI work item form after applying the Professional Scrum process.

Other Customizations

Beyond matching the Scrum process to the Scrum Guide, organizations and teams may want to make additional customizations to work items and backlogs. Here are some examples I’ve collected over the years from various teams and other consultants:

Add a Team field to the PBI work item type to indicate which team owns it, rather than using the Area field gimmick.
Add a Value Stream work item type and corresponding top-level backlog that sits above Epic.
Add a Planned Sprint field to the Impediment work item type for planning when the improvement will be done. The system Iteration field can be used for the Sprint where the impediment was discovered.
Add a new workflow state to the Impediment work item type to indicate which improvement(s) are currently in-progress.
Add an Improvement work item type to plan and track any improvement experiments being performed.
Add a Remaining Work field to the PBI work item type to store the rolled-up sum of any child task Remaining Work values. External automation, such as an extension, would be required to do the rolling up.
Add default user story description text (“As a <type of user>, I want <some goal> so that <some reason>”) to the Description field of the PBI work item type.
Add default text to the PBI work item type Acceptance Criteria fields to suggest a “given-when-then” behavior-driven development (BDD) or “given-when-then-fail” format.
Add a Hypothesis work item type to support hypothesis-driven development.

Tip Use your Scrum or Professional Scrum process the way that it was designed for a few Sprints before customizing anything. I’ve seen teams want to immediately make their new project look and behave like their old project or culture. For example, if after reading this book you decide to abandon your Agile process project, creating a new Professional Scrum project, don’t immediately add the fields that used to be in your old project (for example, the Original Estimate and Completed (hours) fields in the Task work item type—which we removed from the Scrum process for a reason; tracking original estimates and actual hours are generally considered waste). Just know what you are doing and why you are doing it before making any “improvements” and weigh the benefits against potential waste and misuse. Don’t inadvertently change the rules of Scrum by customizing the tool!