A useful sprint health dashboard answers one question in the middle of the sprint: will the team finish what it committed to, and if not, what is getting in the way? Five things cover most of it: aging and blocked work, work in progress against limits, scope churn, carryover and commitment reliability, with a few flow numbers on top. This guide goes through each, what it tells you, and where to find it in Agile Analytics, an Azure DevOps extension.
What sprint health should answer mid-sprint
Most dashboards show what already happened. A Scrum Master on day five of ten needs something different: a view that points at what to do tomorrow morning. A mid-sprint view should answer four questions.
- Is anything stuck? Items that have been in flight too long, or are blocked, are the earliest warning you get.
- Is the team starting too much? Too much work in progress usually shows up as late finishes a week later.
- Did the sprint change shape? Work added or pulled out after the start explains a lot of missed sprints.
- How has this team done before? One sprint in isolation tells you little. A pattern across sprints tells you how much to trust the plan.
A burndown chart shows how much work remains, but not why progress has slowed, so pair it with the signals below rather than relying on it alone. The Agile Analytics Dashboard view is a reasonable first stop. It puts KPIs on one screen: cycle time bands, WIP, flow efficiency, lead time, throughput and a 30-day “How many?” forecast. It tells you whether the team’s flow looks normal. The sections below cover the views that tell you why it does or does not.
Related: How to build a sprint flow dashboard · Why a burndown chart is empty
Aging and blocked work
If you can only look at one thing mid-sprint, look at how long items have been in flight. A story that has sat in progress for twice as long as the team’s usual work will not finish quietly. The Aging & Blocked view plots every in-flight item by days in flow against the team’s p50 and p85, ranked by urgency. The p50 is the point at which half of your past completed items had finished, and the p85 is where 85% had. An item beyond the p85 is already slower than most of what this team has delivered, so it deserves a conversation, not a status update.
The same view shows blocked items, and it arranges the state lanes in the team’s board order, so the picture matches the board people already know. In practice:
- Start the standup at the top of the urgency ranking, not at the first name on the roster.
- For every item near or past the p85, ask what would have to be true for it to finish this sprint, and who can make that happen.
- For blocked items, ask who owns the unblock and by when, then check the same list the next day.
WIP against limits
Aging tells you which items are late. WIP tells you why more items are about to be. When a team has several things half done per person, every one of them slows down. The WIP Monitor shows work in progress against per-team WIP limits. You can also set up alerts that go to Microsoft Teams or Slack through a webhook, and the webhook call is made from the browser straight to your Teams or Slack URL, not through Baytek. Set limits per team, not per organisation: a team of four and a team of nine do not share a sensible number. A WIP limit is a prompt for a conversation, not a rule. When the count goes over, the useful question is what the team should finish before pulling anything new.
Related: Azure DevOps WIP monitoring
Scope churn and carryover
Scope churn is the change in what the sprint contains after it started. Carryover is the work that rolls into the next sprint unfinished. They are linked: a sprint that picks up unplanned work part-way through often ends with more carryover. The Sprint Summary view reports a per-team sprint baseline, commitment reliability, scope churn, carryover, planned work and bugs, with CSV export. Read the numbers side by side:
- High churn and high carryover: the plan changed and the team absorbed it. The conversation is with whoever is adding scope, not with the team.
- Low churn and high carryover: the plan held but the team took on too much, or items were larger than they looked. That points at estimation or slicing.
- A growing share of bugs: unplanned work may be entering through the defect queue rather than through the backlog.
Mid-sprint, scope churn is something you can act on. If it is climbing on day four, you can raise it with the product owner while there is still time to trade something out. At the retrospective, it is only a record. The Delivery Signals view adds carryover trend and time to start across past sprints, which helps you tell a blip from the usual pattern.
Related: Reducing sprint carryover
Sprint Summary rebuilds each sprint from the iteration history Azure DevOps keeps, querying every item that was ever in the sprint, so work pulled out mid-sprint is still counted rather than silently disappearing from the board. The commitment is locked at the end of day 1. After that, the Scope Change tile shows items added and removed as +N / -N, and an item that leaves and comes back counts on neither side. Below the tiles:
- A collapsible list of the items removed from sprint scope after Day 1, each with the state it was in and the date it was removed.
- A separate list of the items moved to the next sprint, each marked Carryover with the state it was in when it moved.
- Add Team puts another team’s card beside the first, each with its own sprint picker, for programme-level reviews.
- Download CSV exports one team’s card, and Download All exports every team on the page.
Commitment reliability
Commitment reliability compares what the team committed to with what it delivered. Taken once, it is a score. Taken over six or eight sprints, it tells you how much to trust the next sprint plan. For the exact definition the extension uses, check the in-product glossary, How These Metrics Work, rather than assuming it matches your own spreadsheet. You will find it in Sprint Summary for the current per-team baseline, and in Delivery Signals for the trend across past sprints.
- Use it to size the next commitment. If a team has consistently delivered less than it committed to, planning for more is not a plan. The Next Sprint Planning view combines capacity, a Monte Carlo run on the last 6 sprints, cycle time per bucket and historical commitment reliability into one recommendation.
- Do not use it to compare teams. Teams size and slice work differently, so compare a team with its own past.
- Read it with churn. A reliability dip in a sprint with heavy scope churn is a different problem from a dip in a stable sprint.
For forecasting beyond the sprint, the Monte Carlo view runs 10,000 simulations on historical throughput and gives outcomes at 95%, 85%, 70% and 50% confidence. It sits alongside the sprint view, not inside it, but it answers the question stakeholders ask next: when will it be done.
Putting tiles on the Azure DevOps dashboard
The views above are for the person running the sprint. Some of the answer should also be visible to everyone else without opening a hub. Azure DevOps project dashboards take widgets, and Agile Analytics ships companion tiles in the widget catalog under the Agile Analytics category. To add them, edit the dashboard, open the widget picker and look for that category. The tiles you see depend on your installed version, so browse the catalog rather than assuming a list.
- The Sprint Forecast tile is free. It works for every organisation without a licence, including after the 30-day trial ends.
- Tiles can pick a team from any project, so a single shared dashboard can show more than one team.
A sensible dashboard for a sprint is small. Put a forecast tile, one or two flow signals and a link to the full hub, and leave the detail where people can drill into it. None of this needs Power BI, Analytics views, a personal access token or a database. The views run in the browser against the Azure DevOps REST API, using the signed-in user’s session. The extension supports Azure DevOps Services only, not Azure DevOps Server.
Related: Azure DevOps dashboard · Azure DevOps sprint reporting
Try it on a live sprint
Agile Analytics starts a 30-day free trial automatically on install, with no credit card and no sign-up form. During the trial everyone in the organisation has full access, so you can open Aging & Blocked, WIP Monitor and Sprint Summary on a live sprint and see whether they answer the questions above. See the pricing page for plans after the trial.
Related: Install instructions · Pricing