How do you turn a massive, vague project—like ‘modernise the entire company website’—into small, trackable tasks that a team can actually complete without going crazy? The answer lies in work item management and agile planning, two core practices that allow teams to break work into bite-sized pieces, prioritise what matters most, and adjust on the fly. For the AZ-400 exam, you need to understand how Azure DevOps provides the tools to do this, because the exam tests your ability to configure and use these tools to manage a team’s workload effectively.
Jump to a section
A simple way to picture Implementing Work Item Management and Agile Planning
A bustling family kitchen, mid-renovation. The countertops are half-installed, the new refrigerator is unboxed in the dining room, and the electrician is waiting to wire a new outlet.
The home owner, Alex, is the product owner. Alex has a dream: a kitchen with an island, double ovens, and a walk-in pantry. But that dream needs to be broken down into smaller, manageable work items. Each work item is a single, trackable task: 'Order the island countertop', 'Install the double-oven electrical wiring', 'Paint the pantry walls'. Alex writes each of these on a sticky note and places them on the fridge (the product backlog).
Alex’s partner, Jamie, is the project manager. Jamie organises the sticky notes into sprints. This month, the sprint goal is 'Have a functional cooking space by the weekend'. Jamie picks the essential work items: 'Connect the gas line for the hob' and 'Install the sink'. They put these on a separate part of the fridge (the sprint backlog).
The family members (the development team) pick up sticky notes. Each morning, they meet for a quick stand-up in the doorway: 'I’m wiring the hob, no blockers.' 'I finished the sink, picking up the under-cabinet lighting task.' The sticky notes move from 'To Do' to 'In Progress' to 'Done'.
When the weekend arrives, the family can cook a meal. They review what worked (the stand-ups) and what didn’t (the paint fumes were too strong). Next sprint, they’ll ventilate better. This is work item management and agile planning in action: breaking a large dream into tiny, trackable tasks, organising them into short cycles, and constantly improving the process.
Work item management is the practice of tracking individual pieces of work—called work items—through their entire lifecycle. In Azure DevOps, these work items are digital records that represent tasks, bugs, user stories, or any other unit of work. Each work item has a unique ID, a title, a description, a status (like To Do, In Progress, Done), and fields for priority, effort, and assignment. Work item management is not just about making a to-do list; it’s about creating a single source of truth for the entire team, so everyone knows what needs to be done, who is doing it, and when it is due.
Agile planning is the methodology that guides when and how work items are executed. Instead of planning an entire project months in advance (a waterfall approach), agile teams plan in short, fixed-length cycles called sprints. A sprint typically lasts two to four weeks. At the start of each sprint, the team holds a sprint planning meeting where they decide which work items from a prioritised list—the backlog—they can complete during the sprint. This list of chosen items becomes the sprint backlog. The team then works through the sprint backlog, and at the end of the sprint, they hold a sprint review to show what they built and a retrospective to discuss what went well and what could be improved.
In Azure DevOps, the backlog is a central list of all work items that have not yet been scheduled into a sprint. The product backlog is managed by the product owner, who decides the priority of each item. The team can customise the backlog to show different types of work items, such as user stories (features from the user’s perspective), bugs (defects in the software), and tasks (technical implementation steps). Azure DevOps also provides boards, like the Kanban board, which visually displays the status of work items as they move across columns like New, Active, Resolved, and Closed.
Work item management also includes detailed tracking fields. For example, a team can assign a work item to a specific team member, set a priority of 1 (highest) to 4 (lowest), and estimate effort using story points or hours. The system automatically updates the burndown chart, which shows whether the team is on track to complete the sprint’s work by the end date. If the burndown line is above the ideal line, the team is behind schedule; if below, they are ahead. This real-time visibility is crucial for agile planning.
Before Azure DevOps, teams often used separate tools like spreadsheets, physical whiteboards, and email to manage work. This created silos—information lived in different places and quickly went out of date. Work item management in Azure DevOps replaces this with a centralised, queryable system. You can create queries to find all work items assigned to a specific person, all bugs with a priority of 1, or all items that are past their due date. These queries can be saved and shared.
The AZ-400 exam also covers how work items are linked to other artefacts. For instance, a bug work item can be linked to the specific commit (a change to the code) that fixed it, and to the build pipeline that produced the fix. This traceability is a key requirement for audits and releases. You can also link work items to each other—for example, a user story might have multiple child tasks that need to be completed to fulfill it. These parent-child relationships create a hierarchy that helps break down large features into actionable pieces.
Finally, agile planning in Azure DevOps supports multiple process templates, such as Scrum, Agile, and CMMI. Each template provides a default set of work item types and fields. The Scrum template, for example, includes Product Backlog Items and Impediments, while the Agile template includes User Stories and Tasks. The exam expects you to know how to choose the right template for a team’s methodology and how to customise a process to add new work item types or fields without breaking existing work items. Understanding these fundamentals is essential because the exam’s scenario questions will ask you to configure the system to handle specific planning needs, like setting up a new team’s backlog or creating a query to identify blockers.
Create or select an Azure DevOps project
Begin by creating a new project or opening an existing one in Azure DevOps. This project will contain all the work items, boards, backlogs, and settings. The project name and visibility (public or private) are chosen here. This step matters because work item management is scoped to a project; you cannot manage work items without a project to house them.
Choose and apply a process template
During project creation, you select a process template (Scrum, Agile, CMMI) or inherit from an existing process. This defines the default work item types, states, and fields. For agile planning, the Agile or Scrum template is most common. This step matters because the process template shapes how the team organises their work—for example, Scrum provides ‘Product Backlog Item’ while Agile provides ‘User Story’.
Set up area and iteration paths
Configure area paths to represent teams or feature areas (e.g., ‘MyProject\MobileTeam’) and iteration paths to represent sprints or releases (e.g., ‘MyProject\Sprint 1’). Each team member gets assigned to an area path, and sprints are mapped to iteration paths. This step matters because it ensures work items are automatically scoped to the correct team and time period, enabling accurate backlog and board views.
Add work items to the backlog
Create new work items (user stories, tasks, bugs) in the product backlog. Fill in fields like Title, Description, Priority, and Effort. Link parent-child relationships (e.g., tasks under a user story). This step matters because it populates the backlog with structured, actionable work that the team can later prioritise and schedule.
Prioritise and schedule work into a sprint
During sprint planning, the product owner and team review the backlog, select items for the next sprint, and assign them to the appropriate iteration path. The items then appear in the sprint backlog and on the sprint board. This step matters because it moves work from ‘planned’ to ‘committed’, and the team can now execute against a focused goal.
Update work items as work progresses
Team members update work items throughout the sprint: changing status from ‘To Do’ to ‘In Progress’ to ‘Done’, updating remaining effort, and adding comments or attachments. They also create impediment work items when blocked. This step matters because it keeps the board and charts accurate, providing real-time visibility into the team’s progress and blockers.
Review and refine with queries and charts
Create shared queries to filter work items (e.g., all active bugs in the current sprint) and add burndown charts to the project dashboard. Use these tools during daily stand-ups and sprint reviews. This step matters because it transforms raw work item data into actionable insights that drive decision-making and process improvement.
Imagine you are the Azure DevOps administrator for a software development company that builds a mobile banking app. The product owner, Maria, has a vision: implement a new ‘Bill Pay’ feature. Your job is to set up Azure DevOps so the development team can manage this feature using agile principles.
First, you create a new project in Azure DevOps and choose the Agile process template because the team uses user stories. You then add the development team as contributors. Maria creates a user story work item titled ‘As a user, I want to pay a bill from my account so I can manage my finances without mailing a cheque.’ She writes the acceptance criteria in the description field and sets the priority to 2 (high).
The team holds a sprint planning meeting for a two-week sprint. The team’s capacity is 40 story points based on their past velocity (the average amount of work they complete per sprint). They break the user story into smaller tasks: ‘Design the bill payment API endpoint’, ‘Create the payment confirmation screen’, ‘Write unit tests for payment processing’, and ‘Integrate with the external payment gateway.’ Each task is created as a child work item under the user story. The team estimates the tasks in hours: 8 hours, 6 hours, 4 hours, and 12 hours respectively. They ensure the total hours fit within the sprint’s capacity.
During the sprint, the daily stand-up meetings happen in the team room. The developer assigned to ‘Design the API endpoint’ moves his work item from ‘To Do’ to ‘In Progress’ on the board. Another developer hits a blocker: the external payment gateway requires a new security certificate that the IT department hasn’t provided. She creates an impediment work item and links it to her task. Maria, as the product owner, sees the impediment on the board and escalates it to the IT team.
To track progress, you create a shared query called ‘Current Sprint Blockers’ that finds all work items with a ‘Blocked’ state. You also configure a burndown chart widget for the team’s dashboard. Mid-sprint, the burndown chart shows the team is behind schedule—the actual remaining work line is above the ideal trend line. You investigate and find that the task for the payment confirmation screen took longer than estimated because the designer was out sick. The team reprioritises: they decide to finish the API and integration tasks first because they are on the critical path, and they move the remaining screen design work to the next sprint.
At the end of the sprint, the sprint review is held. The team demonstrates the working bill payment integration to stakeholders. They then hold a retrospective where they identify that external dependencies (the security certificate) caused a delay. They decide to add a new checklist field to tasks that require external dependencies, so they can flag them earlier. As the administrator, you customise the Agile process to add a new field called ‘External Dependency Required’ with a dropdown of Yes/No.
What does an IT professional actually do here? They:
Configure project settings and process templates to match the team’s workflow.
Create, assign, and update work items based on sprint planning.
Monitor dashboards, queries, and burndown charts to track progress and identify issues.
Customise work item types and fields when the team identifies a gap in tracking.
Link work items to code commits, builds, and releases to ensure full traceability for audits.
This real-world scenario shows that work item management and agile planning are not just theoretical concepts—they are daily, hands-on activities that directly impact a team’s ability to deliver software predictably. The AZ-400 exam expects you to be able to perform these tasks in Azure DevOps, not just describe them.
The AZ-400 exam tests ‘Implement work item management and agile planning’ mostly through scenario-based multiple-choice questions and case studies. You will not be asked to click through the portal directly, but you will need to know which tool or configuration to use in a given situation. The exam loves to test your ability to distinguish between similar concepts and to apply the correct process for a specific agile methodology.
Key exam topics include:
Choosing the correct process template (Scrum, Agile, or CMMI) based on a team’s preferred methodology. The trap: they might describe a team using Scrum but mention they use ‘issues’ instead of ‘product backlog items’ to confuse you. Learn the default work item types for each template.
Configuring teams and team areas so work items are properly scoped. The exam may present a scenario where a large project has multiple teams (e.g., payments team, reporting team) and ask how to set up area paths to separate their backlogs. The correct answer is to create child area paths under the project and assign each team to their own area path.
Creating and customising work item types. Exam questions often describe a need to track a new type of work—like a ‘Security Review’—and ask how to add it. The answer is to customise the inherited process, not the XML process (unless specified). They will test whether you know the difference between an inherited process and a custom XML-based process.
Querying and charts. Expect a question like: ‘The project manager wants a view of all active bugs with priority 1 assigned to the current sprint. Which tool should you use?’ Answer: a shared query in Azure Boards. They might offer ‘Dashboard charts’ as a distractor, but charts are built from queries; the query is the fundamental building block.
Setting up notifications. For example, you might be asked how to alert a team member when a high-priority work item is assigned to them. Correct answer: create a notification subscription for ‘Work item created’ with a filter on the assigned-to field.
Common traps:
Confusing the product backlog with the sprint backlog. The product backlog is the full, prioritised list of all future work. The sprint backlog is the subset selected for the current sprint. If a question says ‘move items from the backlog to the board for the upcoming sprint’, they mean the sprint backlog.
Thinking that Kanban boards replace sprints. Kanban is a continuous flow method and can be used with or without sprints. The exam will test whether you know that sprints are time-boxed cycles, while Kanban limits work-in-progress (WIP) limits without fixed durations.
Assuming all users can edit work item types. Only users with ‘Project Administrator’ or ‘Project Collection Administrator’ permissions can customise processes.
Key definitions to memorise:
Work item: a digital record representing a unit of work (task, bug, user story).
Backlog: a prioritised list of work items not yet scheduled into a sprint.
Sprint: a fixed-length timebox (usually 2-4 weeks) during which a set of work items is completed.
Area path: a way to group work items by team or feature area.
Iteration path: a way to group work items by sprint or release.
Process template: a predefined set of work item types, states, and fields (Scrum, Agile, CMMI).
The exam frequently presents a scenario where a team is having trouble with visibility of blocked items. The correct answer will involve creating a shared query to filter for items in the ‘Blocked’ state, or adding a custom ‘Blocked reason’ field for better tracking. Another common scenario is a team that wants to see progress over time—the answer is to configure the burndown chart widget on the dashboard.
Remember: the AZ-400 is about Azure DevOps, so always choose the Azure DevOps native tool over third-party integrations unless the question explicitly asks about integrating with something like GitHub Issues. And always prefer the default, out-of-the-box solution unless the scenario requires a customisation.
A work item is a single digital record in Azure DevOps that tracks a unit of work, such as a task, bug, or user story, and includes fields for status, priority, assignment, and effort.
The product backlog is the full, prioritised list of all future work; the sprint backlog is the subset of that list committed to for the current sprint.
Sprints are fixed-length timeboxes (typically 2-4 weeks) during which the team completes a set of work items from their sprint backlog.
Area paths organise work by team or feature area; iteration paths organise work by time period (sprint or release); they are not interchangeable.
Customising work item types (adding fields, changing states) is done through inherited processes, not by directly editing XML files, to maintain upgradability.
Shared queries and dashboard charts (like burndown charts) are the primary ways to visualise progress and identify blockers across work items.
Linking work items to code commits, builds, and releases provides end-to-end traceability, which is crucial for audits and release management.
Deleted work items are recoverable from the Recycle Bin for 30 days before permanent deletion.
These come up on the exam all the time. Here's how to tell them apart.
Product Backlog
Contains all future work items not yet scheduled into a sprint.
Managed by the product owner who prioritises the items.
Does not have a fixed time constraint; items can sit indefinitely.
Does not have a fixed time constraint; items can sit indefinitely.
Sprint Backlog
Contains only the work items committed for the current sprint.
Managed by the development team who pull items from the product backlog.
Has a fixed time constraint (the sprint's duration, typically 2-4 weeks).
Has a fixed time constraint (the sprint's duration, typically 2-4 weeks).
Area Path
Used to group work items by team, feature, or functional area.
Hierarchical structure like 'Project\MobileApp'.
Does not change over time; area paths are static.
Does not change over time; area paths are static.
Iteration Path
Used to group work items by sprint or release time period.
Hierarchical structure like 'Project\Sprint 1'.
Changes each sprint; new iteration paths are created for each cycle.
Changes each sprint; new iteration paths are created for each cycle.
Agile Process Template
Default work item types: User Story, Task, Bug.
Uses a three-state workflow: To Do, In Progress, Done.
Commonly used by teams that want simpler state transitions.
Commonly used by teams that want simpler state transitions.
Scrum Process Template
Default work item types: Product Backlog Item, Task, Bug, Impediment.
Uses a more detailed state workflow: New, Approved, Committed, Done.
Designed for teams that strictly follow Scrum methodology and need more states.
Designed for teams that strictly follow Scrum methodology and need more states.
Shared Query
A saved filter that returns a list of work items matching criteria.
Can be exported to Excel or used in other tools.
Does not visualise data until results are viewed.
Does not visualise data until results are viewed.
Dashboard Chart Widget
A visual representation of query data (e.g., burndown chart, pie chart).
Displays on the project dashboard for at-a-glance status.
Built on top of one or more shared queries; cannot exist without data.
Built on top of one or more shared queries; cannot exist without data.
Work Item Type: Bug
Represents a defect or issue in the software that does not meet requirements.
Typically has a priority like 'Critical' or 'High'.
Often linked to the specific test case that failed.
Often linked to the specific test case that failed.
Work Item Type: Task
Represents a discrete unit of work that does not represent a defect.
Has an effort estimate (hours or story points) and an assigned person.
Typically linked to a parent user story or product backlog item.
Typically linked to a parent user story or product backlog item.
Mistake
Work item management is just digital to-do lists that don't change anything about how a team actually works.
Correct
Work item management is a fundamental change in how teams track, prioritise, and visualise work. It provides traceability, accountability, and data like burndown charts that drive team behaviour and project decisions.
People from non-IT backgrounds see a to-do list app and think it's the same thing. They don't realise that Azure DevOps work items link to code, builds, and tests, creating an auditable trail that is essential for regulatory compliance and release management.
Mistake
Agile planning means you don't have to plan anything—you just start coding and figure it out as you go.
Correct
Agile planning requires more frequent, disciplined planning (every sprint) rather than one big upfront plan. It includes sprint planning, daily stand-ups, reviews, and retrospectives. It's not unstructured; it's structured around short cycles.
The word 'agile' is often misunderstood as 'go with the flow.' Beginners hear it and think it means no planning at all, when in fact the Scrum framework, for example, has very clear events and artefacts.
Mistake
Area paths and iteration paths are the same thing and can be used interchangeably.
Correct
Area paths are used to group work items by functional area or team (e.g., 'Mobile App' vs. 'Backend'), while iteration paths are used to group work items by sprint or time period (e.g., 'Sprint 1'). They serve completely different purposes.
Both are hierarchical paths in Azure DevOps and appear in similar configuration screens. Beginners assume they must be redundant, but the exam explicitly tests the difference.
Mistake
You can only use one process template per Azure DevOps project, and you cannot change it after the project is created.
Correct
You can change the process template for a project, but only from one inherited process to another inherited process (e.g., from Agile to Scrum). However, you cannot switch from an inherited process to a custom XML process or vice versa without losing work item data.
Microsoft documentation warns that certain changes are irreversible, which scares people into thinking no changes are possible. The exam tests the nuance of what can be changed and what cannot.
Mistake
If you delete a work item, it is permanently gone and cannot be recovered.
Correct
Deleted work items are moved to the Recycle Bin within an Azure DevOps project and can be restored for up to 30 days. After 30 days, they are permanently deleted.
Many users coming from other tools that permanently delete items assume Azure DevOps works the same way. The Recycle Bin feature is not obvious in the UI, so beginners don't know about it.
Mistake
Burndown charts are only useful for Scrum teams, not Kanban teams.
Correct
Burndown charts are also useful for Kanban teams if the team uses sprint cycles. For continuous flow Kanban without sprints, a cumulative flow diagram (CFD) is more appropriate, but burndowns still work if the team chooses to timebox their work.
The exam often presents a Kanban scenario and asks about burndown charts. Beginners incorrectly think burndowns are exclusive to Scrum because they are most commonly used in that context.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
In Azure DevOps, a work item is a digital record for tracking a specific piece of work (like a task or bug), while a ticket is a more generic term used in other systems like JIRA or Helpdesk tools. In the context of AZ-400, you should use the term work item for Azure DevOps.
Yes, you can use the basic or Kanban process template, which supports continuous flow without fixed sprints. The board columns (To Do, Doing, Done) allow you to manage work items without timeboxed sprints, though you lose burndown charts tied to sprints.
When committing code to the Git repository in Azure Repos, include the work item ID in the commit message (e.g., 'Fixed bug #123'). Azure DevOps automatically links the commit to that work item. You can also manually link from the work item form by clicking 'Add link' and selecting 'Commit'.
Existing work items are automatically mapped to the new work item types based on the mapping rules defined in the process template. For example, a 'User Story' in the Agile template maps to a 'Product Backlog Item' in the Scrum template. Some fields may be lost if they do not exist in the new template.
Go to the project's Boards menu, select 'Work Items', then click the 'Recycle Bin' option at the top. Find the deleted work item, click the context menu (three dots), and select 'Restore'. You have 30 days from deletion to restore it.
Yes, you can create multiple teams within the same project. Each team gets its own backlog and board views, scoped by their assigned area paths. This allows several teams to work on the same project without seeing each other's work items unless explicitly shared.
You've finished Implementing Work Item Management and Agile Planning. Continue through the AZ-400 study guide to build a complete picture of the exam.
Done with this chapter?