Perspectives and Matrices in TFS

Perspectives and Matrices that can be collected by them in TFS

Build Perspective

Describes the Build perspective, which provides metrics regarding builds such as build time and

build frequency and which can be analyzed by various dimensions such as who performed the

build, the build type, the build flavor, the build outcome, and so forth.

Code Churn Perspective

Describes the Code Churn perspective, which provides metrics about the number of file versions

stored in Team Foundation source control. This perspective tracks the total number of lines of

code and number of files, as well as how many lines of code were changed, added, or deleted.

These totals can be analyzed by file directory, build, or the team member doing check-ins. All

totals can be analyzed over time, so you can answer questions such as “How many lines of code

in .cs files have changed between two builds?"

Code Coverage Perspective

Describes the Code Coverage perspective, which provides metrics about how many lines and

blocks of code were tested in various build and run configurations.

Current Work Item Perspective

Describes the Current Work Item perspective, which provides metrics regarding the current state

of work items. You can use this perspective to answer questions such as "How many active tasks

are assigned to each person?"

Load Test Perspective

Describes the Load Test perspective, which provides metrics regarding tests run under simulated

load. This perspective enables counters gathered during the load test to be trended and analyzed

over time.

Test Results Perspective

Describes the Test Results perspective, which provides metrics about test runs and test results.

Test results are tracked over time and can be analyzed by their outcome, which build they were

testing, the type of test, and other dimensions.

Work Item History Perspective

Describes the Work Items perspective, which provides metrics and detailed information about

work items (for example, Bugs or Issues), including historical information that enables total work

item counts to be analyzed over time or as of a current date. You can use this perspective to

answer questions such as “How many active and resolved bugs were there on each day during an

iteration?”

Build Perspective

You can use the Build perspective to view just the measures, attributes, and calculations in the data cube

that pertain to the build process.

Measures

The following table describes the measures that are included in the Build perspective.

Measure Measure Group Description

Build Count Build Number of times a build has been run.

Build Duration Build Number of minutes it took for the build to finish.

Build URL Build The uniform resource locator (URL) for the completed build. A URL specifies the protocol that will be used by Web browsers to locate Internet resources and includes the name of the server on which the resource resides, and, optionally, the path to a resource.

Build Project Count Build Project Number of times the team project has been built.

Compile Errors Build Project Number of compile errors for the selected builds.

Compile Warnings Build Project Number of compile warnings for the selected builds.

Static Analysis Errors Build Project Number of static analysis errors for the selected builds.

Static Analysis Warnings Build Project Number of static analysis warnings for the selected builds.

Dimensions

The following table describes the attributes that are included in the Build perspective.

You can aggregate the measures along each of these attributes.

Attribute Dimension Description

Build Build Number or name used to uniquely identify the build.

Build Start Time Build Date and time the build began.

Build Type Build Name of the build type set in the New Team Build Type Creation Wizard. Selected from the Team Builds node in Team Explorer.

Build Quality Build Quality The current quality of the build. The possible values are controlled by the process template. Set manually by the user in the Team Build Browser.

Build Status Build Status The updated status as the build proceeds. The possible values are as follows:

Build Initializing

Getting Sources

Compilation Started

Compilation Completed

Testing Started

Testing Completed

Successfully Completed

Failed

Stopped

Date Date The day component of the local time zone setting of the

computer. Does not include the hour, minute, and second components.

Build Flavor Flavor The configuration of the build. The possible values include the following:

Debug

Release

Any valid configuration created by the process

template.

Set in the New Team Build Type Creation Wizard.

Platform Platform The platform for which the build was made. The possible values include the following:

X86

X64

Itanium

Win32

Any CPU

.NET

Mixed Platforms

Any valid platform created by the process

template.

File Extension Source Project The file name extension of the source file being built. Set in the New Team Build Type Creation Wizard.

File Path Source Project The file name (without extension) of the source file being built.Set in the New Team Build Type Creation Wizard.

Team Project Team Project The name of the team project which built using the specified build type. This is set in the New Team Project Wizard at the time the team project is created.

