Microsoft AZ-400: Agile Planning and Work Management — Study Guide

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Part of the Microsoft DevOps Engineer Expert AZ-400 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Agile planning and work management in Azure DevOps center on a clear data model, disciplined flow and iteration practices, and visibility across teams. Azure Boards provides a robust hierarchy of work item types and flexible configurations per team, while GitHub Projects offers modern, automation-driven planning tightly integrated with Issues and Pull Requests. Effective adoption depends on rigorous definitions (Definition of Done, acceptance criteria), consistent estimation (story points and relative sizing), and actionable insights (queries, delivery plans, and metrics including DORA). The following sections detail how to design, implement, and operate these practices at scale.

Azure Boards Data Model, Process Templates, and Team Configuration

Work item types and hierarchy form the backbone of planning. In the default Agile process, the portfolio hierarchy is Epic > Feature > User Story, with Task and Bug as execution-level items. Child links capture decomposition (User Story → Task) and Bugs can be managed on the same backlog level as User Stories or triaged independently based on team policy. Link types are essential:

Parent/Child: captures the decomposition hierarchy and drives rollup of progress and effort.
Predecessor/Successor: expresses scheduling and dependency relationships across work items; these surface in Delivery Plans as dependency lines.
Related/Duplicate/Blocked by: models non-hierarchical relations and impediments.
Artifact links: connects work items to code (commits, branches, PRs), builds, and releases, enabling end-to-end traceability.

Azure DevOps process templates define states, fields, and WIT naming:

Agile: Requirement-level item is User Story; fast-moving teams often choose this.
Scrum: Requirement-level item is Product Backlog Item (PBI); sprints and Scrum artifacts are first-class and Bugs can be configured to behave like PBIs.
CMMI: Requirement-level item is Requirement and it includes WITs for Change Request, Risk, and Review—choose this when you must track risks and formal reviews.
Custom (Inherited) processes: In Azure DevOps Services, extend a system process via Inheritance to add custom WITs, states, rules, and fields while preserving service compatibility. Use categories to place a custom WIT on the correct backlog level. Avoid over-customization that fractures reporting; standardize fields such as Story Points and Remaining Work.

Teams are lightweight partitions configured via:

Area paths: scope ownership and backlog filtering; teams select one or more area paths (and optionally include child areas) to define “their” work.
Iteration paths: represent release cadence and sprints; a team picks default and current iterations for planning.
Team backlogs and boards: each team chooses which portfolio levels (Epic, Feature) to show, card styles, and column mappings per team without impacting other teams.
Team dashboards: curate shared visibility using widgets for Velocity, Burndown/Burnup, Cumulative Flow Diagram (CFD), Lead/Cycle Time charts, and custom Analytics views.

Flow-Based Delivery with Kanban and Governance

Kanban in Azure Boards models continuous flow from commitment to completion. Configure columns to map to workflow states and optionally split critical states into Doing/Done subcolumns to improve throughput accounting and reduce hidden queues. Set explicit WIP (Work In Progress) limits per column and per swimlane; enforce them operationally—breaching a limit triggers an improvement conversation rather than a silent backlog growth. Use dedicated swimlanes (for example, Expedite) to visually separate high-priority items and set tighter WIP for that lane.

Definition of Done (DoD) anchors quality and predictability; encode it as board policies, required fields or checklists on specific transitions, and acceptance test linkage. For example, require a Tested By link to a passing Test Case before moving to Done, and capture deployment verification steps when moving to Released.

Use analytics to manage flow health:

Cumulative Flow Diagram validates WIP equilibrium and detects bottlenecks when bands expand.
Lead Time measures the elapsed time from creation to completion; Cycle Time focuses on the time from entering Active to completion. The Cycle Time chart widget reports the elapsed time after a work item transitions to Active, aligning with bottleneck analysis.
Throughput charts track items completed per time period; monitor stability and trend.

Sprint planning converts priority into a timeboxed commitment. The sprint backlog lists the PBIs or User Stories pulled into the iteration, decomposed into Tasks with Remaining Work in hours. Use Sprint Capacity to model people availability:

Per-person capacity in hours/day by activity (Development, Testing, UX).
Individual and team days off to reflect holidays and leave.
Activity-level load balancing by associating tasks to activities and reviewing capacity vs. planned work.

Velocity summarizes delivered story points per sprint. Use the Velocity chart to establish a stable band; avoid “point inflation.” On product backlogs, enable Forecasting to project how many upcoming iterations will be required to burn down the backlog at the team’s historical average velocity (based on several recent sprints) and iteration length. Keep the forecasting honest by excluding partially completed work and maintaining strict DoD.

Backlog refinement enforces clarity and relative sizing:

Acceptance criteria: record clear, testable statements in the work item’s Acceptance Criteria field; prefer Given-When-Then to reduce ambiguity and accelerate test design.
Story points: estimate relative complexity and uncertainty at the requirement level; do not convert points to hours—tasks carry Remaining Work.
Relative estimation (Planning Poker): use a shared baseline and a sequence (Fibonacci or modified Fibonacci) to converge quickly. Teams can use Marketplace extensions to run Planning Poker within Azure Boards, writing estimates to Story Points/Effort fields for consistent reporting.

Bugs should be triaged and either treated like requirements (estimated with points and planned on the backlog) or handled as tasks within the sprint; choose one policy per team to keep velocity consistent.

Cross-Team Planning, Queries, Reporting, GitHub Projects, and DevOps Metrics

Large programs require visibility across teams and repositories:

