When a manager asks for a sprint report from Azure DevOps, the standard answer is Power BI. It is a sensible answer. Power BI can model almost anything in your Azure DevOps data, join it with other sources, and publish it to people who never open Azure DevOps. It also asks you to run a small data project: connect to the Analytics service, choose credentials, schedule a refresh, and keep all of it working. For a team that only wants a trustworthy sprint report, that is a lot of upkeep. This post lays out what the Power BI route involves, where it is the right tool, and when a simpler option is enough.
What the Power BI route involves
Power BI reads Azure DevOps through the Analytics service, either through the Power BI Data Connector with Analytics views or through an OData feed. A working report has a few moving parts.
- A data source. You pick an Analytics view or write an OData query. Microsoft documents both, and the query language takes some learning if you want anything beyond the defaults.
- Credentials. Microsoft recommends signing in with Microsoft Entra ID (OAuth2), and documents a personal access token as an option you should use only when other methods are not available.
- A published dataset with a refresh schedule. Scheduled refresh runs inside the Power BI service, and Microsoft notes a refresh can start up to an hour late.
- Someone to own it. If a credential expires or a query breaks, the report stops updating, often without anyone noticing until the numbers look old.
Related: Microsoft Learn: Client authentication options · Microsoft Learn: Publish a Power BI Desktop file
The friction people describe
Public forums are full of people who got a first report working and then hit the upkeep. A few themes come up again and again.
- Credentials tied to a person. One public question explains that a personal access token “is tied to a user”, which is not what you want behind a report the whole team relies on. Microsoft documents the same thing: a PAT identifies the person who created it, and when it expires the report stops updating with fresh data while still showing old data.
- Refresh that quietly fails. A scheduled refresh depends on the credential, the service and the query all behaving. When one does not, the symptom is a stale chart, not an error someone sees.
- History at the wrong grain. One public feature request notes that the analytics view “only shows the latest status within a day”, which matters if you want every state change.
- Building the chart yourself. Public threads about recreating a burndown in Power BI show how much modelling a basic sprint chart can take.
Related: Public question: credentials tied to a user · Public feature request: state changes within a day · Microsoft Learn: Use personal access tokens
None of this makes Power BI a bad choice. It means the cost is ongoing, and it is paid by whoever built the report. There is also a permissions point worth knowing. Microsoft notes that data included in an Analytics view and published to Power BI is visible to everyone with access to the report, regardless of the project permissions in Azure DevOps. If that is a concern, plan the sharing deliberately.
When Power BI is the right answer
Be honest about what you need before you replace it. Power BI is the better tool when:
- You need to combine Azure DevOps data with other sources, such as finance, support or HR data.
- You want custom measures and visuals that no pre-built view offers.
- Your organisation already has a BI team, a Power BI tenant and the governance around it.
- You report to people who only ever open Power BI.
Related: Built-in reporting vs Power BI vs extensions · Azure DevOps Analytics vs Power BI
When an extension in the browser is enough
If your need is a clear sprint report, sprint health and delivery trends for the teams in your own Azure DevOps organisation, there is a shorter path. Agile Analytics is an Azure DevOps extension. Its views run in the browser against the Azure DevOps REST API, using the session of the person who is signed in. That removes most of the chain above.
- No Power BI, no Analytics views and no OData to write.
- No personal access token, so there is no credential to expire and no one whose departure breaks the report.
- No refresh schedule. The views load current data when someone opens them.
- No Azure Function, database or service connection to keep alive.
- Four read-only scopes: vso.project, vso.work, vso.graph and vso.build. The extension cannot change work items, and work item content is not sent to a Baytek server.
For sprint reporting specifically, the relevant views are Sprint Summary, which gives a per-team sprint baseline with commitment reliability, scope churn, carryover, planned work and bugs, with CSV export, and Delivery Signals, which shows commitment reliability, carryover trend and time to start across past sprints. The Dashboard can also carry a Sprint Burnup tile for the active sprint. For leadership, the Exec Report is a one-page summary built in the browser that you can share as a PDF, a copied summary or copied email text, and it sends nothing to Baytek.
Related: Azure DevOps sprint reporting · Azure DevOps analytics without a PAT · What belongs on a sprint health dashboard
Trade-offs to be clear about
A pre-built extension is faster to start and cheaper to keep running, and it is less flexible than a model you build yourself.
- You get the views the extension provides. It is not a general data model, so if you need to join Azure DevOps data with other systems, Power BI remains the better fit.
- It supports Azure DevOps Services (cloud) only, not Azure DevOps Server.
- People need Project Contributor access or higher to use it, and, after the trial, a seat on the plan for full access (people without a seat still see the Dashboard).
- It is a paid product after a 30-day trial, so compare that against the time you spend maintaining reports.
Questions teams ask
Short answers to the most common follow-ups.
Related: Data and privacy
Does Power BI for Azure DevOps require a PAT?
No. Microsoft recommends Microsoft Entra ID (OAuth2) and lists a PAT as an option for when nothing else is available. The upkeep concern applies to a PAT in particular, because it expires and has to be rotated by hand.
Can I run both?
Yes. Many teams use an extension for day-to-day sprint views and keep Power BI for the cross-system reports that need a data model.
Does the extension send my work items to Baytek?
No. Work item content such as titles, sprint contents and comments stays in the browser and Azure DevOps. Baytek receives licence and usage records, which the privacy page lists in full.
Try it on your own sprints
The extension installs from the Visual Studio Marketplace and starts a 30-day trial on install, with no credit card. During the trial everyone in the organisation has full access, so you can open Sprint Summary on a real sprint and judge whether it covers what your report needs. See the pricing page for plans after the trial.
Related: Pricing · Install guide