# Managing Azure DevOps Processes and Communications

> Chapter 16 of the Courseiva AZ-400 curriculum — https://courseiva.com/learn/az-400/managing-azure-devops-processes-and-communications

**Official objective:** 8.1 — Manage Azure DevOps processes and communications

## Introduction

The AZ-400 'Manage Azure DevOps processes and communications' domain is about designing the rules of the road for your software delivery team. This concept matters because without clear processes and communication channels, teams waste time on confused handoffs, duplicated work, and missed requirements, all of which are exactly the kinds of failures the Azure DevOps Engineer Expert exam tests you to prevent.

## The Restaurant Head Chef Analogy

The Head Chef of a busy Michelin-starred kitchen. This person does not cook every dish themselves. Instead, they design the menu, set the recipes, assign stations to sous-chefs, manage the order tickets coming in, and ensure the final plate that leaves the kitchen meets the quality standard. They also handle the flow of communication: the front-of-house team calls out dietary requirements, the pastry chef signals when a dessert station is backed up, and the Head Chef decides whether to reroute a fry cook to help plating.

In this analogy, the Head Chef is managing a process. They have a backlog of orders (the list of work to do), they set swimlanes for each station (who handles what type of dish), and they enforce a definition of done: a plate is not complete until it has the correct garnish and is on the pass. When a waiter comes back with a complaint, the Head Chef does not just fix that one plate; they adjust the recipe process so the mistake does not happen again. This is managing Azure DevOps processes: designing the workflow, setting the rules for how work moves from 'To Do' to 'Done', and ensuring the communication channels between teams keep the whole kitchen running smoothly.

Just as the Head Chef cannot run a kitchen by shouting generic orders, an Azure DevOps administrator cannot manage software delivery without structured processes and clear communication artefacts. The Head Chef reviews the ticket machine (the work tracking tool), adjusts the station assignments (the process rules), and talks to the front-of-house (the stakeholders) to prioritise the next batch of orders. This is exactly what Managing Azure DevOps Processes and Communications means: designing, configuring, and governing the pathways that work and information follow from idea to delivered value.

## Core explanation

Managing Azure DevOps processes and communications is like setting up the operating manual for a team that builds software. It is not about writing code. It is about defining how work gets tracked, how people talk about that work, and how the whole system stays healthy over time. For a beginner with zero IT background, think of it as the 'business logic' of your team: the set of rules, templates, and dashboards that turn chaos into a predictable machine.

Let us start with the core piece of this puzzle: the process template. In Azure DevOps, a process template is a pre-built set of work item types (things like 'User Story', 'Bug', 'Task', 'Epic'), their states (like 'New', 'Active', 'Resolved', 'Closed'), and the rules for moving between those states. When Azure DevOps was first created, every project came with one of three templates: Basic (for simple teams), Agile (for teams that use Scrum or Kanban), or CMMI (for teams that need heavy documentation and formal approvals). The exam tests you on the fact that you can customise these templates or create new ones from scratch by using the 'Inheritance' model (you edit a process, and all projects using that process automatically get the changes) or the 'XML' model (you directly edit the XML definition files, which is older and less flexible).

