The AZ-400 exam's work tracking and metrics section asks how you design workflows and measure team performance. Which work item type belongs at which level of Azure Boards, how GitHub Issues connects to Azure DevOps, and what DORA's four metrics actually tell you — these are the questions worth understanding deeply, not just memorizing.
Work Item Hierarchy: How Far Do You Break It Down?
Imagine building an apartment complex. The entire complex is the project, each building is a major feature, each floor is a user-facing capability, and each individual room is a task someone needs to complete. Azure Boards organizes work the same way.
At the top sits the — a large body of work that spans multiple teams and quarters. Below that is a , which represents a deliverable capability. A is what a single team can complete within one sprint: the smallest unit of business value that can stand on its own. Below that are items for individual developer work, and items for defects.
The exact names depend on the process template you choose. The template uses User Stories. The template calls the same concept a Product Backlog Item (PBI). The template is the only one that ships with Change Request, Requirement, Risk, and Review as native work item types — making it the right choice for organizations under ISO 9001 or formal audit requirements. The template keeps it simple with just Issue and Task, ideal for small teams getting started.
When an exam question mentions "team autonomy and sprint tracking," reach for the Agile template and User Stories. When it says "regulatory compliance and formal change management," CMMI is the answer.
Boards, Backlogs, and Sprints: Three Views, One Truth
Think of a restaurant kitchen at dinner rush. The head chef needs to see all orders at once (the backlog), the line cooks need to know which dish they're preparing right now (the board), and the manager checks tonight's output against the plan (sprint metrics). Azure Boards gives each role exactly that view.
The view is your Kanban wall — cards move across columns as state changes. WIP (Work in Progress) limits per column prevent too many items from being active at once and force the team to finish before starting new work.
The view is a priority-ordered list of everything planned. The Sprint Backlog narrows this to the current sprint's committed items.
filter work items by custom conditions. Results can be pinned as dashboard widgets, so a well-written query is the foundation of any useful dashboard.
Work item state flow in the Agile process: . Code merged but QA still pending = . All validation done = . Sprint velocity counts only items.
GitHub Issues and the ABBridge
Developers live in GitHub. Their code is there, their pull requests are there, and their conversations about changes happen there too. Forcing developers to switch to a separate system every time they want to log a task introduces friction that slows the whole team down.
GitHub Issues keeps work tracking in the same environment as the code. GitHub Projects adds a Kanban layer on top, offering Board, Table, and Roadmap views over those issues. For teams fully on GitHub, this is a natural choice.
For organizations running both Azure DevOps and GitHub, the mention is the bridge. When a developer writes in a commit message or pull request body, Azure Boards automatically creates a link on work item 1234. When that PR is merged into the default branch, the work item's state updates to automatically. In the other direction, Azure Boards shows the linked PR directly on the work item's detail page.
This two-way traceability is what the exam means by "end-to-end traceability." You can follow any production incident back to the PR that introduced it, the User Story it was implementing, and the Feature it belonged to.
GitHub-first teams benefit from the tighter code-issue integration GitHub Issues provides. Organizations already on Azure DevOps get stronger hierarchy, richer queries, and broader compliance reporting from Azure Boards.
DORA's Four Metrics: Health by the Numbers
A doctor doesn't guess whether a patient is healthy — they check blood pressure, heart rate, and temperature. DORA metrics apply the same logic to DevOps teams, turning "we think we're getting better" into trackable, comparable numbers.
measures how often the team deploys to production. Elite teams deploy multiple times per day. A team that deploys once a month is at the Low level. Higher frequency means smaller, safer releases.
is the time from a code commit to that code running in production. This measures the entire pipeline — from writing the code through build, test, review, and deployment. Shorter lead times mean the team delivers value faster and gets feedback sooner.
measures how long it takes to recover from a production incident. Elite teams restore service in under an hour. High MTTR often points to poor observability or a lack of automated rollback capability.
is the percentage of deployments that cause incidents, rollbacks, or hotfixes. A team deploying ten times a day with a 30% failure rate is making things worse, not better. Lower is always better here.
Thinking about these in pairs helps. and together measure speed — how fast the team moves. and together measure stability — how reliably the team operates. Elite DevOps performance is high speed and high stability at the same time.
!DORA's four metrics
Dashboard Design: Making the Numbers Visible
Data that nobody can see doesn't drive decisions. A great dashboard is like a car's instrument panel: it shows the critical numbers at a glance, so the driver can respond before something goes wrong.
Azure DevOps Dashboards are widget-based. You drag Deployment Frequency widgets, Lead Time widgets, query result charts, and burndown charts onto a canvas to build a team status board. Since query widgets pull directly from saved queries, a well-written query produces a well-populated dashboard automatically.
Permissions matter here for the exam. can create dashboards and manage widgets. Team members in the group can view dashboards but cannot add or rearrange widgets. Users with access level face additional restrictions on certain widget types.
For GitHub-native teams, GitHub Insights provides repository-level metrics: PR cycle time, review turnaround time, and contributor activity. Azure DevOps Dashboards offer organization-wide coverage; GitHub Insights focuses on a single repository's development flow.
Exam Key Takeaways
"Team-level sprint tracking, smallest unit of business value" -- Agile template User Story
"Regulatory audits, formal Change Request and Risk tracking" -- CMMI template
"View that supports WIP limits" -- Board (Kanban)
"Work item state counted in sprint velocity" -- Closed
"GitHub commit or PR body → Azure Boards work item auto-linked" -- AB#<id> mention (e.g., fixes AB#1234)
"Time from code commit to production" -- Lead Time for Changes
"Average time to recover from a production incident" -- MTTR (Mean Time to Restore)
"Percentage of deployments causing rollbacks or incidents" -- Change Failure Rate
"How often the team deploys to production" -- Deployment Frequency
"Permission required to create or manage dashboard widgets" -- Project Administrators
"Repository-level PR cycle time and contributor metrics" -- GitHub Insights
DORA speed pair = Deployment Frequency + Lead Time | DORA stability pair = MTTR + Change Failure Rate