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.

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.

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.

Measure Measure Group Description

Count Code Coverage from The number of builds that have code coverage statistics
Build associated with them.

Lines Covered Code Coverage from The number of lines covered in the selected build. If
Build 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 The number of lines not covered in the selected build. If
Build 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 The number of lines partially covered in the selected
Build 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 The number of blocks covered in the selected build. If
Build 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 The number of blocks not covered in the selected build.
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 The number of test runs that have code coverage
Run statistics associated with them.

Lines Covered Code Coverage from The number of lines covered by all tests in a run, taking
Run into consideration that there may be overlap in the
coverage across the tests.
Lines Not Covered Code Coverage from The number of lines not covered by all tests in a run,
Run taking into consideration that there may be overlap in
the coverage across the tests.

Lines Partially Covered Code Coverage from The number of lines partially covered by all tests in a
Run run, taking into consideration that there may be overlap
in the coverage across the tests.

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

Blocks Not Covered Code Coverage from The number of blocks not covered by all tests in a run,
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.

Attribute Dimension Description

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 Build Number or name used to uniquely identify the build.

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 Start Build Date and time the build began.

Time

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 Build 1
MSF The build in which the bug was found.

Integration Build Build 1

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.

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.

Measure Measure Group Description

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 Load Test Transaction The average response time for the transactions that
Response Time 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.

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.

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 Counter ID Used internally.

Dimension

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 Load Test Transaction Used internally.

Dimension

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 Page Summary Used internally.

Summary Dimension

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 Build Number or name used to uniquely identify the build.

Build Start Time Build Date and time the build began.

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.

Attribute Dimension Description

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 CMMI The date and time the work item is targeted to be
Date 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 Agile A rough estimate of the number of person-days to complete the
Magnitude (Days) 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