The next piece is work item types. A work item is any single unit of work in Azure DevOps: a bug to fix, a feature to build, a task to complete. Managing processes means deciding exactly what types of work items your team will use, what fields they will have (like 'Priority', 'Severity', 'Effort'), and what rules constrain them (for example, 'a Bug cannot move to Closed unless the Acceptance Criteria field is filled in'). The exam loves asking about the default work item types in the Agile process: Epic (big strategic initiative), Feature (a chunk of value), User Story (a piece of functionality from the user's perspective), Task (a technical to-do), Bug (a defect), and Impediment (something blocking progress). You must know which work item type lives at which level of the hierarchy. A User Story is nested under a Feature, which is nested under an Epic. That hierarchy is not optional; it is the structure that lets leadership see progress at a high level and scrum masters see detail at the low level.

Process communications are the other half. Azure DevOps gives you several built-in communication tools. The most important for the exam is the Dashboard. A dashboard is a customisable page that shows widgets: charts of work remaining (burndown charts), progress against goals (velocity chart), test results, and links to important queries. You manage what each team sees. Another communication tool is the Wiki. Azure DevOps has a built-in wiki where you can write documentation that is version-controlled alongside your code. This replaces the old practice of keeping documentation in a separate Word document that grows stale. The exam tests that you can provision a wiki from a Git repository (code-as-documentation) or from a project-defined wiki (simpler, but not versioned with code).

Process also includes area paths and iteration paths. An area path defines the team's area of responsibility: "Database team" vs "Frontend team". An iteration path defines the time-box: "Sprint 1", "Sprint 2", "Release 2025.1". When you assign a work item to both an area and an iteration, you have told the system exactly who is doing what and when. The exam will ask you how to configure these paths in the project settings, and how they affect how work appears on backlogs and boards.

Finally, there is the concept of process governance. This is about who has permission to change the process. In Azure DevOps, permission to edit a process is controlled through the 'Process' security group. Only members of this group can modify work item types, add custom fields, change states, or delete processes. The exam will test that you know the difference between project-level permissions (who can add work items to a specific project) and organisation-level permissions (who can change the process template that multiple projects share). Remember: changing a process template affects all projects that use it, so you must be careful.

The whole system replaces the old way of working where teams used sticky notes on a wall for tasks, a separate spreadsheet for bugs, and email chains for status updates. Azure DevOps centralises these into one tool. As the person managing the process, your job is to configure Azure DevOps so that the team naturally follows good practices: they cannot close a bug without linking the code change that fixed it (a process rule), they always see the sprint goal on the dashboard (a communication widget), and they file bugs using a consistent form (a customised work item type).

## Real-world context

Meet Priya. She is a newly hired Azure DevOps Engineer at a mid-sized UK retail company called 'ShopCo'. ShopCo has three development teams: one for the website, one for the mobile app, and one for the warehouse management system. They all use Azure DevOps, but currently each team has customised their process templates independently. The website team has ten states for a bug ('New', 'Triaged', 'Assigned', 'In Progress', 'Code Review', 'Testing', 'UAT', 'Approved', 'Deployed', 'Closed'), while the warehouse team has just three ('Open', 'In Progress', 'Done'). Priya is tasked with standardising the processes without breaking anyone's workflow.

Priya starts by auditing the current processes. She goes to Organisation Settings > Process in Azure DevOps and lists all the custom processes. She sees that each team created their own inherited process from the Agile template. She realises that none of them have created a process for managing cross-team dependencies. For example, if the website team needs a new API endpoint from the warehouse team, there is no 'Dependency' work item type. They just email each other, which is a disaster waiting to happen.

Priya decides to create a single 'ShopCo Standard' process based on the Agile template. She does not start from scratch because she wants to keep the proven structure of Epics, Features, User Stories, Tasks, and Bugs. Her step-by-step action:

- She navigates to Organisation Settings > Process > Agile > '...' > 'Create inherited process' and names it 'ShopCo Standard'.
- She adds a custom work item type called 'Dependency' with fields: 'Requested By', 'Requested Date', 'Due Date', and a picklist for 'Status' with values 'Requested', 'Accepted', 'In Progress', 'Completed'. This is a new process element the exam expects you to know how to create.
- She customises the Bug work item type to add a mandatory field called 'Root Cause' with values 'Code', 'Database', 'Configuration', 'Unknown'. This enforces a process rule: no bug can be closed without root cause analysis.
- She goes to each team's project settings and changes their project to use the new 'ShopCo Standard' process. She warns the teams that they will lose any custom states they had, so she works with the warehouse team to agree on a common set of just five states for all work items: 'New', 'Active', 'Resolved', 'Closed', 'Removed'. The warehouse team compromises because they see the value in standardisation.

Next, Priya sets up communication. She creates a Wiki in each project and writes an onboarding guide and a 'How to file a Dependency' page. She builds a shared dashboard for the leadership team that shows a roll-up of all bugs across teams (using a 'Work item chart' widget pulling from a query that searches all projects). She configures the notifications so that when a Dependency work item is created, it emails the delivery managers of both teams. This replaces the old email thread chaos.

Priya also defines 'process compliance' checks. She creates a manual test that audits ten randomly selected work items each week to ensure the new rules are followed. If a 'Bug' is closed without 'Root Cause' filled in, the team gets a warning. After three warnings, the team loses the ability to close items without a manager review (she configures this using the 'Rules' feature in the process settings, which can make a field required or set a field value automatically).

Finally, Priya trains the teams. She runs a lunch-and-learn session where she shows the team leads how to drag-and-drop reorder columns on their boards without changing the underlying process. She explains that the process (states, fields, rules) is the permanent backbone, while the board columns are just a view. She emphasises that if a team wants to rename a column, they must first rename the state in the process, which affects all teams. This one rule saves months of future headaches.

Priya's work directly mirrors what an Azure DevOps Engineer Expert does: she designed a process, governed it, communicated it, and enforced it using the tools within Azure DevOps. She did not write a single line of code, but she made the whole organisation more efficient.

## Exam focus

The AZ-400 exam tests 'Manage Azure DevOps processes and communications' in three specific question formats: multiple-choice single-answer, multiple-choice multiple-answer, and 'hot area' questions (where you click on the correct UI element in a screenshot). The exam is blunt about what it wants you to know. It does not ask esoteric theory; it asks which button to click in which settings panel.

Here are the exact concepts the exam loves to test:

- Process inheritance vs XML customisation. The exam will give you a scenario: 'Your team needs a new work item type that is available across all projects. They currently use the Agile process.' The correct answer is to create an inherited process and add the type there. A trap answer will suggest editing the XML definition of the Agile process directly. That is wrong because XML customisation is for on-premises or legacy setups; for Azure DevOps Services, you use inheritance. Memorise this.
- Work item type hierarchy: The exam expects you to know that the default Agile templates have Epic > Feature > User Story. Bug and Task sit at the same level as User Story (they are child items). Impediment is a standalone type with no children. A question might say 'Which work item type should you use to represent a large body of work that spans multiple sprints?' Answer: Epic.
- State transitions and rules: The exam presents a diagram of a state workflow (e.g., New -> Active -> Resolved -> Closed) and asks you to identify which transition is invalid because of a rules conflict. Common trap: showing a transition from 'Closed' back to 'Active'. That is valid by default only if the 'Reactivate Closed Bugs' setting is enabled. Know that you can enable or disable that via process settings.
- Area and iteration paths: The exam will drop a scenario where a team's backlog shows no work items, even though they exist. The reason: the team was assigned to a root area path, but the work items were filed under an area path sub-node that the team does not own. The fix: either move the work items or add the sub-node area path to the team's configuration. The exam tests that you understand that teams are assigned to specific area paths, not the whole project by default.
- Dashboards and widgets: They ask 'Which widget would you use to show the count of bugs per priority?' Answer: 'Work item chart' widget configured with a pie chart. They also ask about the 'Sprint Overview' dashboard that shows burndown, velocity, and taskboard together. Know that dashboards are team-scoped, not project-scoped.
- Wiki provisioning: A question might say 'You want your documentation to be version-controlled alongside your code. Which Wiki type should you use?' Answer: Publish code as wiki (the Git-based wiki). The other option (project wiki) is simpler but not versioned.
- Permissions for process management: The exam tests that you know the 'Process Creator' role (part of the 'Project Collection Administrators' group) is the only one who can create new processes. A regular contributor cannot create a process, only request it. Trap: 'Team administrator can add a new work item type' is false unless that admin is also in the Process Creator role.

The exam will also test communication patterns. One scenario: 'You want to notify the development team when a critical bug is assigned.' The correct answer is to create a subscription in the Notification settings, filtered by work item type = Bug and field change = 'Assigned To'. The exam expects you to know the difference between 'team notifications' (scoped to a team) and 'organisation notifications' (global). Another trap: using a service hook to a third-party tool like Slack when the question specifically says 'within Azure DevOps'. The answer is a built-in email notification.

Finally, the exam tests 'process as code' using YAML pipelines. While this is more relevant to other exam objectives, it appears here in the context of release gates and approval processes. For example: 'You want an approval from a manager before a release to production. Which process configuration do you use?' Answer: Add a 'Post-deployment approval' gate in the release pipeline, using the 'Approvals and checks' section. This ties process management into the release side of Azure DevOps.

To pass this section, focus on hands-on practice. Open a free Azure DevOps organisation, create an inherited process, add a custom field, create a dashboard with a burndown, and watch how changes propagate. The exam rewards this tactile knowledge over abstract reading.

## Step by step

1. **Audit Existing Processes** — Go to Organisation Settings > Process in Azure DevOps. List all custom processes and note which projects use which process. Identify missing work item types (like a 'Dependency' type) or inconsistent state definitions across teams. This step prevents breaking existing workflows.
2. **Create a Custom Inherited Process** — From the default Agile process, select 'Create inherited process' and name it (e.g., 'MyCompany Standard'). This creates a clone that you can customise without affecting the original or other projects. The exam considers this the correct approach for cloud-based Azure DevOps.
3. **Add or Modify Work Item Types** — Within your new process, add custom work item types (e.g., 'Dependency', 'Spike') using the 'Work Item Types' tab. For each type, define fields (text, picklist, integer) and create rules (e.g., make a field mandatory on state transition). This is where you encode your business rules.
4. **Configure Area and Iteration Paths per Team** — In Project Settings > Iterations and Areas, create the hierarchy of area paths (e.g., 'ShopCo/Website', 'ShopCo/Warehouse') and iteration paths (e.g., 'Sprint 2025.1'). Then, for each team, go to the team's settings and select which area paths and iteration paths they own. Without this step, work items are invisible on team boards.
5. **Assign the New Process to Projects** — In Organisation Settings > Process, select your custom process and choose 'Manage projects' then 'Assign process' to each target project. Acknowledge the warning that existing work items are not retroactively changed. This step propagates the new structure to the teams.

## Comparisons

### Inherited Process vs XML (On-premises) Process

**Inherited Process:**
- Customised through the Azure DevOps web UI without coding
- Changes automatically apply to all projects using that process
- Cannot change the base system process (Agile/Basic/CMMI) itself

**XML (On-premises) Process:**
- Customised by directly editing XML definition files
- Requires system administrator access to upload the XML file
- Allows deep customisation like adding new state behaviours not possible in inheritance

### Area Path vs Iteration Path

**Area Path:**
- Represents the organisational breakdown of work (team, component, feature)
- Used to filter work items by which team owns them
- Only one area path can be assigned per work item

**Iteration Path:**
- Represents the time-box for work (sprint, release, milestone)
- Used to filter work items by when they are scheduled
- One work item can have multiple iteration paths if assigned across sprints (not typical)

### Team Notification vs Organisation-wide Notification

**Team Notification:**
- Scoped to a single team within a project
- Only members of that team receive the email
- Configured in Team Settings > Notifications

**Organisation-wide Notification:**
- Applies to all users in the organisation
- Used for global events like a release deployment or security alert
- Configured in Organisation Settings > Notifications

### Publish code as wiki vs Project wiki

**Publish code as wiki:**
- Documentation is stored in a Git repository alongside source code
- Changes to documentation go through pull requests and are versioned
- Supports offline editing via cloning the repository

**Project wiki:**
- Documentation is stored in Azure DevOps's wiki database, not a Git repo
- Edits are made directly in the browser with no version history at commit level
- Easier to set up with no repository requirements

### Work Item Bug vs Work Item Task

**Work Item Bug:**
- Represents a defect or unexpected behaviour in the software
- Has fields for severity, root cause, and repro steps
- Typically linked to a User Story or Feature as a child item

**Work Item Task:**
- Represents a unit of work that needs to be done (coding, testing, design)
- Has fields for effort estimates and activity type
- Typically a child of a User Story, but can be a child of a Bug too

### State 'Resolved' (Bug) vs State 'Closed' (Bug)

**State 'Resolved' (Bug):**
- Indicates that the fix has been implemented and is waiting for verification
- The bug is still considered 'open' for reporting purposes
- Typically only the developer or tester can set this state

**State 'Closed' (Bug):**
- Indicates that the fix has been verified and accepted by the tester or product owner
- The bug is considered complete and is excluded from active sprint counts
- Typically requires a second person (not the developer) to set this state

## Diagram

_The flow of creating a custom process template from an inherited Agile template, customising work item types and rules, assigning the process to projects, and configuring team area and iteration paths._

```mermaid
flowchart TD
    A[Organisation Settings] --> B[Process Tab]
    B --> C[Default Process: Agile]
    C --> D[Create Inherited Process: MyProcess]
    D --> E[Customize Work Item Types]
    E --> F[Add Field: Priority]
    E --> G[Add Rule: Field Required on Close]
    D --> H[Assign Process to Projects]
    H --> I[Project 1: ShopCo Web]
    H --> J[Project 2: ShopCo Mobile]
    I --> K[Team: Website Team]
    I --> L[Team: Mobile Team]
    K --> M[Area Path: ShopCo/Web]
    K --> N[Iteration Path: Sprint 1]
    L --> O[Area Path: ShopCo/Mobile]
    L --> P[Iteration Path: Sprint 1]
```

## Common misconceptions

- **Misconception:** Changing a process template immediately updates all existing work items in projects using that template. **Reality:** Changing a process template only affects the structure: new work items will use the new fields and states, but existing work items retain their current state and field values unless you force an update through a bulk edit. (Beginners assume a template is like a cookie cutter that reshapes everything. In reality, process templates define the blueprint for new items, not a retroactive update on existing data.)
- **Misconception:** The 'Agile' process is the same as using Scrum methodology. **Reality:** The 'Agile' process in Azure DevOps is just a template with specific work item types (Epic, Feature, User Story, Task, Bug). You can use it with Scrum, Kanban, or any other methodology. Methodology is about how you manage the work, not the tool template. (Microsoft naming the template 'Agile' misleads people into thinking it enforces Agile practices. It only provides a recommended set of work item types.)
- **Misconception:** Azure DevOps administrators need to know how to code in a programming language to manage processes. **Reality:** Managing processes in Azure DevOps is a configuration task done through the web UI: creating inherited processes, customising work item forms, adding fields, setting rules. No coding is required except for the 'XML' customisation path, which is legacy and rarely needed. (The term 'DevOps Engineer' makes beginners think coding is required. For this exam objective, you are a configurator, not a developer.)
- **Misconception:** A team board (Kanban board) directly reflects the underlying process state machine. **Reality:** The board columns are a view of the process states. You can map multiple states to a single column. You can also have more columns than states if you use 'swimlanes' or 'card styles'. The board is a presentation layer, not the state machine itself. (Beginners drag columns around on the board and think they are changing the process. They are only changing one team's view of the process, which can cause confusion when other teams look at the same work items.)
- **Misconception:** You can delete the default 'Basic' process template from an Azure DevOps organisation. **Reality:** You cannot delete any of the three default system processes (Basic, Agile, CMMI). You can only delete custom processes that you have created. This is a safety restriction to prevent accidental deletion of foundational templates. (Users see a delete option in the UI for custom processes and assume it works for all processes. The system processes are protected.)

## Key takeaways

- Process templates define the rules for work items, including their types, states, fields, and transitions, and are customised through inheritance for cloud projects or XML for on-premises projects.
- Work items in the Agile template follow a strict hierarchy: Epic contains Features, Features contain User Stories, and Bugs and Tasks are child items of User Stories.
- You assign work to a specific team by configuring area paths (the 'what' of the work) and iteration paths (the 'when' of the work), and a team must own the area path to see the work on their board.
- Dashboards are scoped to a team, not a project, and use widgets such as the 'Work item chart' to visualise queries, burndowns, or test results for that team.
- Notifications in Azure DevOps can be configured at the team level (for a single team's alerts) or the organisation level (for global rules), and they support email and service hooks to third-party tools.
- The 'Process Creator' role, part of the Project Collection Administrators group, is required to create or edit process templates, and this permission is distinct from project-level permissions like editing work items.
- Publishing code as a wiki from a Git repository ensures documentation is version-controlled alongside the code, while a project wiki is simpler but not stored in a Git repository.
- Approval gates in release pipelines are a form of process management, enforced through the 'Approvals and checks' configuration on a release stage.

## FAQ

**What is the difference between a process template and a project in Azure DevOps?**

A process template is the blueprint for work item types, states, fields, and rules. A project is a container for source code, work items, pipelines, and teams. A project uses one process template, and changing the template changes the rules for future work items in that project.

**Can I have two different teams in the same Azure DevOps project using different process templates?**

No. A project can only use one process template at a time. All teams within that project inherit the same work item types and rules. To use different processes, you must create separate projects.

**How do I make a field mandatory when a work item is moved to a specific state?**

Edit the work item type in the process settings. Go to the 'Rules' tab, add a new rule, set the condition to 'State = Resolved', and set the action to 'Make field required' and pick the field. This rule applies to all projects using that process.

**What happens to existing work items if I delete a custom field from the process?**

The field is removed from the form, but the data remains in the database for historical reporting. You can no longer edit the field on existing items, but it is not destroyed. To fully remove the data, you must use the REST API.

**How do I create a dashboard that shows bugs from all teams in my organisation?**

Create a new dashboard at the project level (not team level). Add a 'Work item chart' widget, then in the query pane, write a query that searches under your project and specifies work item type = Bug. The widget will aggregate across all teams.

**Why can't I see the 'Process' option in my Organisation Settings?**

You likely lack the 'Process Creator' permission. You need to be a member of the 'Project Collection Administrators' group or be explicitly granted the 'Create process' permission. Contact your organisation owner to get access.

## Check your understanding

1. **Which Azure DevOps process template would be most appropriate for a team that requires formal documentation and an audit trail of every change?**

   Answer: The CMMI (Capability Maturity Model Integration) process template, because it includes work item types for requirements, change requests, and reviews with mandatory fields for approval.

2. **You have created a custom inherited process called 'Standard' from the Agile template. You then add a custom field 'Root Cause' to the Bug work item type. Which projects will automatically get this field?**

   Answer: All projects that have been assigned the 'Standard' process will have the 'Root Cause' field appear on their Bug work item forms, for all new and existing work items.

3. **A team cannot see any work items on their Kanban board, but the project administrator confirms the work items exist in the project. What is the most likely cause?**

   Answer: The team has not been assigned an area path that matches the area path of the work items. Team boards only show work items from area paths the team owns.

4. **Which permission is required to create a new process template in Azure DevOps?**

   Answer: The 'Create process' permission, which is part of the 'Project Collection Administrators' group (also known as the 'Process Creator' role).

5. **Describe the key difference between a team dashboard and a project dashboard in Azure DevOps. **

   Answer: A team dashboard is personal to that team and only shows widgets pulling data scoped to that team's area and iteration paths. A project dashboard can show widgets that aggregate data across all teams in the project.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/az-400/managing-azure-devops-processes-and-communications