To Top

Code Churn Perspective

You can use the Code Churn perspective to view just the measures, attributes, and calculations in the data

cube that pertain to the Team Foundation Build process. The Code Churn perspective helps you analyze

how source files are changing over time and across builds.

You can use the Code Churn perspective to answer questions such as:

How many files of a specific file name extension changed in a particular build?

How many lines of code are in the source base for a particular build?

Which change sets have been submitted, and the details of each change (for example, who

performed the change, what files were modified, and the date the change was made).

Measures

The following table describes the measures that are included in the Code Churn

perspective. The Code Churn perspective contains a single measure group named Code

Churn. A new fact is added to this measure for each file change referenced by a check-in

action in the version control system.

Measure Description

Code Churn Count The number of times that changes were made to files in the version control system.

Lines Added Lines added to files for the selected dimensions.

Lines Deleted Total number of deleted lines.

Lines Modified Total number of changed lines in the time period selected.

Total Churn Total churn in the code, computed as: [Lines Added] + [Lines Deleted] + [Lines Modified].

Total Lines Total number of lines in the selected part of the file path hierarchy at the point of a specific build or across a set of builds. This calculation only returns information for builds, and will return NULL when you use it without selecting individual builds. The number of lines is calculated by aggregating the lines added and lines deleted that have contributed to a specific build type/operating system combination.

Dimensions

The following table describes the attributes that are included in the Build perspective.

You can aggregate the measures along each of these attributes.




Build Type Build Name of the build type. Set in the New Team Build Type Creation Wizard. Selected from the Team Builds node in Team Explorer.

Changeset Changeset The check-in comment associated with the changeset.

Changeset ID Changeset The Changeset Name or ID which included the

file changes.

Alias Checked In By The alias of the person checking in the code modifications.

Person Checked In By The user name of the person checking in the code modifications.

Year Month Date Date The date on which the changeset was submitted organized by year, month and date.

Year Week Date Date The date on which the changeset was submitted organized by year, week of the year and date.

Date Date The date on which the changeset was submitted.

File Extension Filename The type of file (file name extension) for which the changes were made.

File Path Filename A hierarchy of the directories and files in the source control database.

Team Project Team Project The name of the team project.

ID Work Item The work item's ID, as assigned when the work item was created.

Previous State Work Item The previous state of the work item.

Work Item Type Work Item The type of the work item.

Reason Work Item The reason that the state of the work item changed.

Rev Work Item The revision of the work item.

State Work Item The state of the work item.

Title Work Item The title of the work item.

(other) Work Item Other attributes depending on the process template used to create the team project.

To Top

Code Coverage Perspective

You can use the Code Coverage perspective to analyze the code coverage results from builds and test

runs. You can use the code coverage perspective to answer the following types of questions:

Which assemblies and projects have the lowest code coverage?

Which test runs give you the most code coverage?

Which builds have the highest code coverage?

Which architectures or build types have the highest code coverage?

Measures

The following table describes the measures that are included in the Code Coverage

perspective. This perspective contains two measure groups: Build Coverage, and Run

Coverage. The Build Coverage measures should always be used to analyze numbers

summarized by build. The measures in the build coverage measure group do not

aggregate across multiple builds to return meaningful numbers. For example, if 100 lines

are covered in build 1, and 100 lines are covered in build 2, the total coverage may be far

less than 200. The same is true for using run coverage that only returns meaningful

numbers when filtered or summarized by a test run.


Count Code Coverage from Build

The number of builds that have code coverage statistics associated with them.

Lines Covered Code Coverage from Build

The number of lines covered in the selected build. If multiple runs are performed against a build, the build coverage reflects the combined coverage of the runs, taking into consideration that there may be overlap in the lines covered across the runs.

Lines Not Covered Code Coverage from Build

The number of lines not covered in the selected build. If multiple runs are performed against a build, the build coverage reflects the combined coverage of the runs, taking into consideration that there may be overlap in the lines covered across the runs.

Lines Partially Covered Code Coverage from Build

