Sooner or later someone asks a question about the past. When did this bug get picked up? How long did that story sit in review? Why did it go back to In Progress twice? Who changed the permissions on the release pipeline? All of these are audit questions, but they need different records. Azure DevOps already keeps most of them. The trick is knowing which record answers which question.
Three kinds of audit trail
It helps to separate three things that all get called an audit trail.
- Work item history: every change to one work item, field by field, with who made it and when.
- Organization audit log: changes to the organization itself, such as permissions, policies, deleted resources and access to the log.
- Delivery timeline: how a set of work items moved through your workflow over a period, such as a sprint, with the time spent between each move.
Work item History in Azure DevOps
Every work item has a History tab. It lists each revision: the fields that changed, the old and new values, the person who made the change and the time. This is the authoritative record of who changed what on a single item, and it is where to go when the question is about a person or a field. Its limit is scope. It shows one item at a time, so it does not tell you how a whole sprint flowed, and adding up how long an item spent in each state means reading the revisions and doing the arithmetic yourself.
Organization Auditing in Azure DevOps
Azure DevOps Services also has an organization-level audit log, under Organization settings → Auditing. It records changes to the state of artifacts in the organization. Microsoft’s examples include permission changes, deleted resources, branch policy changes and access to the log itself. A few things to know before you rely on it:
- Auditing is turned off by default. An administrator turns on Log Audit Events under Organization settings → Policies.
- It is only available for organizations backed by Microsoft Entra ID.
- Events are kept for 90 days. To keep them longer, download them as CSV or JSON, or set up audit streaming to another system.
- It covers the organization, not the movement of work through a sprint.
The Audit Trail view in Agile Analytics
The Agile Analytics Audit Trail view fills the third gap: a delivery timeline for one sprint. Its own description says it shows the state transition history for every work item in a sprint, for auditing delivery timelines, finding bottlenecks and demonstrating process compliance. It reads the same work item revision history that Azure DevOps keeps, so it adds no new tracking and needs no setup.
- Find it under the Extra group in the navigation sidebar. The group is collapsed by default, so expand it first, and pick a team.
- Choose a sprint from the Sprint list. Each entry is marked (active), (past) or (future), and the active sprint is selected first.
- Each work item is a row with its type, ID, title, current state and the number of state change events.
- Expand a row to see each transition as from-state to to-state, with the date and time and how long the item had spent in the previous state, for example "+2.5d in prev state". Expand all and Collapse all work on every row at once.
- Search by ID or title to find one item quickly, and open any item in Azure DevOps from its row.
- Export the timeline as CSV: one row per transition, with the item, the from and to states, the time of the change and the days spent in the previous state.
What it does not show
Be clear about the limits before you use it for an audit. The Audit Trail view shows when each state change happened and how long the item waited before it. It does not show who made the change. For that, open the item’s History tab in Azure DevOps. It lists the items currently in the sprint, so an item that was moved out of the sprint does not appear. For scope that left mid-sprint, use Sprint Summary, which lists items removed after the commitment. And it follows your Item Types configuration, so types you have not mapped are not listed.
Using it in sprint reviews
In a sprint review, the timeline gives the team and stakeholders a shared record of how work moved. Instead of reconstructing the sequence from memory, walk through the items that took longest. The "in prev state" durations show where the time went: often not in development but in a queue before review or test. That turns "this took too long" into "this waited four days for review", which is something the team can change.
Using it in retrospectives
In a retrospective, the timeline is a facts-first start to the discussion. Patterns that are hard to see on a board stand out in a list of transitions:
- Items that went from Review back to In Progress, sometimes more than once. Ask what the reviewer found that the author did not.
- Long gaps before Test or Review. These are queues, and they are usually cheaper to fix than development time.
- Several items that changed state within minutes at the end of the sprint. That is usually the board being updated after the fact, which makes every flow metric less reliable.
- Bugs that were closed and reopened. Look at what "done" meant the first time.
Using it for process checks
Some teams need to show that work followed an agreed process, for example that every story passed through a test state before it was closed. The timeline makes that a quick check: expand all, or export the CSV and filter for items that reached Done without the expected state in between. Treat the result as evidence for a conversation, not as proof on its own. Combine it with the item History for the who, and with organization Auditing for permission and policy changes.
Changes to the extension’s own settings
Separately, admins can see changes made to Agile Analytics itself. Configuration → Access Control has an Admin activity list: who changed what, when, across areas such as workflow mapping, access control, seats and CSV exports. It is stored in your organisation’s own Azure DevOps storage and keeps the newest 400 entries. The product describes it as an operational record, not a tamper-proof audit trail, and that is the right way to treat it.
Related: How Agile Analytics works · Data privacy and transparency · Workflow mapping setup guide