Azure Boards, work item links and flow metrics
Azure DevOps and GitHub are often used together, and the AZ-400 exam checks that you can connect them and measure how work flows. Most questions come down to one setting or one syntax.
Connect GitHub to Azure Boards
Install the Azure Boards app from GitHub Marketplace on the organization or repository, then authenticate and pick the Azure DevOps project. From then on, mention a work item in a commit message, pull request title or description with AB#123. The work item gets a link to the commit or pull request.
To close the item automatically, put a keyword before the mention, for example Fixes AB#123. The state changes when the pull request merges into the default branch. Several items can be listed in one message.
The Azure Pipelines app is a different app. It connects pipelines to the repository so builds can run, and it is not needed to link work items.
Link types
| Link | Use it for |
|---|---|
| Parent / Child | Breaking an epic into features and stories |
| Predecessor / Successor | Sequencing and dependencies between teams |
| Related | Loose connection with no order |
| Commit / Pull request / Build | Traceability to code and pipelines |
For cross-team consumers and producers, use Predecessor/Successor links, and the Delivery Plans view for an overview across projects.
Flow metrics and widgets
- Lead time: from creation to done. Shows what the customer experiences.
- Cycle time: from active to done. Shows how fast the team works once it starts.
- Cumulative Flow Diagram: items per state over time. A widening band means a bottleneck.
- Burndown / Burnup: remaining or completed work against a sprint or scope.
- Velocity: story points completed per sprint.
Dashboards hold these widgets and can be shared at team or project level.
Work item processes
Azure DevOps ships four inherited processes: Basic, Agile, Scrum and CMMI. Basic is the simplest (Epic, Issue, Task). Agile uses User Story, Scrum uses Product Backlog Item, and CMMI uses Requirement and adds formal change and risk tracking. Customize by creating an inherited process, not by editing the system one.
Wiki ordering
A published wiki is built from a Git repository folder. Page order comes from a .order file that lists page names, one per line. A project wiki can be reordered by drag and drop.
Exam traps
- Confusing the Azure Boards app with the Azure Pipelines app when the goal is work item links.
- Using
#456when linking from GitHub. In GitHub,#points to a GitHub issue; useAB#456for Azure Boards. - Mixing up cycle time and lead time. Lead time begins at creation.
- Expecting drag and drop to reorder a published code wiki.
- Editing a system process instead of inheriting from it.
Practice questions
Choose an answer, then review the explanation to check your understanding.
1. Developers commit to a private GitHub repository. You want each pull request to show up on the related Azure Boards work item. What do you do first?
Show answer
Answer: A.The Azure Boards app for GitHub creates the connection between the repository and the Azure DevOps project. Without it, AB# mentions do nothing.
2. A commit message must link to work item 456 and move it to Done when the pull request merges. What should the message contain?
Show answer
Answer: B.In GitHub, the AB#ID syntax links the work item, and a keyword such as Fixes in front of it also closes it on merge.
3. You must show how long work items take from the moment they become active until they are completed. Which widget fits?
Show answer
Answer: C.Cycle time is measured from active to done. Lead time starts earlier, at creation.
4. You publish a wiki from a Git repository and need to change the order of pages in the navigation pane. What do you add?
Show answer
Answer: B.A .order file lists the page names in the order you want. Drag and drop only works in a project wiki, not a published code wiki.