Work Item Tracking: Boards, GitHub & Flow

Why Work Item Tracking Matters in DevOps

Azure Boards vs GitHub Projects

Both platforms offer work tracking, but they serve different scales and workflows. Knowing when to recommend each is a core AZ-400 skill.

Azure Boards vs GitHub Projects

Capability	Azure Boards	GitHub Projects
Work item hierarchy	Epic - Feature - User Story - Task - Bug (5 levels)	Issues with sub-issues and task lists (flexible nesting)
Process templates	Basic, Agile, Scrum, CMMI (choose at project creation)	No fixed process — custom fields and views
Board customisation	Swimlanes, card styles, column rules, split columns	Custom fields, grouping, multiple views (board/table/roadmap)
WIP limits	Built-in per column with visual warnings	No native WIP limits
Queries and reporting	Powerful query editor with flat/tree/direct links modes	Filter views with custom field filters and charts
Automation	Rules engine (when state changes, assign, notify)	Built-in automation workflows (when item added, set field)
Sprint planning	Full sprint board with capacity planning and burndown	Iteration custom field with roadmap view
Integration with repos	Azure Repos + GitHub via AB# syntax	Native GitHub integration — closes issues from PRs
Best for	Enterprise teams needing formal process and compliance	Teams already on GitHub wanting lightweight planning

🏢 Nadia’s Enterprise Board Setup

Nadia at Meridian Insurance uses Azure Boards with the Agile process template. Her team tracks:

• Epics — major business initiatives (“Claims Portal Modernisation”)
• Features — deliverables within an Epic (“Online Claims Submission”)
• User Stories — user-facing functionality (“As a policyholder, I can upload photos of damage”)
• Tasks — developer work units (“Create blob storage upload API endpoint”)
• Bugs — linked to the Story they affect

She configures swimlanes by team (Frontend, Backend, QA) and sets WIP limits of 3 per developer on the “In Progress” column. When a column turns red (over WIP), the team knows to finish work before starting new items.

🚀 Kai’s GitHub Projects Setup

Kai at Launchpad Labs uses GitHub Projects with custom fields:

• Priority (P0–P3)
• Sprint (two-week iterations)
• Size (XS/S/M/L/XL)

He creates three views: a Board for daily standups, a Table for backlog grooming, and a Roadmap for quarterly planning with stakeholders.

GitHub Flow: The 6-Step Workflow

GitHub Flow is the branching and collaboration model the exam expects you to know inside-out. It’s simple by design — one long-lived branch (main) and short-lived feature branches.

The six steps:

1. Create a branch — branch off main with a descriptive name (feature/claims-upload)
2. Make changes — commit frequently with meaningful messages
3. Open a pull request — even before code is finished (draft PRs for early feedback)
4. Review and discuss — team reviews code, CI checks run automatically
5. Merge — squash merge or merge commit into main
6. Deploy — main is always deployable; deploy immediately or on schedule

Question

What is the core principle of GitHub Flow?

Click or press Enter to reveal answer

Answer

There is only one long-lived branch (main), and it must always be in a deployable state. All work happens on short-lived feature branches that are merged back via pull requests.

Click to flip back

Exam Tip: GitHub Flow vs Git Flow

