You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can query for data about how thoroughly a particular test run covered the code that it was intended to test by using FactRunCoverage and the associated dimensions.
18
-
19
-
For information about the measures and dimensions that are associated with these tables in the SQL Server Analysis Services cube, see [Code churn and code coverage](perspective-code-analyze-report-code-churn-coverage.md).
18
+
Use FactRunCoverage and the associated dimensions to query for data. Find out how thoroughly a particular test run covered the code that it was intended to test.
19
+
20
+
For information about the measures and dimensions that are associated with these tables in the SQL Server Analysis Services cube, see [Code churn and code coverage](perspective-code-analyze-report-code-churn-coverage.md).
20
21
21
-
![Fact Table for Run Coverage](media/teamproj_factruncoverage.png"TeamProj_FactRunCoverage")
22
+
![Fact Table for Run Coverage](media/teamproj_factruncoverage.png"TeamProj_FactRunCoverage")
22
23
23
24
> [!NOTE]
24
25
> You cannot aggregate these coverage values to determine code coverage for a build. To determine the code coverage in a build, you must use FactBuildCoverage. For more information, see [Build Coverage tables](table-reference-build-coverage.md).
25
26
26
-
FactRunCoverage is associated with the following dimension tables:
27
+
FactRunCoverage is associated with the following dimension tables:
27
28
28
-
-DimAssembly
29
-
-DimBuild
30
-
-DimBuildFlavor
31
-
-DimBuildPlatform
32
-
-DimDate
33
-
-DimPerson
34
-
-DimTestRun
29
+
- DimAssembly
30
+
- DimBuild
31
+
- DimBuildFlavor
32
+
- DimBuildPlatform
33
+
- DimDate
34
+
- DimPerson
35
+
- DimTestRun
35
36
36
-
## Related articles
37
-
-[Code churn and code coverage](perspective-code-analyze-report-code-churn-coverage.md)
You can report data from across team project collections because all reportable data in a deployment of Team Foundation is written to the SQL Server Analysis Services cube for Visual Studio Team Foundation Server. You can use the Team Project dimension to show the data for only those team projects that you specify. You can use the Date dimension to create trend reports that show changes over a day, a week, a month, or a year. All perspectives in the cube share these dimensions.
16
+
You can report data from across team project collections because all reportable data in a deployment of Azure DevOps is written to the SQL Server Analysis Services cube for Azure DevOps Server. Use the Team Project dimension to show the data for only those team projects that you specify. Also, use the Date dimension to create trend reports that show changes over a day, a week, a month, or a year. All perspectives in the cube share these dimensions.
18
17
19
-
You can use dimension attributes to summarize the measures in the cube according to various categories. For example, you can use the Priority, Work Item Type, State, Closed By, and Closed Date attributes to determine how many priority one bugs were closed by a specific team member in November.
18
+
You can use dimension attributes to summarize the measures in the cube according to various categories. For example, you can use the Priority, Work Item Type, State, Closed By, and Closed Date attributes to determine how many priority one bugs were closed by a specific team member in November.
20
19
21
20
## <aname="team_project"></a> Filter Reports or Mine Data Based on Project Collections and Team Projects
22
-
You can use the Team Project dimension to filter a report or highlight specific details of a project collection or team project. All measures and dimensions in the Team System cube record data that is specific to a team project and project collection. The following illustration shows the attributes within the Team Project dimension as it appears in the Report Builder Query Designer. The Team Project Hierarchy node contains two hierarchical attributes, the first at the collection level and the second at the team-project level.
21
+
22
+
You can use the Team Project dimension to filter a report or highlight specific details of a project collection or team project. All measures and dimensions in the Team System cube record data that is specific to a team project and project collection. The following illustration shows the attributes within the Team Project dimension as it appears in the Report Builder Query Designer. The Team Project Hierarchy node contains two hierarchical attributes, the first at the collection level and the second at the team-project level.
You can filter the report to the team projects of interest by specifying one or more of the attributes in the following table.
26
+
You can filter the report to the team projects of interest by specifying one or more of the attributes in the following table:
27
27
28
28
|Attribute|Description|
29
29
|---------------|-----------------|
@@ -34,17 +34,32 @@ You can report data from across team project collections because all reportable
34
34
|Project Path|A flat list of team project paths that start with the project collection.|
35
35
36
36
## <aname="date_dimension"></a> Create and Filter Trend Reports
37
-
By using the Date dimension, you can create trend reports that summarize changes that occur over time to work items, builds, tests, and files in version control. Reports that include the Date dimension show information for the specific day on which an action occurred. All information in the data warehouse is tracked as it appeared at the end of each day.
37
+
38
+
By using the Date dimension, you can create trend reports that summarize changes that occur over time to these items in version control:
39
+
- Work items
40
+
- Builds
41
+
- Tests
42
+
- Files
43
+
44
+
Reports that include the Date dimension show information for the specific day on which an action occurred. All information in the data warehouse is tracked as it appeared at the end of each day.
38
45
39
46
> [!NOTE]
40
47
> The dates in the Date dimension are stored according to the date that is set for the application-tier server that runs the warehouse adapters that move data from the data stores to the relational warehouse database. Dates are not adjusted based on time zone.
41
48
42
-
![Date Dimension](media/alm_rpt_date_dimension.png"ALM_RPT_Date_Dimension")<br />You can use date dimension hierarchies to aggregate values by day, week, month, or year. For example, you can compare the percentage of opened versus closed bugs from one month to another.<br /><br /> The first two attributes, **Year Month Date** and **Year Week Date**, correspond to hierarchical tree filters. The first hierarchy, as the following illustration shows, supports filtering by month. The second hierarchy supports filtering by week.<br /><br />
You can use date dimension hierarchies to aggregate values by day, week, month, or year. For example, you can compare the percentage of opened versus closed bugs from one month to another.
52
+
53
+
The first two attributes, **Year Month Date** and **Year Week Date**, correspond to hierarchical tree filters. The first hierarchy, as the following illustration shows, supports filtering by month. The second hierarchy supports filtering by week.
<br /><br /> Under **More fields**, you can specify the granularity of the time axis for displaying trend reports as **Date**, **Month**, **Week**, or **Year**.<br /><br /> You can use the Date hierarchy with the **Year Month Day** attribute to aggregate measures by year, month, and the day of the month.<br /><br /> You can use the Date hierarchy with the **Year Week Day** attribute to aggregate measures by year, week of year, and the day of the week.
57
+
Under **More fields**, you can specify the granularity of the time axis for displaying trend reports as **Date**, **Month**, **Week**, or **Year**.
58
+
59
+
You can use the Date hierarchy with the **Year Month Day** attribute to aggregate measures by year, month, and the day of the month.
60
+
61
+
You can use the Date hierarchy with the **Year Week Day** attribute to aggregate measures by year, week of year, and the day of the week.
47
62
48
63
## Related articles
49
64
50
-
-[Perspectives and measure groups provided in the Analysis Services cube](perspective-measure-groups-cube.md)
65
+
-[Perspectives and measure groups provided in the Analysis Services cube](perspective-measure-groups-cube.md)
By reviewing a sprint burndown report, you can track how much work remains in a sprint backlog, understand how quickly your team has completed tasks, and predict when your team will achieve the goal or goals of the sprint.
18
-
19
-
This report is very similar to the report available from your team backlog page. The sprint burndown report is built from data in the Analysis Services cube, and the team burndown chart references the WIT data store in real time.
17
+
By reviewing a sprint burndown report, you can:
18
+
- Track how much work remains in a sprint backlog.
19
+
- Understand how quickly your team has completed tasks.
20
+
- Predict when your team will achieve the goal or goals of the sprint.
21
+
22
+
This report is similar to the report available from your team backlog page. The sprint burndown report is built from data in the Analysis Services cube, and the team burndown chart references the WIT data store in real time.
20
23
21
24
## Requirements
22
25
23
-
-The on-premises Team Foundation Server (TFS) deployment and the team project collection that contains your team project are configured with SQL Server Reporting Services. This report is not available if ![Report](media/icon_reportte.png"Icon_reportTE")**Reports**does not appear when you open Team Explorer and expand your team project node.
26
+
- The on-premises Azure DevOps Server deployment and the team project collection that contains your team project are configured with SQL Server Reporting Services. This report isn't available if ![Report](media/icon_reportte.png"Icon_reportTE")**Reports**doesn't appear when you open Team Explorer and expand your team project node.
24
27
25
28
If you need to add reporting services to your deployment or reports for a team project, see [Add reports to a team project](../admin/add-reports-to-a-team-project.md).
26
29
27
-
-To view the report, you must be assigned or belong to a group that has been assigned the **Browser** role in SQL Server Reporting Services. For more information, see [Grant permissions to view or create reports in TFS](../admin/grant-permissions-to-reports.md).
30
+
- To view the report, you must be assigned or belong to a group that has been assigned the **Browser** role in SQL Server Reporting Services. For more information, see [Grant permissions to view or create reports in Azure DevOps Server](../admin/grant-permissions-to-reports.md).
28
31
29
32
30
33
<aname="Data"></a>
31
34
32
35
## Data in the report
33
36
34
-
A sprint burndown report shows how much work remained at the end of specified intervals during a sprint. The source of the raw data is the sprint backlog. The horizontal axis shows days in a sprint, and the vertical axis measures the amount of work that remains to complete the tasks in the sprint. The work that remains is shown in hours.
37
+
A sprint burndown report shows how much work remained at the end of specified intervals during a sprint. The source of the raw data is the sprint backlog. The horizontal axis shows days in a sprint. The vertical axis measures the amount of work that remains to complete the tasks in the sprint. The work that remains is shown in hours.
35
38
36
-
A sprint burndown graph displays the following pieces of data:
39
+
A sprint burndown graph displays the following pieces of data:
37
40
38
41
- The Ideal Trend line indicates an ideal situation in which the team burns down all of the effort that remains at a constant rate by the end of the sprint. The line is drawn from the total remaining work on the sprint start date to intersect the x-axis on the sprint end date.
39
42
@@ -50,30 +53,34 @@ By reviewing a sprint burndown report, you can track how much work remains in a
50
53
You can filter the report by selecting the **Iteration** or **Area**.
51
54
52
55
### Required activities to support the sprint burndown report
53
-
For the burndown report to be useful and accurate, your team must perform the following activities for tracking tasks:
56
+
57
+
For the burndown report to be useful and correct, your team must carry out the following activities for tracking tasks:
54
58
55
-
-[Define sprints](../../boards/sprints/define-sprints.md) for your team.
59
+
-[Define sprints](../../boards/sprints/define-sprints.md) for your team.
56
60
57
-
-[Define tasks for each product backlog item](../../boards/sprints/assign-work-sprint.md) you're working on within the sprint. If you work from your team's backlog and task board, the items you create will automatically be assigned to the current sprint (**Iteration**) and to your team's default **Area** path.
61
+
-[Define tasks for each product backlog item](../../boards/sprints/assign-work-sprint.md) you're working on within the sprint. If you work from your team's backlog and task board, the items you create will automatically be assigned to the current sprint (**Iteration**) and to your team's default **Area** path.
58
62
59
-
-Specify and update the **Remaining Work** field for each task or subtask as it is worked on.
63
+
- Specify and update the **Remaining Work** field for each task or subtask as it is worked on.
60
64
61
65
> [!IMPORTANT]
62
66
> If you divide a task into subtasks, specify hours only for the subtasks. These hours are rolled up as summary values for the parent task. For more information, see [Address inaccuracies published for summary values](address-inaccuracies-published-for-summary-values.md).
63
67
64
68
- Update the **State** of each task as it progresses from **To Do** to **Done**.
65
69
66
-
## <aname="Interpreting"></a> Interpreting the report
67
-
You can review the report to determine the progress that your team has made in a release and answer the following questions:
70
+
## <aname="Interpreting"></a> Interpret the report
71
+
72
+
You can review the report to determine the progress that your team has made in a release and answer the following questions:
68
73
69
-
-How much work remains in the sprint?
74
+
- How much work remains in the sprint?
70
75
71
-
-Is your team on track to finish all work for the sprint?
76
+
- Is your team on track to finish all work for the sprint?
72
77
73
-
-When will your team finish all work for the sprint?
78
+
- When will your team finish all work for the sprint?
[Define area paths](../../organizations/settings/set-area-paths.md) or [Define iteration paths](../../organizations/settings/set-iteration-paths-sprints.md)
0 commit comments