Making "done" mean something in Azure DevOps
Azure DevOps can already tell you which work items went into a given deployment. Here is how to wire states, branch policies and environments so that answer is trustworthy.
The work item is in the final state. The pull request is completed. Somebody in another team asks whether it is in production and three people look at each other. The board has told you that engineering has finished with it, which is a different claim entirely, and one nobody outside engineering ever wanted.
Azure DevOps is unusually well equipped to close this gap, better than most of its competitors, and most organisations use about a third of what they have already paid for. What follows is the part worth turning on.
Start with the state model, because it is not what you think
Two things about Azure Boards states cause more confusion than anything else in the product.
States vary by process. Your project was created from a process template, and the final state may be called Closed or Done depending on which one. If your organisation has projects on different processes, and most large organisations do, then reports written against a state name will silently return the wrong set for half the estate.
States belong to state categories. Each state maps to a category such as proposed, in progress, resolved, completed or removed, and it is the category that boards and charts read. This is the important detail, because it means you can add your own states without breaking the reporting. If you want a state between merged and released, you can have one, and nothing in the analytics will object as long as you map it to a sensible category.
Take that offer. The single highest-value change here is to stop having one state that means both “engineering has finished” and “customers have it”. Split them.
Write your definition of done onto the board column. Azure Boards lets a Kanban column carry a definition of done text that is visible from the board itself. Where the exact setting lives varies by version, but the capability has been there a long time. It is worth using for one reason: it is the only place your definition of done will be read at the moment somebody is deciding to move a card. A wiki page is read once, during onboarding, by someone who was not listening.
What Azure Repos and Pipelines already enforce
Branch policies. On a protected branch you can require a minimum number of reviewers, require that comments are resolved, require a successful build, require reviewers for particular paths, and require that the pull request has linked work items. That last policy is the one to enable first. It converts your linking rate from a thing you hope is high into a thing that is structurally near a hundred percent, and every derived report downstream depends on it.
Commit and pull request linking. Referencing a work item ID in a commit message or pull request creates the link. The exact prefix differs depending on whether your repository lives in Azure Repos or in GitHub connected to Azure Boards, so confirm which form your team should be using rather than assuming.
Pipeline environments with approvals and checks. A deployment stage can target a named environment that carries its own approval requirements and checks. This gives you two things: a real deployment record tying a build to an environment, and a place to put the human gate that is actually about releasing rather than about reviewing a diff.
Associated work items on a run. This is the capability that makes Azure DevOps genuinely strong here. A build or deployment can report the work items and commits included since the previous successful one. Once you have branch policies enforcing links and pipelines targeting environments, you can answer “what shipped in this release” from the tool rather than from a spreadsheet somebody maintains.
The policy checks that a link exists, not that it is the right one
The linked work item policy checks a link exists, not that it is the right one. People under time pressure link whatever is nearest. The policy raises your linking rate to nearly everything and your link quality not at all, and quality is invisible to every report built on top.
Process customisation is administrator work with organisational reach. Adding a state means editing an inherited process, which may be shared across many projects. In a large tenant, the person who can make the change is several conversations away from the team that needs it.
One work item, several repositories. A change spanning services produces several pull requests, each satisfying its own branch policies. Nothing evaluates whether the work item as a whole is complete, and the bigger the estate the more of your genuine risk sits precisely there.
The final transition is still manual. Everything above gives you excellent evidence. Moving the card remains an act of human assertion, and under sprint-end pressure that assertion gets cheap.
Associated work items depend on clean build history. Force pushes, rebuilds, and pipelines that do not run on every merge all distort the “since last successful run” calculation, sometimes badly.
Branch policy first, then the harder half
Enable the linked work items policy on your protected branches. Free, five minutes, and it is the foundation for everything else. Expect a fortnight of complaints and then silence.
Split the end of your state model. One state for merged, one for released, mapped to appropriate categories. Then check your queries and dashboards for anything filtering on a state name rather than a category.
Put the definition of done on the column. Rewrite it first as checkable statements. The exercise of deciding which of your fourteen bullets can actually be evaluated is more valuable than the text you end up with.
Target environments in your deployment pipelines. If your pipeline deploys without naming an environment, Azure DevOps knows nothing about your software after the merge, and you are throwing away the best feature in the product.
Move the approval to the environment. Reviewing code and authorising a release are different decisions made on different information. Environment approvals let you stop pretending they are the same one.
Then automate the release transition. Have the deployment stage move the work item to released rather than a person. At that point “is it live” becomes a query.
Done properly, this is a complete answer inside the tooling you already own, for a single-project team on a single repository. There is nothing further to buy.
Where this breaks down
Enforcement produces link spam. Every mandatory link policy generates a population of technically-satisfied, semantically-empty links. Your metrics improve and your knowledge does not. Sample twenty links by hand a month after enabling it and see what you find.
Adding states breaks things you have forgotten about. Saved queries, dashboards, exports into finance systems, that Power BI report someone built in 2023. Search for hard-coded state names before you change anything.
More gates means more overrides. Branch policies can be bypassed by people with the permission, and a policy that blocks a hotfix at midnight will be bypassed. That is correct behaviour. Just make sure bypasses are visible afterwards, or you have added ceremony rather than control.
The tool cannot tell you whether the work was any good. Everything here verifies that the artefacts of a process are present. It does not verify that the change does what the work item said. Confusing the two produces a very well instrumented form of theatre.