다음을 통해 공유

Permissions and prerequisites to access Analytics in Azure DevOps

  • 아티클

Azure DevOps Server 2019

To work with Analytics and create reports, several prerequisites must be met as summarized in this article.

By default, all project members are provided access to Analytics data for the projects they are members of, including members added to the project Readers group. Users with Stakeholder access have no access to view or edit Analytics views.

Service and feature enablement

In general, Analytics is always on and available to members of an organization or collection to view data and create report.

Analytics service

For Azure DevOps Server 2019, you must first install Analytics on each project collection you create.

You can pause and restart the service. When paused, no new data is added to Analytics.

For more information, see Install or enable the Analytics service.

Azure DevOps services

To exercise any Azure DevOps service, it must be enabled. No data can be captured for a service that has been disabled. Services can be enabled or disabled on a project by project basis.

To verify that all services are enabled, see Turn a service on or off.

Analytics views

Analytics views, a hub in your web portal, provides a simplified way to specify the filter criteria for a Power BI report based on the Analytics data. For more information, see What is the Analytics Service?

To access Analytics views, have it enabled. The organization owner or member of the Project Collection Administrators group can enable it for everyone in the organization. Or, each project member can enable it for themselves.

To learn how, see Manage or enable features.

Permissions

You set permissions for the service at the project level, and for shared Analytics views at the object level.

The following table summarizes the permissions available to be set and the default assignments made to the project security groups.

Permission Readers Contributors Project Administrators
View Analytics ✔️ ✔️ ✔️
View a shared Analytics view ✔️ ✔️
Add a private or shared Analytics view ✔️ ✔️
Edit and delete shared Analytics views ✔️

Data tracking prerequisites

To capture meaningful data, software teams must perform meaningful actions. The following sections provide general recommendations based on the type of data you want to report on.

Azure Boards and work tracking

For a review of available entity sets that you can query, see Metadata reference for Azure Boards Analytics.

To report on work tracking, teams need to perform several tasks to ensure meaningful data is available. Review the following tasks prior to defining your Analytics queries and reports.

  • To report on active bugs or bug trends, define bugs and update the bug State as it is fixed, verified, and then closed.
  • To report on backlog work or other work item types, make sure you define those work items, and update their State as it moves from new to closed. Consider whatever fields or tags you'll use to filter or group data in a report and make sure that is well defined and consistent.
  • To support rollup reports, ensure parent-child links exist between product backlog items and tasks/bugs, or parent-child links exist between features or portfolio backlog work items and their child items. For more information, see Organize your backlog and map child work items to parents.
  • To create burndown or burnup reports, such as Sprint burndown or Release burndown, ensure you have thought through how you want to filter and group data in your report. Burndown/burnup reports reference the WorkItemsSnapshot entity set. Snapshot entity sets are modeled as daily snapshots. Data is aggregated based on assignments made as of the date they are assigned. What this means is that to filter a burndown/burnup report based on field or tag assignments, you must assign the fields or tags prior to the period you want to report on. Otherwise, the fields/tags aren't registered by the report until the date on which they are applied.
  • To support Requirements tracking, define test cases, and create a Tested By link from each test case to a user story, product backlog item, or requirement. Define test cases and link test cases to their parent PBIs using the Tested By link. See Create your tests.
  • (Recommended) To support filtering and grouping within a report, assign Area Path and Iteration Path to all work items. For information about how to define iteration and area paths, see Define area paths and assign to a team or Define iteration paths (sprints) and configure team iterations.

Note

All custom fields added to a work item type are available for use in reports. Custom fields are labeled with Custom_DisplayNameOfField, where all spaces have been removed from the display name.