The number of lines partially covered in the selected build. If multiple runs are performed against a build, the build coverage reflects the combined coverage of the runs, taking into consideration that there may be overlap in the lines covered across the runs.

Blocks Covered Code Coverage from Build

The number of blocks covered in the selected build. If multiple runs are performed against a build, the build coverage reflects the combined coverage of the runs, taking into consideration that there may be overlap in the blocks covered across the runs.

Blocks Not Covered Code Coverage from Build

The number of blocks not covered in the selected build. If multiple runs are performed against a build, the build coverage reflects the combined coverage of the runs, taking into consideration that there may be overlap in the blocks covered across the runs.

Count Code Coverage from Run

The number of test runs that have code coverage statistics associated with them.

Lines Covered Code Coverage from Run

The number of lines covered by all tests in a run, taking into consideration that there may be overlap in the coverage across the tests.

Lines Not Covered Code Coverage from Run

The number of lines not covered by all tests in a run, taking into consideration that there may be overlap in the coverage across the tests.

Lines Partially Covered Code Coverage from Run

The number of lines partially covered by all tests in a run, taking into consideration that there may be overlap in the coverage across the tests.

Blocks Covered Code Coverage from Run

The number of blocks covered by all tests in a run, taking into consideration that there may be overlap in the coverage across the tests.

Blocks Not Covered Code Coverage from Run

The number of blocks not covered by all tests in a run, taking into consideration that there may be overlap in the coverage across the tests.

Dimensions

The following table describes the attributes that are included in the Code Coverage from

the Build perspective. You can aggregate the measures along each of these attributes.


Date Date The date on which the Run or Build coverage statistics were collected. This dimension should be used together with builds or runs to show the date of a specific build or run. Aggregating coverage measures, if there are no builds or runs, will not consider overlapping code coverage.



Build Start Time

Build Date and time the build began.

Team Project

Team Project The project against which the coverage statistics were published.

Platform Platform The platform for which the build was made. The possible values include the following:

X86

X64

Itanium

Win32

Any CPU

.NET

Mixed Platforms

Any valid platform created by the process

template.

Build Flavor Flavor The configuration of the build. The possible values include the following:

Debug

Release

Any valid configuration created by the process

template.

Set in the New Team Build Type Creation Wizard.

Run Run The test run ID that was used in generating Run Coverage statistics.

Remote Run Run A True/False flag that indicates whether the test run that generated the coverage statistics was a remote test run.

Assembly Assembly The assembly name against which the coverage statistics were generated.

To Top

Current Work Item Perspective

You can use the Current Work Item perspective to view the measures and dimensions of the Team System cube that pertain to the current state of work items.

You can use this perspective to answer questions such as:

How many active tasks are assigned to each person?

How many bugs are active in each area of the project?

How many un-triaged items of each type are active in the project?

How many active tasks have issues associated with them, and what are the tasks?

How many active requirements have bugs linked to them?

Measures

The following table describes the measures that are included in the Current Work Item

perspective. The Current Work Item Count measure is present in all Team Foundation

Server deployments. The scheduling fields of Remaining Work, Completed Work, and

Baseline Work is present if any process template on the server uses the scheduling fields

in work item definitions. Additional measures are present in this perspective when

custom fields in the work item type definitions specify "measure" as the reportable

attribute.

Measure Description

Current Work Item Count Contains the current number of work items that meet the selection criteria in the query or report.

Remaining Work Contains the remaining hours of work for work items that meet the selection criteria in the query or report.

Completed Work Contains the completed hours of work for work items that meet the selection criteria in the query or report.

Baseline Work Contains the baseline hours of work for work items that meet the selection criteria in the query or report.

Dimensions

The Current Work Item perspective contains all the dimensions that can be used to summarize and filter

the measures. These dimensions can be categorized into the following groups, each of which is described

in the tables in the following table:

Shared Dimensions These are relationships between the work item and elements in the cube;

such as Team Project, Date, or Person, that are shared across many Team System perspectives.

Work Item Dimension The work item dimension contains all attributes particular to work