The exam may contrast GitHub Flow with Git Flow. GitHub Flow uses one main branch and feature branches — suited for continuous deployment. Git Flow adds develop, release/*, and hotfix/* branches — suited for scheduled releases. The AZ-400 heavily favours GitHub Flow for CD scenarios and Git Flow (or release branching) for enterprise scheduled releases.

Feedback Cycles and Notifications

Fast feedback loops are a DevOps pillar. The exam tests your ability to design notification strategies that inform without overwhelming.

Configuring Feedback in Azure DevOps

• Follow a work item — get email on every update
• Team notifications — configure per-team rules (e.g., “notify QA when a bug moves to Ready for Test”)
• Service hooks — push events to Slack, Teams, or custom webhooks
• @mentions in work item discussions — targeted notifications
• Dashboards — pull-based: team checks the dashboard rather than receiving push notifications

Configuring Feedback in GitHub

• Watch settings — per-repository (all activity, releases only, issues/PRs, or ignore)
• @mentions and team mentions (@org/team-name)
• CODEOWNERS — automatically request reviews from the right people
• GitHub Issues templates — guide reporters to provide structured feedback
• Discussion forums — for open-ended feedback that doesn’t need a work item yet

Question

In Azure DevOps, what is the difference between a Team Notification and a Personal Notification?

Click or press Enter to reveal answer

Answer

Team Notifications are configured by team admins and apply to all team members (e.g., 'notify team when build fails'). Personal Notifications are configured by individual users for their own preferences. Team notifications cannot be overridden by personal settings — they always deliver.

Click to flip back

🏢 Nadia’s Notification Strategy

Nadia configures three tiers at Meridian:

1. Critical — build failures and deployment failures go to Teams channel AND email
2. Actionable — PR reviews assigned, work items assigned go to email only
3. Informational — sprint burndown, velocity trends visible on the dashboard (pull-based, no push notification)

This prevents alert fatigue while ensuring nothing critical is missed.

Traceability: From Work Item to Production

Traceability means you can trace any line of code in production back to the work item that requested it, the PR that reviewed it, the build that compiled it, and the release that deployed it. Regulated industries (Nadia’s insurance, Amira’s government clients) often require this for audit.

AB# Syntax (Azure Boards + GitHub)

When you install the Azure Boards GitHub App, you can link GitHub commits and PRs to Azure Boards work items using AB#1234 in commit messages or PR descriptions.

• AB#1234 — creates a link (doesn’t change state)
• Combine with branch policy: “Resolve work items on merge” — automatically moves linked items to Done/Closed

GitHub Native Traceability

• Closes #42 or Fixes #42 in a PR description — auto-closes the issue when the PR merges
• Resolves #42 also works
• Multiple issues: Closes #42, closes #43
• Cross-repo: Closes org/other-repo#42

Question

What syntax links a GitHub commit to an Azure Boards work item?

Click or press Enter to reveal answer

Answer

AB#1234 — where 1234 is the work item ID. This requires the Azure Boards GitHub App to be installed on the repository. The link appears in both the GitHub commit/PR and the Azure Boards work item.

Click to flip back

The Traceability Chain

A complete traceability chain looks like this:

Work Item (User Story #456)
  → Branch (feature/claims-upload)
    → Commits (AB#456 in message)
      → Pull Request (linked to #456)
        → Build (triggered by PR merge)
          → Release (deployed to production)
            → Work Item auto-resolved

Every link in this chain is auditable. Elena (Nadia’s compliance officer) can trace any production feature back to its original business request.

Azure Boards Work Item Hierarchy

Understanding the hierarchy and when to use each level is critical for the exam.

Level	Purpose	Example	Typically Managed By
Epic	Large business initiative spanning multiple sprints	”Customer Self-Service Portal”	Product Owner / PM
Feature	Deliverable capability within an Epic	”Password Reset Flow”	Product Owner
User Story (Agile) / PBI (Scrum)	User-facing functionality	”As a user, I can reset my password via email”	Development Team
Task	Developer work unit (hours, not days)	“Create password reset API endpoint”	Individual Developer
Bug	Defect linked to a Story/Feature	”Reset email contains wrong link”	QA / Development

Exam Tip: Process Template Differences

The CMMI process template adds Requirements and Change Requests — important for regulated environments. Amira uses CMMI for her government clients because it maps to formal change management processes. The exam may ask which process template supports formal change requests — the answer is always CMMI.

Kanban Board Customisation

Columns and WIP Limits

Kanban boards in Azure Boards can be customised with:

• Custom columns — add columns like “Code Review”, “QA”, “UAT” between “Active” and “Closed”
• Split columns — divide any column into “Doing” and “Done” halves to visualise handoffs
• WIP limits — set a maximum number of items per column; exceeding turns the column header red
• Column rules — auto-set fields when items enter a column (e.g., entering “QA” column auto-assigns the QA lead)
• Swimlanes — horizontal lanes for categorisation (by team, priority, or type)
• Card styles — colour cards based on rules (e.g., red border for P0 bugs, blue for features)

Definition of Done

Each column can have a Definition of Done checklist. Items cannot move to the next column until all checklist items are met. This enforces quality gates without requiring tooling changes.

Question

What happens when a Kanban column exceeds its WIP limit in Azure Boards?

Click or press Enter to reveal answer

Answer

The column header turns red as a visual warning, but items can still be added — WIP limits in Azure Boards are advisory, not enforced. The team must self-regulate. This is by design: Kanban philosophy treats WIP limits as signals, not hard blocks.

Click to flip back

Queries in Azure Boards

Queries are how you extract data from Azure Boards for reporting, dashboards, and bulk operations.

Three query types:

• Flat list — simple list of matching work items
• Tree of work items — shows parent-child hierarchy (Epic → Feature → Story)
• Direct links — shows items and their linked items (e.g., Stories linked to Test Cases)

Common query fields: State, Assigned To, Iteration Path, Area Path, Tags, Changed Date, Work Item Type

Queries power dashboard widgets (charts, burndowns, cumulative flow), email alerts, and bulk edits.

Question

What are the three query modes in Azure Boards?

Click or press Enter to reveal answer

Answer

1) Flat list — returns matching items as a simple list. 2) Tree of work items — shows parent/child hierarchy. 3) Direct links — shows items with their linked items (related, tested by, etc.). Tree queries are essential for seeing Epic → Feature → Story rollups.

Click to flip back

Knowledge Check

Kai's team uses GitHub and wants to automatically close GitHub Issues when pull requests merge. They also need to track these issues in Azure Boards. What should Kai configure?

AUse 'Closes #N' in PR descriptions and install the Azure Boards GitHub App with AB# referencesBUse Azure Boards webhooks to monitor GitHub PR events and close issues via the GitHub APICConfigure GitHub Actions to call the Azure Boards REST API on PR mergeDUse Azure Pipelines integration with GitHub to sync work item states

Check Answer

Knowledge Check

Nadia's compliance team needs to prove that every production deployment can be traced back to an approved user story. Which Azure Boards feature provides this end-to-end traceability?

ACumulative flow diagramsBWork item linking with branch policies that resolve items on mergeCSprint burndown charts with capacity planningDKanban board swimlanes configured by deployment stage

Check Answer

Knowledge Check

A team using GitHub Projects needs to enforce that no more than 3 items are in progress per developer at any time. What should they do?

ASet WIP limits on the GitHub Projects board columnsBCreate a GitHub Actions workflow that blocks new assignments when a developer has 3+ in-progress itemsCUse team agreements and visual indicators — GitHub Projects does not have native WIP limitsDConfigure branch protection rules to prevent more than 3 open PRs per developer

Check Answer

🎬 Video coming soon

Work Item Tracking Deep Dive

Next up: DevOps Metrics: Dashboards That Drive Decisions