Delivery Dashboards: See Waiting, Not Just Activity
Read cumulative flow, lead time, cycle time and recovery measures, and use GitHub Insights without confusing activity with delivery.
Watch the queue between the counters
A café can serve coffee quickly while customers wait twenty minutes to order. Measuring only preparation time misses the actual experience. A delivery dashboard should expose queues as well as work in progress.
Start with the decision the reader needs to make. A team board helps daily coordination. A flow chart helps identify bottlenecks. An operational recovery measure helps assess incident response. Combining them does not make their definitions interchangeable.
Read cumulative flow carefully
An Azure Boards cumulative flow diagram shows work-item counts across workflow states over time. A growing band for review suggests work is arriving faster than it leaves that state.
Check whether items are kept current and whether the board’s columns map correctly to state categories. A band can grow because work is blocked, but also because the team’s workflow or scope changed. Inspect the records before announcing a root cause.
Do not read a CFD band as CPU utilization or deployment duration. It describes the chosen work population, not every technical event in the service.
Use the right clock
| Measure | Example boundary | Interpretation caution |
|---|---|---|
| Work-item lead time | Creation to final completion | Includes waiting before active work |
| Work-item cycle time | First In Progress-category transition to final completion | Reopened work can extend the span |
| Change lead time | Defined code/change event to production | Must be separately instrumented |
| Recovery time | Defined impact/start event to restored service | Incident closure can occur later than restoration |
Azure Boards’ lead/cycle widgets follow their documented work-item semantics. Do not label their output commit-to-production time.
For recovery, define “restored”: for example, the affected customer operation returns within agreed error/latency objectives. A ticket marked resolved after a retrospective is not necessarily the service restoration timestamp.
Use distributions, sample sizes, and context. A dashboard comparing two months should state whether team scope, workflow, and incident definitions stayed comparable.
Configure a useful Azure view
With appropriate Analytics and dashboard access, select the team’s area and relevant work-item types, add lead-time/cycle-time widgets, and configure a time window. Use a cumulative flow view for the same population where possible.
Inspect an actual long-duration item and compare its state history with the chart. The scatter plot can aggregate multiple items at a point; do not assume one visible dot always represents exactly one work item.
Add a short definition and data-freshness note. A chart without population or clock boundaries is easy to misread.
GitHub Insights and Projects charts
Repository Insights provides views such as Pulse, contributor activity, commits, code frequency, and traffic, subject to permissions, plan, repository size, and feature availability. Pulse summarizes activity; traffic reports visits/clones over its documented period. Neither automatically measures customer impact or service recovery.
GitHub Projects charts can summarize project items by supported fields and filters. Create a chart with an explicit project population, grouping, and intended question. Check that project items actually carry the needed fields and statuses.
A useful workflow might show open items by status or priority, while a repository view shows merged PR activity. Do not combine counts from different populations into a made-up “productivity score.”
Put evidence behind an AI summary
An assistant can summarize “review WIP rose” and retrieve the associated items through approved tools. Ask for the exact filter, dates, source links, and competing explanations. If a team changed its board mapping last week, that may explain a shape change without any real slowdown.
Avoid publishing individual rankings from commit counts. Pairing, review work, operational response, and task difficulty are not captured by that number.
A cycle-time chart improves while customers still wait a long time before work starts. Which measure would expose that earlier waiting?
Try it: explain one slow item
Prerequisites: read access to a sandbox Boards dashboard or GitHub Project. Creating charts requires the corresponding permission; no Azure deployment is needed.
Create or inspect a chart for one explicit population. Choose one delayed item and trace its history. Identify time waiting before work, time active, and time blocked if evidence exists. In GitHub, inspect a Project chart and a repository activity view, then state why their counts differ.
Expected observation: you can connect the visualization to underlying records and name at least one thing it does not measure.
Cleanup: delete only the exercise chart/widget if you created it. Do not change real work-item states just to improve the report.
Decision check: the review band widened
Inspect arrivals, completions, blocked items, and workflow changes. A widened band is a signal to investigate, not proof that reviewers caused the delay.