Work Item Tracking: From Request to Running Service
Build an Azure Boards workflow with feedback, acceptance criteria, and links from a customer request to the deployed change.
Start with the delivery receipt
A repair shop gives every job a number. The number connects the customer’s complaint, the mechanic’s work, the test drive, and the collection receipt. Software needs the same chain. A green build is the test drive, not proof the customer received the repair.
This is the first of 27 free AZ-401 lessons. The course follows Microsoft’s published objectives checked on 30 October 2026. AZ-401 is a beta exam; product features and objectives can change. These lessons teach the skills, not Microsoft’s confidential exam questions. The separate practice product has a 20-question free preview and a paid full bank.
Give each phase an entry and exit
Imagine a small booking application. Customers report that confirmation emails sometimes arrive twice. “Fix duplicate emails” is not yet a useful delivery contract: nobody has stated what counts as success.
| Phase | Work and evidence | Useful feedback |
|---|---|---|
| Plan | Bug with reproduction, impact, owner, acceptance criteria | Support confirms the real customer symptom |
| Build | Linked PR, reviewed code, unit and integration results | Developer receives an actionable failed check |
| Deploy | Versioned artifact, target environment, rollout evidence | Release owner sees failed health checks |
| Operate | Request failures, duplicate-send metric, support confirmation | Product owner decides whether the outcome was achieved |
Use the team’s selected Azure Boards process rather than forcing every organization into one hierarchy. Agile uses user stories; Scrum uses product backlog items; Basic and CMMI differ again. Features and epics help coordinate larger outcomes, while tasks break down implementation.
Keep acceptance criteria observable: “Retrying the same booking request does not send a second email.” A task such as “add a queue” describes a possible implementation, not the outcome. Define who accepts the result and which evidence they need.
Configure a useful board
In a disposable Azure DevOps project, create a team and choose its area and iteration paths. Team configuration controls which work appears on its backlog and board. Map workflow states to columns such as New, Active, Review, and Done. Column names need not be identical to work-item states.
Set a work-in-progress limit where work accumulates. A limit is a visual signal to discuss blocked flow; it does not automatically prevent a developer from moving another card into that column. Mark blocked work visibly and record why. Otherwise a queue becomes invisible until the release is late.
For the email bug, link a task for reproducing the retry, a PR for the fix, and the test result demonstrating one delivery. Do not mark the customer outcome complete merely because the implementation task finished.
Follow the links, not a copied status report
Azure Repos can associate commits and PRs with work items through its built-in work-item linking. With a configured Azure Boards-to-GitHub connection, put a reference such as AB#123 in a supported location, for example the GitHub PR description:
Prevent duplicate confirmation emails.
Related work: AB#123
Evidence: integration test retries the same booking identifier.The identifier here is illustrative; use your own test work item. GitHub PR titles and comments do not create these Azure Boards links. A supported closing expression such as Fixes AB#123 can request a state transition when the PR merges to the default branch; permissions, connection settings, and workflow configuration still matter. A reference is not a universal deployment-completed signal.
Preserve the build/run identifier and deployment target. “PR merged” answers a source-control question. “Artifact from run 456 deployed to production and passed its health check” answers a release question. These should not be collapsed into the same checkbox.
Make feedback reach someone who can act
Use targeted subscriptions for events that need action: assigned bug, failed build, or approval waiting. Use dashboards for trends that do not need an immediate interruption. Teams and individuals can have different subscriptions, so check effective recipients instead of assuming a team setting overrides every personal preference.
Service hooks deliver events to an integration endpoint; they do not supply a response process. Choose an owner, urgency, escalation path, and deduplication strategy. An agent can summarize a failed build using approved read access, but its summary should link to the original run and avoid exposing logs to a broader audience.
A PR is merged and its build is green. Support asks which deployed change fixed a customer's bug. What evidence is still needed?
Try it: reconstruct one change
Prerequisites: a sandbox Azure DevOps project with Boards access; a test repository and connection permissions if you also want GitHub links. No Azure resource deployment is required.
- Create a test bug with one reproducible symptom and two measurable acceptance criteria.
- Link a task and a draft PR. For GitHub, put your real
AB#reference in the PR description and verify the link appears on the work item. - Write down what build and deployment evidence would be required before closing the customer issue.
- Configure one narrowly filtered notification, then inspect its recipients.
Expected observation: the work item shows linked development artifacts. There is still no production deployment merely because those links exist.
Cleanup: close the draft PR, remove the test notification, and close or delete only your disposable test work. If you have no project access, draw the evidence chain on paper; do not describe that as a completed integration.
Decision check: when would you reopen the work?
Reopen or create linked follow-up work when operational evidence shows the acceptance criteria were not met. A merged PR is not a reason to ignore a continuing customer symptom.