items, such as the State, Work Item Type and Work Item ID. Additionally, work item fields in

process templates that have the reportable attribute set to "Dimension" will be reflected as

attributes in the Work Item dimension.

Related Dimensions The measures in the Current Work Item perspective can be summarized

by attributes of the work items that are linked to them. For each dimension in the Current Work

Item perspective, there is a corresponding "Related" dimension.

Shared Dimensions

The following table describes the shared dimensions that are included in the Current

Work Item perspective. You can aggregate the measures along each of these dimensions.

The Dimension Use column indicates the name of the dimension as it pertains to the

measures in the Current Work Item perspective. For all work items, there are a common

set of dimension uses defined in the Team System cube. These dimension uses are listed

as "Common" in the Origin column. Besides these common dimension uses, new

dimension uses can be defined by designating fields as "reportable" in the process

template definition. The MSF process templates contain such dimensions as indicated by

the values CMMI, Agile, or MSF (if the attribute is common to both) in the Origin

column in the following table.

Dimension Use Dimension Origin Description

Area Area Common The area in which the work item is classified.

Found In Build1 MSF The build in which the bug was found.

Integration Build Build1 MSF The build in which the bug was fixed.

Activated Date Date Common The latest date on which the work item was activated.

Closed Date Date Common The latest date on which the work item was closed.

Date Date Common The date on which a work item is changed.

Resolved Date Date Common The latest date on which the work item was resolved.

Start Date Date MSF The current value of the Finish Date scheduling field

Finish Date Date MSF The current value of the Finish Date scheduling field

Iteration Iteration Common The iteration in which the work item is classified.

Assigned To Person Common The person to whom the work item is assigned.

Changed By Person Common The person who changed the work item.

Created By Person Common The person who created the work item.

Team Project Team Project Common The team project associated with the work item.

1 For more information, see Build Perspective.

The Work Item Dimension

The following tables describe the common attributes that are included in the Work Item

dimension. This dimension contains all attributes of all work items that are deployed on

the Team Foundation Server computer. Every work item definition contains a set of

common fields, and these fields are always attributes in the Work Item dimension.

http://msdn.microsoft.com/en-us/library/ms244712(VS.80).aspx

Attribute Origin Description

ID Common The identification number of the work item, as assigned when the work item was created.

Work Item Type Common The type of work item.

Title Common The title of the work item.

State Common The state of the work item.

Previous State Common The previous state of the work item.

Reason Common The reason that the state of the work item changed.

Rev Common The revision of the work item.

Activated By MSF The person who activated the work item.

Blocked CMMI Whether the work item is blocked from being completed.

Closed By MSF The person who closed the work item.

Discipline MSF The discipline to which the task belongs.

Exit Criteria MSF The flag to determine whether this scenario should be tracked as an exit criteria for the iteration.

Issue MSF Used to highlight the work item, for example, to mark a bug as an issue.

Rough Order of Magnitude Agile A rough estimate of the number of person-days to complete the task.

Priority CMMI Priority to the business.

Quality of Service Type Common The Quality of Service type.

Rank MSF Stack rank to prioritize work

Requirement Type CMMI The type of the requirement.

Resolved By MSF The person who resolved the work item.

Resolved Reason MSF The reason why the bug was resolved.

Task Hierarchy MSF A string representing Microsoft Project context for the given work item.

Task Type CMMI The type of task.

Triage CMMI Status of triaging the work item.

Related Dimensions

Each dimension and dimension attribute that were discussed earlier has a corresponding dimension that

enables the measures to be filtered or categorized by the attributes of work items that are linked to the

work items being analyzed. This lets you perform queries that answer questions such as "How many

active bugs are linked to priority 1 scenarios?"

The dimensions that correspond to the attributes of work item links are prefixed with the

word "Related." For example, the "Assigned To" dimension use has a corresponding

dimension "Related Assigned To," and so on for other dimension uses.

Dimension Description

Related Area Used to categorize the selected work items by the area of the linked work items.

Related Iteration Used to categorize the selected work items by the iteration of the linked work items.

Related Date Used to categorize the selected work items by the date of the linked work items.

