Interpreting sprint metrics and turning them into a conversation your team can act on takes experience and time. Agile Analytics does the arithmetic for you: it reads your sprint history from Azure DevOps and produces a retrospective-ready snapshot, a set of delivery signals, and scheduled alerts — all computed from your own numbers.
How the insights are generated
Every figure and observation described below is computed deterministically from your Azure DevOps state history — the same inputs always produce the same output, and no language model is involved at any point. Where Agile Analytics does use AI is a separate feature set: AI Metrics and the AI Improvement & Intervention Panel, which measure GitHub Copilot adoption across your teams rather than analysing your sprints.
What the Retro Snapshot contains
Open Retro Snapshot, choose a team and a sprint, and you get a structured document you can take straight into the retrospective:
- Delivery Summary — committed vs delivered item counts, commitment reliability %, and carryover count and percentage
- Scope — scope churn %, items added mid-sprint, and items removed
- Flow — throughput, cycle time p50 and p85, and lead time p50
- Velocity Context — the six-sprint average and whether the trend is rising, falling or flat
- Team Insights — observations drawn from those same numbers
Getting it out of the tool
The snapshot is built to leave the extension, because the retro rarely happens inside Azure DevOps:
- Copy as Markdown — paste straight into a wiki page or retro board
- Download as PNG — drop the image into slides or a chat thread
- Share to Microsoft Teams or Slack — posts to a webhook you configure
Background Monitor and Alerts
The Background Monitor is a scheduled Azure Pipeline you run in your own organisation. Download the generated YAML from Configuration, add it to a repo in your project, and it checks your WIP limits on a schedule — every 3, 6 or 12 hours, or once each weekday morning — and posts to a Microsoft Teams or Slack webhook you supply. Separately, seven notification triggers fire across three groups:
- Sprint Health: Commitment Reliability Low, Scope Churn Exceeded, Carryover Risk, Sprint End Summary
- Flow & WIP: WIP Over Limit, Stale In-Progress Items
- Digest: Weekly Sprint Digest
Where the numbers come from
Every figure above is read from the Azure DevOps REST API and computed in your browser. Work item content, project and team names, and user names and email addresses never leave your Azure DevOps tenant. What is sent to Baytek is your organisation ID, to confirm your subscription, plus usage and error telemetry — the in-product Data & Privacy page lists exactly what those contain and where to switch usage telemetry off.
Getting the most out of it
A few habits that make the snapshot more useful:
- Keep work item states up to date — every number here is only as good as the state history it reads
- Confirm your Workflow Mapping first: cycle time and flow figures depend on which states you count as active work
- Use the snapshot as the first agenda item in the retro — it removes 10–15 minutes of manual metric gathering
- Read three consecutive sprints together; a single sprint rarely separates a real shift from normal variation
- For that question specifically, the Process Behavior chart states in a sentence whether a change is a genuine signal or routine noise