For most Azure DevOps Services teams that want sprint and flow metrics, an extension takes the least total effort, because the hard part is getting state mapping, history and sprint moves right, not drawing charts. Build on the REST API when your definitions are unusual or the data must land in your own warehouse, and use Power BI when you already run it and need Azure DevOps data next to other business data.
The three options side by side
Each option moves the same work to a different place.
| Factor | Build on the REST API | Power BI | Buy an extension |
|---|---|---|---|
| Effort to start | High: queries, history handling, definitions and a front end | Medium: connect, model the data, build visuals | Low: install and confirm how your workflow states map |
| Upkeep | Ongoing: process changes, API changes and bug reports land on you | Ongoing: refreshes, model changes, report access | Mostly the vendor: you keep the mapping current |
| Who maintains it | Your engineers, usually whoever wrote it | A BI developer or analyst | The vendor, plus an admin who owns the mapping |
| Good at | Exact in-house definitions, feeding a warehouse | Joining Azure DevOps data with other business data | Standard sprint, flow and forecast metrics inside Azure DevOps |
What is hard about these metrics
The charts are the easy part. Three problems take most of the time in a homegrown report, and they are why two reports on the same project often disagree.
Related: One worked example: our carryover rule · Workflow Mapping for accurate analytics
Workflow state mapping
Teams rename and add states. Done might be Closed, Resolved or a custom Ready to Release. Cycle time depends on which state stops the clock, so any approach needs a maintained, per-team answer to which states are in progress and which one means done.
History at a past date
A query tells you what is true now. "What was in the sprint on day three" needs each item's revision history replayed to that date. That is where homegrown reports quietly take a shortcut, and it shows up as wrong carryover, wrong WIP and wrong aging.
Sprint moves
Items get pulled in late, pushed back to the backlog, moved to the next sprint, or added and removed by mistake. Each case needs a rule, written down and applied the same way everywhere.
When building is the right answer
Building is a sound choice in these cases. Budget for upkeep, not only the first version.
- Your definitions are specific to your organisation and nothing off the shelf matches them.
- The data has to flow into an internal warehouse or a system you own.
- You run Azure DevOps Server on-premises. Agile Analytics supports Azure DevOps Services only.
- You need one roll-up across several Azure DevOps organisations. Agile Analytics reads the organisation you are signed in to, and each organisation installs it separately.
When Power BI is the right answer
Power BI fits when your company already uses it, a BI team supports it, and leaders want delivery data in the same model as finance, CRM or support data. It also fits when reporting has to follow central BI governance.
Related: Agile Analytics vs Power BI
Is Power BI worth it just for sprint reports?
If sprint and flow reports are the only goal, usually not. You still have to solve state mapping, history and sprint moves inside the model, and someone has to keep the refresh and the visuals working.
What an extension removes
Agile Analytics adds a hub under Boards with 30+ views, including Sprint Summary, Cycle Time, Monte Carlo, Flow Metrics and an Exec Report.
- Infrastructure. No Power BI, Analytics views, personal access token, Azure Function, database or service connection. Views run in your browser with your existing session.
- Access risk. Four read-only scopes, and it cannot modify work items. Work-item content is never sent to Baytek.
- Mapping from scratch. It works with Agile, Scrum, CMMI, Basic and custom inherited processes. Setup reads your project's states, and an admin can check each one.
- Sprint rules. One documented carryover rule across Sprint Summary, Dashboard, Delivery Signals and Exec Report.
Related: Azure DevOps analytics without a PAT
What it does not remove
Someone still owns the workflow mapping, and if you need data elsewhere you export it, with CSV, PNG and Markdown exports available.
Cost for a small team
We do not put hour estimates on a build, because they depend too much on your team. The useful comparison is who carries the upkeep: a build or a Power BI model is a permanent internal cost. Agile Analytics is a 30-day free trial, then from $300 a year per organisation, with every feature on every plan. If all you need is a next-sprint forecast, the separate, free Monte Carlo Sprint Forecast extension adds a tile to a dashboard, with no account, trial or licence key.
Related: Pricing
Try it
The trial starts when you install, with no credit card, and everyone in the organisation has full access while it runs. Compare its numbers with whatever you use today.
Related: Install instructions