Related Assigned To Used to categorize the selected work items by the person or group the linked work items are assigned to.

Related Changed By Used to categorize the selected work items by the person or group that changed the linked work items.

Related Created By Used to categorize the selected work items by the person or group that created the linked work items.

Related Activated Date Used to categorize the selected work items by the date the linked work items were activated.

Related Closed Date Used to categorize the selected work items by the date the linked work items were closed.

Related Resolved Date Used to categorize the selected work items by the date the linked work items were resolved.

Related Work Item Used to categorize the selected work items by the linked work items.

Related Start Date Used to categorize the selected work items by the date the linked work items were started.

Related Finish Date Used to categorize the selected work items by the date the linked work items were finished.

Related Found In Used to categorize the selected work items by whether the linked work items were found in the build.

Related Integration Build Used to categorize the selected work items by the build in which the linked work items were resolved.

Related Created Date Used to categorize the selected work items by the date the linked work items were created.

To Top

Load Test Perspective

When a load test is executed and the results are published, the details of load test results at the page,

transaction, and counter levels are loaded into the data warehouse and appears in the Result perspective.

By using these details, you can answer questions such as:

Which transactions and pages were executed in the load test, and what was their average

response time?

What counter values, such as memory usage or network throughput were collected, and what

were the values?

Are the results of a particular load test better or worse than results from a comparison test?

Measures

The following table describes the measures that are included in the Load Test

perspective. The information that is contained in the measures and dimensions for this

perspective are driven by the structure of the load tests that generated the results that have

been published to the data warehouse.


Value Load Test Counter Values collected by the counters during the execution of the load test. These values can be analyzed using the attributes in the Counter ID dimension. Depending on the type of counter that is taking the measurement, the value in this measure has different meanings, for example, the amount of available memory, the number of requests per second, and so on.

Average Duration Load Test Details The Average duration for the tests executed during the load test.

Failed Tests Load Test Details The number of tests that failed during the execution of the load test.

Total Tests Load Test Details The total number of tests that were executed as a part of the load test.

Page Count Load Test Results The number of Web page reads that occurred in the load test.

Response Time Load Test Results The average response time for the pages read by the load test.

Actual Duration Load Test Summary The actual duration for which the load test ran.

Elapsed Time Load Test Transaction The average elapsed time for the transactions that occurred in the load test.

Load Test Transaction Response Time

Load Test Transaction The average response time for the transactions that occurred in the load test.

Transactions Load Test Transaction The number of transactions executed during a load test. This can be summarized by the transaction dimension.

Dimension

The following table describes the attributes that are included in the Load Test

perspective. You can aggregate the measures along each of these attributes.




Counter Counter ID Identifies the specific counter within the counter object to which the Value measure in the Load Test Counter measure group is associated. For example, for the Request counter object, the values contain elements identified by the specific counter such as Average Response Time, Cached Requests, Failed Requests, and so on.

Counter Instance Counter ID Identifies the counter instance associated with the Value measure of the Load Test Counter measure group. For example, a counter instance may indicate a specific network card associated with the measurement of Bytes Received per second, Counter within the Network Interface counter object.

Counter Object Counter ID The Load Test Counter object used in measuring activity during the load test. This includes counters such as Memory, Network Interface, or Requests. These counters relate to the Value measure in the Load Test Counter measure group described above. Finer granularity for interpreting the meaning of this attribute is contained in the Counter attribute of the Counter ID dimension.

Counter Result Counter ID Boolean value indicating that the current counter is used to determine the overall result.

HigherIsBetter Counter ID A flag indicating whether the value measured by this counter instance is better when the value is higher. For example, it is better to have higher throughput for the Bytes Received per Second counter, but it is not better to have higher memory consumption for the Average Test Time measurement. This enables reports to be created that indicate improvements from one run of a load test to another.

Load Test Counter Dimension

Counter ID Used internally.

Load Test Scenario Load Test Scenario The scenario used for measurements found in the Load Test Transaction and Load Test Details measure groups.

Load Test Transaction Dimension

