Azure DevOps dashboard widgets are how most engineering teams first encounter delivery analytics. The dashboard page is already pinned to their browser, so a good widget set is the lowest-friction way to get sprint health, flow metrics, and forecasting into the team's daily view. The catch is that the built-in widget catalog covers work-item queries and a thin set of charts — the widgets that actually drive sprint conversations are not there. This guide walks through the six widgets every Azure DevOps dashboard should have and what each one needs to show to be useful.
Widget 1: Sprint summary
A sprint summary widget should answer one question at a glance — is this sprint on track? The basics: committed item count and points, completed count and points, scope change since the commitment lock, days remaining, and a clear health indicator. A good sprint summary widget freezes commitment at the end of day 2 of the sprint so late refinements do not corrupt the baseline, and shows scope additions separately from original commitment.
Widget 2: Velocity over the last 6 sprints
A velocity widget should show enough history to spot a trend. Six sprints is the right minimum — three is too noisy, ten is too long for most retrospectives. The widget should also show a trend line and the standard deviation as a band, so the team can see whether velocity is stable or drifting. A velocity widget that shows only the current sprint's number is not useful — the value is in the comparison.
Widget 3: Burndown with the commitment line
A useful burndown widget shows two lines — the actual remaining work and the original commitment. The committed line stays flat across the sprint; scope additions appear as upward steps on the actual line. This makes scope creep visible without anyone needing to call it out. A burndown widget that only shows actual remaining work hides the most important signal.
Widget 4: Cycle time scatterplot
A cycle time widget should be a scatterplot, not a bar chart. Each completed item is a dot positioned by completion date and cycle time; P50 and P85 percentile lines run across the chart. The team can immediately see the typical service expectation, the spread of variability, and the outliers. A cycle time widget that only reports an average is hiding the spread that actually matters.
Widget 5: Throughput
A throughput widget should show items completed per sprint or per week, broken down by item type. This is the input to forecasting, the simplest measure of team output, and the cleanest way to spot drops in delivery rate before they become a problem. Pair it with the velocity widget for the full picture — velocity tells you sized output, throughput tells you raw count.
Widget 6: Flow signals
A flow signal widget surfaces the things that quietly damage delivery — aging work, blocked items, breached WIP limits, items with no recent activity. These are the early warning lights for the next sprint. A widget that combines all of these into a single ranked list of risk items is more useful than four separate widgets, because it points the team at what to act on first.
Where these six live in Agile Analytics
Agile Analytics covers all six as pre-wired views inside Azure DevOps: sprint summary, sprint velocity, burndown with a scope line, a cycle time scatterplot with P50 and P85 percentile lines, throughput, and delivery signals for aging and blocked work. They open in the Agile Analytics hub, one click from Boards, rather than being pinned onto the dashboard page — so your existing dashboards and tiles are left exactly as they are. See the Azure DevOps dashboard solution for screenshots, or the dashboard guide if you are designing yours from scratch.
Related: Azure DevOps dashboard · Browse all dashboards · How to build an Azure DevOps dashboard · Customize the home dashboard
Whichever way you surface them, the metric set is the difference between analytics that gets used and analytics that gets bookmarked and ignored. The views that answer the questions teams actually ask — what happened in the sprint, how are we trending, what is at risk — are the ones a team opens without being asked to.