Delivery Plans: create multi-team timelines filtered by area/iteration paths. Visualize work by iteration with dependency lines (from Predecessor/Successor links) and markers for milestones (release dates, external commitments). Show rollup progress on Features and Epics and expose custom fields (e.g., Risk) for governance reviews.
Queries and reporting: build Flat list queries to answer “which items match these filters,” Tree of work items to navigate hierarchy with rollups, and Direct links queries to analyze one link hop (e.g., Feature → Stories or Bug → commits). Save and share queries, add charts (pie, bar, trend), and pin them to dashboards. For analytics-grade reporting, use the Azure DevOps Analytics service and OData with Power BI to produce portfolio burndown, dependency risk heatmaps, and DORA visualizations. Built-in reports include Velocity, Burndown/Burnup, CFD, Lead Time, Cycle Time, and Sprint Capacity usage.

GitHub Projects integrates planning with Issues and PRs:

Project boards: create Kanban or table views at the organization or repository scope, define custom fields (Status, Iteration, Priority), and filter by team.
Automation rules: configure built-in workflows to set Status when an Issue or PR is opened, merged, or closed; auto-archive done items; assign or label based on field changes; and move items across views. Combine with GitHub Actions for advanced automations.
Issues and PR integration: Issues and PRs are first-class items in Projects. Use keywords in PR descriptions (Fixes #123) to link and auto-close Issues. Status and reviewers are visible on the board, enabling code-to-plan traceability.

DevOps metrics must connect code, deployment, and outcomes:

DORA metrics:
- Deployment frequency: count production deployments per day/week; source from pipeline release events.
- Lead time for changes: measure from code commit (or PR merge) to production deployment; ensure pipelines emit deployment timestamps and correlate them to commits.
- Change failure rate: ratio of production deployments that result in a customer-impacting incident or rollback; integrate with incident management tags and pipeline outcomes.
- Mean time to restore (MTTR): elapsed time from incident start to service restoration; drive from monitoring alerts and incident closure times. Correlate DORA with Board analytics (Lead/Cycle time) to detect whether planning or delivery is the constraint. Use dashboards to surface both sets of metrics to the same audience for continuous improvement.

Practical Problem Scenario

Microsoft’s Advertising division is aligning eight cross-functional teams delivering a shared campaign management platform. The codebase is in GitHub; the organization needs reliable quarterly commitments, clear dependency visibility, and actionable flow and DORA metrics without adding tooling sprawl.

Choose the Azure DevOps Agile process and configure teams

Why: Agile provides the Epic > Feature > User Story hierarchy that balances simplicity with portfolio rollups. Create eight teams, each with their own area path and current/future iteration paths, enabling autonomy in boards and dashboards while preserving organization-wide reporting.

Define Kanban governance and board configuration

Why: Continuous flow between sprints reduces wait time. Configure columns mapped to states with Doing/Done splits for In Progress and Code Review. Set WIP limits per column and add an Expedite swimlane with a lower WIP. Add board policies stating the Definition of Done (unit tests pass, PR approved, deployment verification checklist completed) to gate movement to Done.

Implement backlog refinement and estimation discipline

Why: Predictable commitments require consistent sizing and clarity. Capture acceptance criteria using Given-When-Then on User Stories. Standardize Story Points via Planning Poker (Fibonacci 1–13) using an Azure Boards extension, and keep task estimates in Remaining Work hours to support Sprint Capacity.

Plan sprints with capacity and velocity-based forecasting

Why: Capacity planning reduces overcommitment. Enter individual capacities by activity and days off. Use the Velocity chart from the last six sprints to set a realistic sprint goal. Enable backlog Forecasting to project how many sprints are needed to reach the quarterly Epic objectives, aligning stakeholder expectations.

Establish Delivery Plans for cross-team visibility

Why: Dependencies and milestones must be visible on a single timeline. Create a Delivery Plan including all eight teams and portfolio levels. Add milestone markers for quarterly release dates and market events. Use Predecessor/Successor links to show dependency lines and surface risk where items span iterations.

Integrate GitHub Projects for repository-centric execution views

Why: Developers live in GitHub; Projects keep execution context close to code. Create an org-level GitHub Project with board and table views. Add automation rules to set Status to In Progress on PR open, to Done on PR merge, and auto-archive closed Issues. Use “Fixes #<id>” in PRs to close linked Issues and reflect status back in the board.

Link code and work for traceability

Why: End-to-end traceability enables accurate reporting and audits. Enforce referencing the Azure Boards work item ID in commit messages and PR descriptions; use artifact links on work items so Delivery Plans and analytics can roll up progress from code activity.

Instrument flow and DORA metrics on dashboards

Why: Shared, automated metrics drive improvement. On team dashboards, pin CFD, Lead Time, and Cycle Time charts to manage flow. On a program dashboard, surface Velocity, Delivery Plan summary, and DORA metrics: compute deployment frequency and lead time using pipeline deployment events from production stages; derive change failure rate and MTTR by tagging incidents and correlating to deployments. This unified view highlights whether constraints are in planning (board lead/cycle time) or delivery (DORA).

This approach balances team autonomy (team-specific boards, capacity, and dashboards) with program governance (Delivery Plans, dependencies, and milestones). Azure Boards provides hierarchical planning and analytics, GitHub Projects streamlines day-to-day developer tracking with automation tied to Issues and PRs, and DORA metrics bridge planning with operational outcomes for credible, data-driven commitments.

← Package Management and Artifact Management · All domains

Practice these questions → · Timed practice on ExamRoll.io →