Load Test Transaction

Used internally.

Transaction Load Test Transaction

The name of the transaction associated with measurements in the Load Test Transaction measure group. This enables a list of all transactions, and their corresponding response times and frequencies to be generated for a particular load test result, or across many load test results.

Machine Machine The computer on which the associated load test counter collected information.

Load Test Page Summary Dimension

Page Summary Used internally.

Url Page Summary The URL of the Web page used when measuring the Page Count and Response Time measures of the Load Test page Summary measure group.

Result Result The name of the Test Result of the load test. By default, this is the timestamp of the time at which the load test was run.

Test Result The name of the load test.

Test Description Result A description of the test when the load test result was run.

Test Type Result The type of test associated with the test result. For load tests, this will always be Load Test.

Run Run The description of the test run that produced the load test results.

Remote Run Run A True/False flag that indicates if the test run that produced the load test results was a remote test run.

Load Test Scenario Scenario Used internally.

Team Project Team Project The team project referenced when publishing the load test results.

To Top

Test Results Perspective

The Test Results perspective shows all the fields associated with tests and their results. The Test Results

perspective is based on the Test Result relational table that enables reporting on test results as either a

property of the tests or as an independent outcome. You can also answer questions about changes to the

result outcomes. These ways of reporting on the test results can be to answer the following types of

questions:

Which tests are failing in the current build?

In this case, if a test is run multiple times against a build, the answer is based on the latest result

for that test using that build.

How many failed results have occurred in the current build?

In this case, if a test is run multiple times against a build, each result is counted separately.

What is the latest result for a particular test across a range of builds and test runs?

In this case, each test can be listed with its corresponding latest result across the selected builds

and test runs.

Measures

The following table describes the measures that are included in the Test Results

perspective.

Measure Description

Cumulative Result Count

Counts the latest version of each result in a particular build.

Latest Result Displays the latest results when you use it together with the Test dimension, and displays the latest result of the test. This calculation requires significant computation and should be used when the number of tests being analyzed is constrained.

Result Count Counts all the results individually.

Result Transition Count Counts all the results where the outcome for a result in a particular build changed.

Shared Dimensions

The following table describes the attributes that are included in the Test Results

perspective. You can aggregate the measures along each of these attributes.

Dimension Use Dimension Description

Area Area The area classification of the test result. If the test result did not specify an area when it was published, the area is set to "Unknown."



Build Type Build The build type of the build against which the test result was generated. For more information, see Build Perspective.

Date Date The date that the test result was generated.

Date Finished Date The finish date of the test run that generated the result.

Build Flavor Flavor The build flavor of the build against which the test result was generated. For more information, see Build Perspective.

Iteration Iteration The area classification of the test result. If the test result did not specify an area when it was published, the area is set to "Unknown."

Alias Owner The alias of the author or current owner of the test.

Person Owner The name of the author or current owner of the test.

Platform Platform The operating system for which the build was made. The possible values include the following:

X86

X64

Itanium

Win32

Any CPU

.NET

Mixed Platforms

Any valid operating system created by the

process template.

This value is set in the New Team Build Type

Creation Wizard.

Team Project Team Project The team project referenced when publishing the load test results.

ID Work Item The work item's ID, as assigned when the work item was created.

Previous State Work Item The previous state of the work item.

Work Item Type Work Item The type of the work item.

Reason Work Item The reason that the state of the work item changed.

Rev Work Item The revision of the work item.

State Work Item The state of the work item.

Title Work Item The title of the work item.

(other) Work Item Other attributes depending on the process template used to create the team project. For more information, see the "The Work Item Dimension" section of Current Work Item Perspective.

Test Result Dimensions

The following table lists all dimensions and attributes specific to the test measures in the

cube.


Machine Agent Machine The computer on which the test was run.

Alias Assigned To The alias of the person the test is assigned to.

Person Assigned To The name of the person the test is assigned to.

Test Category Category This hierarchy categorizes test results according to the test list in which they are run. This is a parent-child hierarchy, and can be used to drill down into sub-categories of tests, if nested test lists are used when tests are executed and published.





