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 views are pre-built around delivery questions, they read your Boards data live, and there is no separate BI project to maintain. Agile Analytics takes this approach — sprint summary, velocity, burndown, a cycle time scatterplot, and flow signals are all pre-wired views inside Azure DevOps. They open in the Agile Analytics hub, one click from Boards, rather than being pinned onto the dashboard page itself, so your existing dashboards and tiles stay exactly as they are. See the full Azure DevOps dashboard solution for screenshots and the view catalog.
Related: Azure DevOps dashboard · Browse all dashboards · Customize the home dashboard
A minimum delivery dashboard, in 6 views
If you only build one dashboard, build this one. Six views cover the questions above without overloading the page:
- Sprint summary — committed vs completed, scope change, carryover, and the items removed mid-sprint.
- Velocity over the last 6 sprints with a trend line and commitment reliability.
- Burndown with the ideal line, the actual line, and a scope line that exposes mid-sprint additions.
- Cycle time scatterplot with P50 and P85 percentile lines.
- WIP monitoring against the WIP limits your team has configured.
- Monte Carlo forecast: a confidence range for the next chunk of scope rather than a single date.
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.