Module 2: Azure Boards — Agile Work Management

Introduction to Azure Boards

Azure Boards is the work tracking and agile planning service within Azure DevOps. It provides a rich set of capabilities for teams practicing Scrum, Kanban, or any hybrid methodology — backlogs, sprint planning, Kanban boards, queries, dashboards, and deep integration with every other Azure DevOps service.

Think of Azure Boards as a digital war room — the backlog is your strategy whiteboard where you capture every piece of work; the Kanban board is your operations display showing what's in progress right now; sprints are your battle plans with fixed timelines and committed scope; and queries are your intelligence reports that surface exactly the information you need. Together, they give every team member — from developers to executives — a shared, real-time view of what's happening.

Azure Boards vs Standalone Tools

For Agile and Scrum fundamentals that underpin everything in Azure Boards, see Part 3: Agile Methodologies and Part 4: Scrum Deep Dive in the main series.

Process Templates

When you create an Azure DevOps project, you choose a process template that determines your work item types, workflow states, and default fields. Think of this like choosing between different project management methodologies — the template encodes the methodology into the tool itself.

The Four Built-in Templates

Workflow States Visualized

The following diagram shows the Agile process workflow — the most commonly used template. Notice how items can move backwards (e.g., from Resolved back to Active when testing reveals issues):

                                stateDiagram-v2
                                    [*] --> New
                                    New --> Active : Work begins
                                    Active --> Resolved : Dev complete
                                    Resolved --> Active : Testing fails
                                    Resolved --> Closed : Accepted
                                    Active --> Closed : Cancelled
                                    Closed --> [*]
                            

Choosing the Right Template

• Choose Agile if your team uses sprints loosely, mixes Scrum and Kanban, or you want "User Story" terminology that non-technical stakeholders understand
• Choose Scrum if your team practices strict Scrum with Product Backlog Items, sprint commitments, and Impediment tracking
• Choose CMMI if you need formal change management, risk tracking, or compliance audit trails (common in healthcare, defense, and banking)
• Choose Basic for small teams (under 5 people) who want minimal ceremony or when managing non-software work like marketing campaigns

Work Item Types & Hierarchy

Work items are the atomic units of tracking in Azure Boards. Every piece of work — from a high-level business initiative to a single coding task — lives as a work item with a type, state, and rich set of fields.

The Work Item Hierarchy

Azure Boards uses a parent-child hierarchy to organize work from strategic goals down to individual tasks. Think of it like a Russian nesting doll — each level contains the next:

                                flowchart TD
                                    E[Epic: Launch Mobile App] --> F1[Feature: User Authentication]
                                    E --> F2[Feature: Shopping Cart]
                                    F1 --> US1[User Story: Social Login]
                                    F1 --> US2[User Story: Password Reset]
                                    F2 --> US3[User Story: Add to Cart]
                                    US1 --> T1[Task: Implement Google OAuth]
                                    US1 --> T2[Task: Write Unit Tests]
                                    US3 --> T3[Task: Design Cart UI]
                                    US3 --> B1[Bug: Cart total incorrect]
                            

• Epic — A large body of work spanning multiple sprints or releases. Example: "Launch mobile e-commerce app by Q3"
• Feature — A shippable increment of functionality. Example: "User authentication module with social login"
• User Story / PBI — A single piece of user-facing value completable in one sprint. Example: "As a user, I want to log in with my Google account so I don't need a new password"
• Task — A technical activity required to complete a story (4–16 hours). Example: "Implement Google OAuth callback handler"
• Bug — A defect that needs fixing. Can live at Story or Task level depending on severity

Key Work Item Fields

Every work item has fields that capture essential metadata. The most important ones:

Creating Work Items Programmatically

While the web UI is great for individual items, you often need to create work items in bulk — during migration, from automated processes, or as part of project setup scripts. The Azure CLI makes this straightforward:

# Create an Epic — the top-level strategic container
az boards work-item create \
    --org https://dev.azure.com/contoso \
    --project "WebApp" \
    --type "Epic" \
    --title "Launch Mobile E-Commerce App" \
    --description "Deliver a cross-platform mobile shopping experience by Q3 2026" \
    --assigned-to "jane@contoso.com" \
    --fields "Priority=1" "System.Tags=mobile;strategic"