Outcome Outcome The outcome of the test, for example, Passed, Failed, or Inconclusive.

Outcome Passing Outcome A flag that is set to True if the outcome of a test is passing, or false if the outcome is anything other than passing.

Result Result The name of the test result.

Test Result The name of the test that generated the result.

Test Description Result A description of the test associated with the result.

Test Result Result A hierarchy of the Test and Result. This enables drill-down from results for a particular test to the individual results of that test.

Test Type Result The type of the test result, for example, Unit Test, Web Test, Load Test.

Run Run The Run Name of the Test Run that generated the test result.

Remote Run Run A flag, either True or False. This indicates whether the test run that produced the result was a remote test run.

Alias Run By The alias of the person or account under which the test was run.

Person Run By The name of the person or account under which the test was run.

To Top

Work Item History Perspective

The Current Work Item Perspective enables queries and reports based on the current state of work items

on the server. In contrast, the Work Item History perspective provides views on the historical information

about work items over time. This perspective is based on the Work Item History relational table. You can

use this perspective to answer questions such as:

What was the total count of active bugs each day in the last iteration?

How many scenarios were active each month during the last year?

How many bugs of each priority have been active each day in the last month?

These questions require that you use totals as they appeared at a particular point in time. For these types

of questions, the Work Item Count measure is used. This measure is a calculated measure, and appears in

the Work Item perspective.

Another type of query that can be performed by using the historical information in the Work Items

perspective, answers questions regarding the activity on a particular day (instead of the total number of

items on a particular day). You can use the State Change Count and Revision Count measures to answer

questions such as:

How many bugs were closed each day in the last month?

How many bugs were reactivated in the last milestone?

How many priority = 1 bugs did a certain set of users close during a particular week, or iteration?

How many QA Tasks which had their Issue flags set have been closed each week this year?

Besides these measures, any field marked in the process template as playing the role of a measure (that

is, reportable="measure") will cause a new calculated measure to appear that enables point-in-time

reporting such as the Work Item Count measure. For example, the MSF for Agile Software Development

process template declares the scheduling fields of Active, Remaining, and Baseline work as measures.

These measures enable reporting to be performed on projects that use integration with Microsoft Project.

Projects that are based on the MSF for Agile Software Development process template include measures for

these values. You can use these measures to answer questions such as:

How much outstanding and remaining work has a set of work items had over the last month?

How much work was completed by a set of developers?

How much additional work was created after a particular date?

Measures

The following table describes the measures included in the Work Item History

perspective. The scheduling measures listed here are included with the default process

templates. When measures in the cube are based on fields in a process template, they use

the reference name of the originating field, but have a localized translation for the

measure name seen when you browse the cube with Microsoft Excel or other reporting

tools.

Measure Description

Cumulative Baseline Work The number of hours of work from the baseline plan for the selected dimensions. The reference name of this measure is

Microsoft_VSTS_Scheduling_BaselineWork.

Cumulative Completed Work The number of hours of work completed for the selected dimensions. The reference name of this measure is Microsoft_VSTS_Scheduling_CompletedWork.

Cumulative Count Cumulative count records the number of work item revisions that have occurred for the selected dimensions.

Cumulative Remaining Work An estimate of the number hours of work remaining to complete selected work items. The reference name of this measure is Microsoft_VSTS_Scheduling_RemainingWork.

Revision Count Revision count records the number of work item revisions that have occurred. This is useful when you view detailed history about work items. For example, a query that returns the Revision Count, and is sliced by the Changed By dimension and filtered by a date range results display the number of times each person has modified a work item.

This measure is also useful when displaying the detailed history of a particular work item.

State Change Count State Change Count records the number of times that work items change state. When it is used together with the dimensions in the Work Item History perspective, it can be used to display results for Bug Activations in a particular Area over a particular time range.

Work Item URL The uniform resource locator (URL) for the work item. A URL specifies the protocol that will be used by Web browsers to locate Internet resources and includes the name of the server on which the resource resides, and, optionally, the path of a resource.

