Most Azure DevOps dashboards never become anyone's homepage. They start as a few work-item queries pinned to a tile, sit there for a sprint or two, and slowly stop being opened. The reason is simple — a dashboard built from work-item queries answers questions like "how many bugs are open" but not the questions engineering managers actually ask: how is this sprint going, are we slowing down, can we hit the date. A real Azure DevOps dashboard has to answer those questions in one glance, every time.
What a real delivery dashboard should answer
Before picking widgets, decide what the dashboard is for. A delivery dashboard for an engineering manager or scrum master should be able to answer five questions without scrolling:
- Sprint health — is this sprint on track, ahead, or in trouble?
- Velocity — what does this team usually deliver, and is the trend stable?
- Cycle time — how long does work actually take, and where are the outliers?
- WIP pressure — are we starting more than we are finishing?
- Forecast — based on history, when are we likely to be done with the next chunk of scope?
Path 1: The built-in Azure DevOps dashboard
Azure DevOps ships dashboards out of the box, and the built-in widget set covers basics — work-item queries, burndown, sprint capacity, and pull-request activity. This works fine for tracking individual queries, but the gap shows up fast. There is no flow analytics view, no percentile-based cycle time, no Monte Carlo forecasting, and no commitment-vs-completed view that survives mid-sprint scope change. Most teams hit the ceiling within a few sprints.
Path 2: Power BI with the Analytics service
Power BI plus the Azure DevOps Analytics service is the most flexible path. You can build any chart you want, blend data from other systems, and customize layouts down to the pixel. The cost is real, though — someone has to design the data model, manage refresh schedules, maintain dashboard versions, and respond when stakeholders ask for changes. Most teams do not have a dedicated BI function, and the dashboards drift within a quarter.
Path 3: A Marketplace extension
A Marketplace extension fills the middle. The dashboards are pre-built around delivery questions, the widgets pin to your existing Azure DevOps dashboard, and there is no separate BI project to maintain. Agile Analytics takes this approach — sprint summary, velocity, burndown, cycle time scatterplot, and flow signal widgets all live inside ADO, ready to drop onto any dashboard page. See the full Azure DevOps dashboard solution for screenshots and the widget catalog.
A minimum delivery dashboard, in 6 widgets
If you only build one dashboard, build this one. Six widgets cover the questions above without overloading the page:
- Sprint summary card — committed vs completed, scope change, days remaining.
- Velocity over the last 6 sprints with a trend line.
- Burndown with the commitment line frozen on day 2 of the sprint.
- Cycle time scatterplot with P50 and P85 percentile lines.
- WIP per column with team WIP limits visible.
- Monte Carlo forecast: P50, P85, P95 dates for the next chunk of scope.
What changes when the dashboard is good
When the dashboard answers the five questions in one glance, the conversation changes. Standups are shorter because everyone arrives with the same context. Sprint reviews stop arguing about what was committed. Stakeholders stop asking for a status update because they have a link to one. The dashboard becomes a meeting in itself — and the homepage your team actually opens.