The fastest way to lose trust in any analytics dashboard is to calculate the right math on the wrong workflow states. Azure DevOps teams often use custom states like Ready for Dev, In Test, Waiting for Review, or Released. If those states are not mapped into the right stages, cycle time, burndown, reliability, and aging metrics all become harder to interpret.
Why Workflow Mapping Matters
Agile Analytics uses your saved workflow mapping to understand where work is queued, active, blocked, or done. That mapping becomes the semantic layer behind multiple reports.
- Sprint metrics rely on done-state mapping to count completed work correctly.
- Cycle time depends on the first active state and the final done state.
- Aging views depend on which states are considered in-progress vs waiting.
- Agile Coach summaries become more useful when stage definitions reflect reality.
A Practical Mapping Model
Most teams can start with a simple five-stage model and refine later:
- New: ideas or untriaged work not ready for delivery.
- Queued: approved work that is ready but not yet being worked.
- Active: development, implementation, test execution, or review that is actively consuming team capacity.
- Blocked or Waiting: work paused on dependency, approval, environment, or review latency.
- Done: states that truly meet your Definition of Done, not just code complete.
Common Mapping Mistakes
These mistakes are responsible for many misleading dashboards:
- Treating Ready for Test or Waiting for Review as done, which understates cycle time.
- Leaving custom states unmapped, which can make items disappear from stage breakdowns.
- Counting backlog refinement states as active work, which inflates WIP.
- Using a done state that does not match how the team closes stories in practice.
A Good Admin Setup Sequence
If you are rolling out Agile Analytics to a new project, use this order:
- Claim admin access first in Access Control so settings are saved by the right owner.
- Review a live board and list every state teams actually use today.
- Map states in Workflow Mapping based on how work flows, not how labels sound.
- Save, reload the dashboard, and validate one recent sprint against known outcomes.
- Only after that should you socialize the dashboard more broadly.
How to Know the Mapping Is Working
A healthy mapping usually produces sprint completion counts that match retrospective records, aging items that align with team intuition, and cycle-time percentiles that feel plausible. If the numbers still look odd, the next place to inspect is whether teams are updating work-item states consistently and whether the same workflow is being used across all scoped teams.