# Create a Feature linked to the Epic (parent ID 1001)
az boards work-item create \
    --org https://dev.azure.com/contoso \
    --project "WebApp" \
    --type "Feature" \
    --title "User Authentication Module" \
    --description "Support email/password and social login (Google, Microsoft, Apple)" \
    --assigned-to "bob@contoso.com" \
    --fields "Priority=2" "Microsoft.VSTS.Scheduling.StoryPoints=13"

# Create a User Story under the Feature
az boards work-item create \
    --org https://dev.azure.com/contoso \
    --project "WebApp" \
    --type "User Story" \
    --title "As a user, I want to log in with Google so I don't need a new password" \
    --fields "Microsoft.VSTS.Scheduling.StoryPoints=5" \
        "Microsoft.VSTS.Common.AcceptanceCriteria=Given valid Google credentials, when I click 'Sign in with Google', then I am authenticated and redirected to the home page" \
        "System.IterationPath=WebApp\\Sprint 14"

Backlogs & Prioritization

The backlog is the single source of truth for all planned work. It's where product owners capture, prioritize, and refine work items before committing them to sprints. Azure Boards provides three levels of backlog:

• Portfolio Backlog — Epics and Features. The strategic view for leadership and product managers. Answers: "What big initiatives are we pursuing?"
• Product Backlog — User Stories / PBIs. The tactical view for product owners and scrum masters. Answers: "What's next for the team to build?"
• Sprint Backlog — Stories + Tasks assigned to the current sprint. The execution view for developers. Answers: "What am I working on today?"

Prioritization

In Azure Boards, backlog priority is determined by stack rank — the order of items in the list. The item at position 1 is the highest priority. You can reorder by dragging items up or down, and this order persists across all views (backlog, board, sprint planning).

Backlog Refinement Workflow

Effective teams refine their backlog regularly — typically in mid-sprint sessions. Here's a proven refinement pattern:

1. Triage new items — Review items in "New" state, assign area paths and rough priorities
2. Split large stories — Any story over 8 points should be decomposed into smaller, independently valuable stories
3. Add acceptance criteria — Every story entering a sprint must have clear, testable acceptance criteria
4. Estimate — Team assigns story points using planning poker or t-shirt sizing
5. Reorder — Product owner reorders based on business value, dependencies, and risk

The following CLI commands help automate backlog queries — useful for generating refinement meeting agendas or tracking backlog health:

# Query all unestimated stories in the backlog (no story points assigned)
# This helps identify items that need refinement before sprint planning
az boards query \
    --org https://dev.azure.com/contoso \
    --project "WebApp" \
    --wiql "SELECT [System.Id], [System.Title], [System.State] \
            FROM WorkItems \
            WHERE [System.WorkItemType] = 'User Story' \
            AND [System.State] = 'New' \
            AND [Microsoft.VSTS.Scheduling.StoryPoints] = '' \
            ORDER BY [Microsoft.VSTS.Common.StackRank]"

# Find stories that are too large (over 8 points) — candidates for splitting
az boards query \
    --org https://dev.azure.com/contoso \
    --project "WebApp" \
    --wiql "SELECT [System.Id], [System.Title], [Microsoft.VSTS.Scheduling.StoryPoints] \
            FROM WorkItems \
            WHERE [System.WorkItemType] = 'User Story' \
            AND [Microsoft.VSTS.Scheduling.StoryPoints] > 8 \
            AND [System.State] <> 'Closed'"

Sprint Planning & Execution

Sprints (called "Iterations" in Azure DevOps) are fixed-length time boxes where the team commits to delivering a set of work items. Azure Boards provides comprehensive sprint management including planning, capacity tracking, and burndown monitoring.

Configuring Iterations

Before you can plan sprints, you need to define iteration paths. Each iteration has a name, start date, and end date. Teams typically use 2-week sprints, though 1-week and 3-week sprints are also common:

Setup path: Project Settings → Boards → Team Configuration → Iterations → + New child

Sprint Planning Workflow

Sprint planning in Azure Boards follows this sequence:

1. Set team capacity — Define hours per day for each team member, mark days off, and assign activity types (Development, Testing, Design)
2. Review velocity — Check how many story points the team completed in previous sprints (Boards shows a velocity chart automatically)
3. Drag stories from backlog to sprint — Move top-priority items from the product backlog into the sprint until you reach capacity
4. Decompose into tasks — Break each story into tasks with hour estimates. The capacity bar shows remaining hours vs capacity
5. Commit — The team agrees this scope is achievable. The sprint begins.

Capacity Planning

The capacity view shows a real-time bar chart: planned hours (from task estimates) vs. available hours (from capacity settings). When the bar turns red, you've over-committed — remove stories or negotiate scope.

Burndown & Burnup Charts

Azure Boards automatically generates sprint charts:

• Burndown Chart — Shows remaining work (hours or story points) decreasing over time. The ideal line shows expected progress; deviations indicate the sprint is at risk
• Burnup Chart — Shows completed work accumulating over time plus the total scope line. Scope creep shows as the total line rising
• Velocity Chart — Tracks story points completed per sprint over time. Helps predict how much the team can take on in future sprints

Kanban Boards

The Kanban board is Azure Boards' visual workflow tool. It shows every work item as a card positioned in a column that represents its current state. Unlike sprint backlogs (which show a time-boxed commitment), the Kanban board shows the continuous flow of all active work.

Board Columns

Columns map directly to your process workflow states. For the Agile template, the default columns are:

                                flowchart LR
                                    A[New] --> B[Active]
                                    B --> C[Resolved]
                                    C --> D[Closed]
                            

You can customize columns extensively — add, rename, reorder, or split them. A typical customized board might look like: New → Refined → In Development → In Code Review → In Testing → Done.

WIP Limits

Work-In-Progress (WIP) limits are the single most important Kanban practice. They cap how many items can be in a column simultaneously, preventing the team from starting too much work at once.

Swimlanes

Swimlanes add horizontal rows to your board, creating visual groupings. Common uses:

• Priority lanes — "Expedite" (top, for urgent items), "Standard" (middle), "Low Priority" (bottom)
• Type lanes — Separate rows for Stories, Bugs, and Technical Debt
• Team member lanes — Each developer gets a row (useful for pair programming visibility)

Split Columns & Definition of Done

Azure Boards lets you split columns into "Doing" and "Done" sub-columns. This creates a visual handoff point — when a developer finishes coding, they move the card from "In Development → Doing" to "In Development → Done," signaling it's ready for the next stage (code review).

You can also attach a Definition of Done checklist to any column. When someone tries to move a card out of that column, a checklist pops up reminding them what must be true before advancing (e.g., "Unit tests passing, Code reviewed, Documentation updated").

Cumulative Flow Diagram (CFD)

The CFD is a powerful analytics tool that shows the number of items in each state over time. It reveals bottlenecks at a glance:

• Widening band = items accumulating in that state (bottleneck)
• Narrowing band = state is processing faster than incoming (healthy)
• Parallel bands = steady flow (optimal)
• Total height increasing = scope growth outpacing delivery

Queries & Reporting

Queries let you find, filter, and organize work items using powerful criteria. They're the backbone of reporting in Azure Boards — every dashboard widget, email notification, and bulk operation starts with a query.

Query Types

• Flat query — Returns a simple list of matching items. Most common type. Use for: "Show me all active bugs assigned to me"
• Tree query — Returns items with their parent-child hierarchy preserved. Use for: "Show all features with their child stories"
• Direct links query — Returns items connected by any link type (related, duplicate, tested by). Use for: "Show all bugs linked to a specific feature"

Powerful Query Operators

Azure Boards supports special macros that make queries dynamic — they resolve at runtime so queries never go stale:

WIQL — Work Item Query Language

Under the hood, all queries are expressed in WIQL (Work Item Query Language) — a SQL-like syntax. The UI query editor generates WIQL, but you can also write it directly for complex queries or automation. Here are practical examples:

# WIQL query: Find all high-priority bugs in the current sprint
# that are unassigned — these need immediate attention in standup
az boards query \
    --org https://dev.azure.com/contoso \
    --project "WebApp" \
    --wiql "SELECT [System.Id], [System.Title], [System.State], \
                   [Microsoft.VSTS.Common.Priority] \
            FROM WorkItems \
            WHERE [System.WorkItemType] = 'Bug' \
            AND [Microsoft.VSTS.Common.Priority] <= 2 \
            AND [System.IterationPath] = @CurrentIteration \
            AND [System.AssignedTo] = '' \
            ORDER BY [Microsoft.VSTS.Common.Priority] ASC"