Hidden Measures

In order to build the calculations that provide point-in-time totals, several hidden

measures are used. These hidden measures are not exposed to client tools such as

Microsoft Excel or Report Designer, but are present in the cube definition of the

deployed cube. Hidden measures perform a calculation using the MDX LastChild

function that aggregates the total for the measure as-of a particular date.

Measure Description

LastChild Record Count Hidden measure used in the calculation of

"Work Item Count."

LastChild Microsoft_VSTS_Scheduling_RemainingWork Hidden measure used in the calculation of

"Remaining Work."

LastChild Microsoft_VSTS_Scheduling_CompletedWork Hidden measure used in the calculation of

"Completed Work."

LastChild Microsoft_VSTS_Scheduling_BaselineWork Hidden measure used in the calculation of

"Baseline Work."

Shared Dimensions

The following table describes the shared dimensions that are included in the Work Item

History perspective. You can aggregate the measures along each of these. The Dimension

Use column indicates the name of the dimension as it pertains to the measures in the

Work Item History perspective. For all work items, there are a common set of dimension

uses defined in the Team System cube. These dimension uses are listed as "Common" in

the Origin column. Besides these common dimension uses, new dimension uses can be

defined by designating fields as "reportable" in the process template definition.

Dimension Use Dimension Origin Description

Team Project Team Project

Common The team project associated with the work item.

Area Area Common The Area in which the work item is classified.

Iteration Iteration Common The Iteration in which the work item is classified.

Date Date Common The date dimension records the date on which a work item was changed.

Assigned To Alias Common The alias of the person to whom the work item is assigned.

Assigned To Person Common The name of the person to whom the work item is assigned.

Changed By Alias Common The alias of the person who changed the work item.

Changed By Person Common The name of the person who changed the work item.

Created By Alias Common The alias of the person who created the work item.

Created By Person Common The name of the person who created the work item.

Changeset Changeset Common The set of changesets associated with the set of work items that meet the filter criteria.

Changeset ID Changeset Common The ID of the changeset associated with the set of work items that meet the filter criteria.

Found In build Build Common The build in which the bug was found.

Integration Build Build Common The build in which the bug was fixed.

Target Resolved Date

Date CMMI The date and time the work item is targeted to be resolved.

Proposed Date Date CMMI The date the work item was proposed.

The Work Item Dimension

The following tables describe the attributes that are included in the Work Item

Dimension. This dimension contains all attributes of all work items that are deployed on

the server. Every work item definition contains a set of common fields, and these fields

will always be attributes in the work item dimension.

Attribute Origin Description

ID Common The work item's ID, as assigned when the work item was created.

Previous State Common The previous state of the work item.

Reason Common The reason that the state of the work item changed.

Rev Common The revision of the work item.

State Common The state of the work item.

Work Item Type Common The type of the work item.

Title Common The title of the work item.

Activated By Common The person who activated the work item.

Closed By Common The person who closed the work item.

CMMI Estimate Common The estimated number of hours to complete the amount of work.

Committed Common Whether the requirement has been committed.

Discipline Common The discipline to which the task belongs.

Exit Criteria Common The flag to determine whether this scenario should be tracked as an exit criteria for the iteration.

Issue Common Issue is used to highlight the work item, for example, to mark a bug as an issue.

Rough Order of Magnitude (Days)

Agile A rough estimate of the number of person-days to complete the task.

Meeting Type CMMI The type of the meeting.

Priority CMMI The Priority to the business.

Probability CMMI The environment in which the work item was found.

Proposed By CMMI The person who proposed the work item.

Rank Common The Stack rank for prioritizing work.

Requirement Type CMMI The type of the requirement.

Resolved By Common The person who resolved the work item.

Resolved Reason Common The reason why the bug was resolved.

Task Hierarchy Common A string representing Microsoft Project context for the given work item.

Triage CMMI Status of triaging the work item.

UAT CMMI The user acceptance test (UAT) of the requirement.

To Top

Perspectives and Matrices in TFS

Documents

Transcript of Perspectives and Matrices in TFS