# WIQL query: Items changed in the last 24 hours (activity report)
# Useful for daily standup preparation or manager status updates
az boards query \
    --org https://dev.azure.com/contoso \
    --project "WebApp" \
    --wiql "SELECT [System.Id], [System.Title], [System.State], \
                   [System.ChangedBy], [System.ChangedDate] \
            FROM WorkItems \
            WHERE [System.TeamProject] = 'WebApp' \
            AND [System.ChangedDate] >= @Today - 1 \
            ORDER BY [System.ChangedDate] DESC"

# WIQL query: Stale items — active stories with no updates in 7+ days
# These may be blocked or forgotten — flag for sprint retrospective
az boards query \
    --org https://dev.azure.com/contoso \
    --project "WebApp" \
    --wiql "SELECT [System.Id], [System.Title], [System.AssignedTo], \
                   [System.ChangedDate] \
            FROM WorkItems \
            WHERE [System.WorkItemType] = 'User Story' \
            AND [System.State] = 'Active' \
            AND [System.ChangedDate] <= @Today - 7 \
            ORDER BY [System.ChangedDate] ASC"

Shared vs Personal Queries

Personal queries (My Queries) are visible only to you — use these for your daily workflow. Shared queries (Shared Queries) are visible to the team and can be referenced by dashboard widgets, email alerts, and API integrations. Organize shared queries into folders by purpose: "Sprint Reports," "Bug Triage," "Stakeholder Views."

Dashboards & Analytics

Dashboards provide real-time visibility into project health. Each team can have multiple dashboards tailored to different audiences — a developer dashboard (PRs, builds, my tasks), a scrum master dashboard (burndown, blockers, WIP), and a stakeholder dashboard (feature progress, release timeline).

Key Widgets

Analytics Views for Power BI

For advanced reporting beyond built-in widgets, Azure Boards exposes an OData analytics feed that connects directly to Power BI. This enables custom reports like:

• Bug resolution time by severity and team over the last 6 months
• Feature delivery predictability (planned vs actual completion dates)
• Cross-project portfolio tracking for program managers
• Team comparison dashboards for engineering leadership

Dashboard Design Best Practices

• One dashboard per audience — Don't mix developer metrics with executive summaries
• Limit to 6–8 widgets — More creates information overload; prioritize signal over noise
• Use trend widgets over point-in-time snapshots — trends reveal whether things are improving or deteriorating
• Include an "action trigger" — At least one widget should drive immediate action (e.g., "Unassigned High-Priority Bugs")
• Review monthly — Remove widgets nobody looks at; add widgets that answer recurring questions from stakeholders

Team Collaboration Features

Azure Boards isn't just a tracking tool — it's a collaboration platform with features designed to keep teams aligned without drowning in notifications.

@Mentions & Discussions

Every work item has a Discussion tab where team members can have threaded conversations. Use @mention to notify specific people — they'll get an email and in-app notification. Discussions support rich text, code snippets, images, and emoji reactions.

Following Work Items

Click the "eye" icon on any work item to follow it. You'll receive notifications when the state changes, someone comments, or fields are updated — without being assigned to it. This is ideal for product owners who want to track key stories without cluttering assignee fields.

Notification Configuration

Azure DevOps provides granular notification control at three levels:

• Personal — Your own subscriptions (e.g., "Notify me when any item assigned to me changes state")
• Team — Notifications for the whole team (e.g., "Notify the team channel when a sprint burndown is at risk")
• Project — Organization-wide alerts (e.g., "Notify security team when a 'Security' tagged bug is created")

Microsoft Teams Integration

The Azure Boards app for Microsoft Teams enables:

• Creating work items directly from Teams messages (right-click → More actions → Create work item)
• Linking Teams conversations to work items for context
• Subscribing channels to board events (new bugs, sprint completions)
• Previewing work item details inline when someone pastes a link

Wiki Integration

Azure DevOps Wiki and Boards work together — you can embed work item queries in wiki pages (showing live status), and link wiki pages from work items for requirements documentation or architectural decision records.

Case Study: Enterprise Board Setup

Exercises