Report

Table of Contents
Dashboards
Overview
Charts, dashboards, and widgets
Quickstarts
Add and manage dashboards
Add widgets to a dashboard
Add Markdown to a dashboard
Tutorials
Configure burndown or burnup widgets
Configure a cumulative flow chart
Configure a lead/cycle time widget
Configure or view Velocity charts
Work with sprint burndown
Concepts
Cumulative flow, lead time, and cycle time guidance
Velocity guidance
Burndown guidance
How-to Guides
Add charts to a dashboard
Configure work item query-based charts
Configure test status, progress, & result charts
Set dashboard permissions
Reference
Widget catalog
Markdown guidance
Resources
Agile
Testing
Build a dashboard widget
Marketplace widgets
Dashboards
10/18/2017 1 min to read Edit Online
VSTS | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

Start gaining visibility into how your team is progressing by adding one or more widgets to your dashboard. Each
team can customize and configure dashboards to share information and monitor their progress.
5-Minute Quickstarts
Add charts and widgets to a dashboard
Step-by-Step Tutorials
Configure a Cumulative Flow chart
Configure a Lead Time or Cycle Time widget
Configure or view Velocity chart
View sprint burndown charts
Concepts
Velocity metrics and usage guidance
Burndown guidance
How-to Guides
Configure work item query-based charts
Configure test status, progress, and result charts
Reference
Widget catalog
Resources
Build a dashboard widget
Marketplace widgets
Dashboards, charts, & widgets

Customizable, highly-configurable dashboards provide you and your teams with the flexibility to share information,
monitor progress and trends, and improve your workflow processes.
Add widgets to your dashboard

With dashboards, you can configure an array of charts and widgets.
Each team can add and configure multiple dashboards to share information, view status, progress, and trends, and
access quick links and other functions. Easily add and rearrange widgets on the dashboard to show recent changes
made to view build status, bug trends, and more.
Sample chart widgets

Sequence for adding and customizing a dashboard
Monitor code activity, build progress and deployment status

With the code tile widgets, you can monitor the activity occuring within a repo or branch folder. Build history
displays a histogram of all builds run for a specific build definition. Bar color indicates: green-completed, red-failed,
and yellow-completed without tests.
Code, build, and release chart widgets
Marketplace widgets
In addition to the widgets available to your from the widget catalog, you may find additional widgets of interest
from the Marketplace.
Generate status and trend charts from queries

With flat-list queries, you can create various charts to monitor status, progress, and trends. To get started, you can
open a shared query and create a chart based on your tracking interests. Chart types include statuspie, bar,
column, stacked bar, and pivotand trendstacked area, line, and areacharts.
Sample Agile tool light-weight charts
Sequence for adding query-based charts to a dashboard
Prior to monitoring work progress and trends, you'll need to have planned your project and made progress on
work you're tracking.
Test progress, results, and trends

The steps to creating charts that track test progress and results are similar to those for tracking work. The starting
point, however, begins with the test plan rather than a query. For example, you can find out how many test cases
are ready to run, or how many tests are passing and failing in each test suite.
Sample light-weight test charts
And, just like work item query-based charts, you can add these charts to a dashboard.
Sequence for adding test progress and result charts to a dashboard
System-generated work tracking charts

There are a number of system-generated charts that you can access from the web portal, but can't add to a
dashboard. However, you may find a comparable widget listed in the widget catalog that tracks the same or similar
data which you can add to the dashboard. These include:
Cumulative flow
Team velocity
Sprint burndown chart
Sprint charts
Each sprint provides access to two charts. The first tracks capacity for the team, team activitiessuch as
Development, Test, Designand individual team members. The second tracks the sprint burndown in terms of
remaining work.
CAPACITY BARS BURNDOWN
Sprint chart widgets
Try this next

Add a widget to a dashboard or Review available widgets
Add custom fields
You can add data to support reporting requirements in the following ways:
Add a custom field (Inheritance process model, VSTS)
Add or modify a field (Hosted XML or On-premises XML)
Extensibility
Using the REST API service, you can create a custom widget.
VSTS | TFS 2018 | TFS 2017 | TFS 2015.1-2015.3
NOTE
Feature availability: Multiple team dashboards and the widget catalog are available from Visual Studio Team Services
(VSTS) and from the web portal for TFS 2015.1 or later version.
If you connect to an on-premises TFS running TFS 2015 or earlier version, you don't have access to multiple team
dashboards. Instead, your home page serves as a single team dashboard. For information on SharePoint dashboards, see
Project portal dashboards.
Share progress and status with your team using configurable team dashboards. Dashboards provide easy-to-
read, easy access, real-time information. At a glance, you can make informed decisions without having to drill
down into other parts of your team project site.
The Overview page provides access to a default team dashboard which you can customize by adding, removing,
or rearranging the tiles. Each tile corresponds to a widget that provides access to one or more features or
functions.
Anyone with access to the team project, including stakeholders, can view dashboards. However, only team
admins can add or modify dashboards.
If you need to add a team first, see add teams and team members.
Connect to the web portal for your team project

To add and manage dashboards, you connect to your team project using a supported web browser. If you don't
have a team project yet, create one in VSTS or set one up in an on-premises TFS.
Open a browser window and click the Dashboards hub.
If you don't see the team or team project you want, click the project icon to browse all team projects and
teams.
Add and name your dashboard

From the dashboards tab, click the and enter a dashboard name.
If you don't see the , then you're not a team admin for the currently selected team. Either switch the context to
your team, or request you be added as a team admin.
With the dashboard selected, you can add widgets and charts to the dashboard. Or, you can add charts to a team
dashboard from the Work, Build, or Test hubs.
Manage dashboards
NOTE
Feature availability: You can configure the auto-refresh setting for each dashboard on VSTS and for TFS 2015.2 and later
versions. For VSTS and TFS 2017.1 and later versions, you can set dashboard permissions.
You can rename, reorder, or delete a dashboard. Also, you can enable auto-refresh, and the dashboard will
automatically update every 5 minutes.
From VSTS and TFS 2017, you can also manage dashboard permissions.
To manage dashboards, click the wrench icon.
Reorder and auto -refresh

1. Drag and drop the dashboards into the sequence you want them to appear.
2. Click to delete a dashboard and then click Save.

3. Select the Auto-refresh checkbox when you want the dashboard to refresh every five minutes.
Required permissions
If you don't see the , then you don't have permission to edit your team dashboards. In general, you need to be
a team admin for the currently selected team to edit dashboards. Request your current team or project admin to
add you as a team admin.
If you work in VSTS, you can ask your team admin to change dashboard permissions to allow you and other team
members to edit dashboards as described in Set permissions.
Move or delete a widget from a dashboard

NOTE
Just as you have to be a team or project admin to add items to a dashboard, you must have admin permissions to remove
items.
Click to modify your dashboard. You can then drag tiles to reorder their sequence on the dashboard.
To remove a widget, click the widget's or delete icons.
When you're finished with your changes, click to exit dashboard editing.
Try this next

As you can see, you can use team dashboards to provide guidance and keep your team in sync, providing
visibility across the org as to status, trends, and progress.
Add a widget to a dashboard
See these additional resources to help you support your team:
Review the widget catalog
Review Marketplace widgets
Extensibility
Using the REST API service, you can create a dashboard widget. To learn more about the REST APIs for
dashboards and widgets, see Dashboards (API).
Provide feedback
We welcome your feedback.
Send suggestions on UserVoice, and follow us on Twitter @vsts.
See also our comprehensive feedback and support page.
Add widgets to a dashboard
VSTS | TFS 2018 | TFS 2017

Widgets smartly format data to provide access to easily consumable data. You add widgets to your team
dashboards to gain visibility into the status and trends occurring as you develop your software project.
Each widget provides access to a chart, user-configurable information, or a set of links that open a feature or
function.
You can add one or more charts or widgets to your dashboard. You add several widgets at a time simply by
selecting each one. See Manage dashboards to determine the permissions you need to add and remove widgets
from a dashboard.

To add a widget to a dashboard, you connect to your team project using a supported web browser. If you don't
have a team project yet, create one in VSTS.
Open a browser window and click the Dashboards hub. If you haven't been added as a team member, get
added now.
If you don't see the team or team project you want, click the project icon to browse all team projects and
teams.
NOTE
Feature availability: You can access the widget catalog from the web portal for VSTS or TFS 2015.1 or later version. The
widget catalog provides widgets for all tiles supported in previous releases of TFS for the team homepage. For on-
premises TFS 2015, you can add select charts to the team home page using the Pin to home page feature.
To determine the platform and version you're on, see Provide product and content feedback, Platforms and version
support.
Click to modify a dashboard. Click to add a widget to the dashboard.

The widget catalog describes all the available widgets, many of which are scoped to the selected team context.
NOTE
Feature availability: For VSTS and TFS 2017 and later versions, you can drag and drop a widget from the catalog onto
the dashboard.
Widget images may vary depending on which platform you access. This topic shows images that appear in VSTS. However,
the widget title and functionality described in this topic are valid for both VSTS and TFS. For example, dashboard edit
mode controls shown below are valid for VSTS and TFS 2015.2 and later version. Some functionality differs when you
connect to TFS 2015.1 or earlier versions.
Configure a widget
To configure a widget, add the widget to a dashboard and then click the configure icon.
Click the delete icon to remove the tile from the dashboard.
Once you've configured the widget, you can edit it by opening the actions menu.
Move or delete a widget from a dashboard

NOTE
Just as you have to be a team or project admin to add items to a dashboard, you must have admin permissions to
remove items.
Click to modify your dashboard. You can then drag tiles to reorder their sequence on the dashboard.
To remove a widget, click the widget's or delete icons.
When you're finished with your changes, click to exit dashboard editing.
Copy a widget
NOTE
Feature availability: This feature is only available from VSTS.
To copy a configured widget to another team dashboard, click the actions icon and select Add to
dashboard.
Try this next

Review the widget catalog or Review Marketplace widgets
Extensibility
In addition to the widgets described in the Widget catalog, you can create your own widgets using the Widget
REST APIs.
Widget size
Some widgets are pre-sized and can't be changed. Others are configurable through their configuration dialog.
For example, the Chart for work items widget allows you to select an area size ranging from 2 x 2 to 4 x 4 (tiles).
Disabled Marketplace widget
If your account or project collection administrator disables a marketplace widget, you'll see the following image:
To regain access to it, request your admin to reinstate or reinstall the widget.
VSTS | TFS 2018 | TFS 2017 | TFS 2015.1-2015.3

Use the Markdown widget to support your team and stakeholders by adding information such as:
Team goals
Provide links to team backlogs or boards, metrics, or other items located in a network share such as a OneNote,
SharePoint site or wiki pages
Important dates or target deadlines
Here's an example:

To add the markdown widget to a dashboard, you connect to your team project using a supported web browser. If
you don't have a team project yet, create one in VSTS.
Open a browser window and click the Dashboards hub. If you haven't been added as a team member, get added
now.
If you don't see the team or team project you want, click the project icon to browse all team projects and teams.
Add the markdown widget to a dashboard
1. Click to modify a dashboard.

If you need to add a dashboard, see Add and manage dashboards.
2. Click to open the widget catalog.

3. Drag the Markdown widget onto the dashboard where you want it located.
4. Click the gear icon to open the configuration dialog for the widget.
To edit a markdown widget, you may need to be a team admin, a member of the Project Administrators
group, or be granted permissions. To learn more, see (../report/dashboard-permissions.md).
5. Adjust the widget size as needed to fit the contents of the markdown you'll enter. The largest size is 10 tiles
wide by 10 tiles tall. You can always adjust this later.
6. Enter the text and markdown syntax into the configuration the configuration dialog. For supported syntax,
see Syntax guidance for Markdown files, widgets, wikis, and pull request comments.
Here we show some simple text with a bulleted list of four links
To link to a wiki page, repository file, hub, or page within the team project, use this format:
/DefaultCollection/Fabrikam%20Fiber/Voice/_wiki?pagePath=%2FHome
/DefaultCollection/Fabrikam%20Fiber/Voice/_git/Fabrikam%20Fiber?path=%2FREADME.md
/DefaultCollection/Fabrikam%20Fiber/Voice/_backlogs?level=Backlog%20items&showParents=false&_a=backlog
This renders the following widget:
NOTE
Links to documents on file shares using file:// are not supported on VSTS or TFS 2017.1 and later versions. This
restriction has been implemented for security purposes.
7. Optionally, you can choose to point to a file in your repository.

8. If you haven't closed the widget catalog yet, do that now.
9. If you want to reposition the markdown widget or other widgets on the dashboard, do that now while you're
still in dashboard edit mode.
10. When you're finished with your changes, click to exit dashboard editing.
Related notes
Syntax guidance for Markdown files, widgets, wikis, and pull request comments
Widget catalog
Marketplace widgets
Configure a Burndown or Burnup widget
VSTS
The Burndown and Burnup widgets provide the flexibility to create burndown or burnup charts for any type of
scope, worked on by any number of teams, within any defined period of time. Burndown charts focus on remaining
work within a specific time period, while Burnup charts focus on completed work.
NOTE
Feature availability: The Burndown and Burnup widgets are available only for VSTS at this time. For on-premises TFS, you
can add the Sprint Burndown widget to your dashboard.
Both burndown and burnup charts help answer the question: Are we on track to complete this set of work by
the end date?
Use this topic to learn how to:
Install and configure the burndown or burnup widgets
How burndown metrics should be used
How to work with the burndown chart
A burndown chart is a useful tool to track completion of a predefined scope of work over a predefined period of
time. For example, a sprint burndown tracks the sprint backlog completion by end of the sprint. A release
burndown tracks the release backlog completion by the end of the release. A bug burndown chart can also be used
to track completion of a set of bugs by a certain date.
Burndown widget configured to display a Release Burndown
Burndown widget configured to display a Bug Burndown
Burndown and burnup metrics

Burndown and burnup charts provide an easy way to monitor progress across teams and sprints by showing work
remaining over time. Work remaining is the vertical axis and time is the horizontal axis. You can define remaining
work to be calculated as a sum of a particular field, such as Story Points, or count of a particular work item type.
In addition, each chart calculates and displays the average burndown or burnup rate and added scope over the
course of the project. The Burndown chart calculates a projected completion date for when the work is expected to
be done based on historical burndown and scope increase. Using burndown, teams can stay on top of their
progress and see the immediate impact of their work on their delivery date.
To help you answer the question: Are we on track to complete this set of work by the end date?, the widgets
provide these useful metrics:
Percentage work complete
Average burndown rate
Total scope increase
Number of work items not estimated with Story Points (or whichever field you are burning down on)
Projected burndown, based on historical burndown rate
Projected scope increase, based on historical scope increase rate
Projected completion date, based on historical burndown and scope increase rates
Add the widget to your dashboard

The Configuration dialog for the Burndown and Burnup widgets is the same. You configure these widgets for one
or more teams. To learn more about teams, see Add teams and team members.
1. If you haven't yet added the Analytics Marketplace extension, do that now.
2. If you haven't yet added the Burndown widget to your dashboard, do that now.
3. Click the actions icon and choose the Configure option to open the configuration dialog.
NOTE
While the Burndown and Burnup widgets use the Analytics service, access to the service for other report purposes is not
supported at this time.
Choose the teams and work items to chart

1. Modify the Title of the widget and select your preferred Size. The Burndown widget can scale up to 10x10.
2. Select the Teams you want to track.
Select at least one Project and one Team.
If you wish to track progress across teams, just add more teams using the team selector. You may also select
teams from other team projects.
The Burndown chart will display the burndown of remaining work for all selected teams.
NOTE
While you can select teams from other team projects, all of the available configuration optionsWork items, Field
criteria, and Burndown on will show selections from your current team project.
The list of selectable backlogs, work item types, and fields are based on your current team project.
For example, if you select a work item type that doesn't exist in another team project, the burndown will not include
work items from that team project. If you select a field that doesn't exist in another team project, that field will be
considered blank for the burndown. Therefore, a burndown created across multiple team projects will only work if the
Process for those projects are the same, or at least very similar.
3. Choose your work items. The burndown can include work based on items in your Backlog or by Work
item type.
You can select a Backlog, which include all the work items in that backlog.
If you select the Stories backlog you are presented with an additional option: Include bugs on the Stories
backlog. Place a checkmark in the box to include bugs along with user stories in your burndown.
This option is presented for the PBI Backlog for Scrum projects, and the Requirements backlog for CMMI
projects.
You can also select Work item type to burndown on a specific work item type. In the list, you will find all
the project's work item types including custom work item types.
4. (Optional) Select field criteria to limit the work items that appear in the chart.
You can filter by any field available in your team project, even a specific tag. For example, you can narrow
your burndown to top priority items by adding a filter Priority <= 2.
You may add multiple field critiera, by selecting Add criteria. For example, you can also select a custom
field such as Release, to create a burndown chart of only those items assigned to a specific release.
NOTE
All field criteria are AND-ed together. That is, work items must match all the field criteria to be included in the
burndown or burnup chart.
Choose how you want to calculate burndown or burnup

1. Select how you want to calculate burndown or burnup, by a count of work items or a sum based on a
selected field.
Here, we choose to base the burndown on a count of work items.
And, here we choose a sum based on Story Points.
Choose the time period and plotting interval

1. Select the time period. You can select from one of the following options to define your time period:
OPTION PURPOSE FOR BURNDOWN
Start Date Determines the original scope baseline. The chart burns
down from the original scope. % Complete and Total
Scope Increase are calculated based on your original
scope.
End Date Specifies the target date of completion. Your goal is to

burndown the original scope of work by the End Date.
Plotting Interval Here you select the intervals to plot between the Start
Date and End Date. Average Burndown is based on the
selected interval. You can plot burndown based on
daily/weekly/monthly intervals or based on an iteration
schedule.
Plot based on an iteration schedule

After selecting the Start Date, set Plot burndown by to Iteration. You can select iterations from your
current team project.
Add multiple iterations by selecting Add iterations.
The iteration selection box support search, so you can simply type a partial name of an iteration and it will
find the closest match.
The selectable iterations are based on the current team project, even if you selected teams from other
team projects. Since the burndown chart plots remaining work based on the end date of the iteration, it
calculates remaining work across all teams/team projects, based on that iteration end date. For example, if
an iteration ends on 11/10/2017, the burndown chart calculates remaining work as of 11/10/2017, counting
or summing all work items for every team/team project. Therefore, a cross-project burndown will work
when plotting by iterations, as long as you are OK with having all the teams reporting on the same iteration
schedule.
The burndown chart uses the end date of each iteration to plot the remaining work for that iteration.
NOTE
The Average Burndown assumes that every iteration is the same length. It does not account for iterations that are
different lengths. Additionally, it assumes that the interval between the Start Date and the first iteration is a full
iteration, even if the length of time between Start Date and the first iteration's end date does not match your typical
length of iteration. For best restuls, enter a Start Date that is the same as the first iteration's start date.
If you select to plot based on an iteration schedule, you will not be able to select End Date. The burndown
assumes the End Date is the last iteration's end date.
Plot based on a daily, weekly, or monthly interval
After selecting the Start Date, set Plot burndown by to Date. Specify the End Date for your burndown.
You can set Plot interval to Days, Weeks, or Months.
If you select Weeks, then you'll be able to select the Last day of week. The remaining work for each
interval will be calculated based on that day.
If you select Months, then burndown will be caluclated based the last day of each month.
NOTE
The Average Burndown assumes that every interval is the same length. It does not account for months that are
different lengths. Additionally, it assumes that the interval between the Start Date and the first month is a full
month, even if the length of time between Start Date and the first months's end date does not match your typical
length of a month. For example, a Start Date of 11/15/2017, would plot the first month as 10/31/2017, but would
be counted as a full month for your Average Burndown. For best results, enter a Start Date that is the same as the
first months's start date. This is also true when plotting by weekly itervals.
Choose additional options
Check the boxes of the following options that you want to add to your chart.
Show burndown: Displays both the historical and projected future burndown
Show total scope: Displays both the historical and projected scope increase
Show completed work: In addition to remaining work, it also displays completed work as as stack bar
Plot remaining using work item type color: Displays remaining work based on the work item type color,
rather than the default blue color. If multiple work items are included, then it stacks colors by work item type.
Interpret a Burndown or Burnup widget chart

Looking at the burndown chart, a team can not only get immediate insight as to their progress, but also learn about
their rhythm and behavior. Most burndown lines are not straight lines. The team never moves at exactly one fixed
velocity and scope might be added on the way. For example, if your projected completion date as moved, you may
want to ask
Are we adding too much scope?
Is the average burnrate changing, and if so, why?
The burndown chart also helps the teams understand if the release is at risk. If the projected end date exceeds the
release target date, you may need to reduce scope or lengthen your project. Burndown can also indicate that
progress is greater than anticipated, providing the uncommon, but wonderful option of adding scope.
As the following diagram shows, charts based on the Burndown and Burnup widgets provide a number of
calculated elements.
ELEMENT DESCRIPTION
Date range The start and end date of the burndown. When burndown is
plotted by iterations the end date is the end of the last
iteration
Main metric Current remaining work based on the selected burndown

method.
ELEMENT DESCRIPTION
% Completed The percentage of work completed based on original scope.

You may click or press % Completed to see the full list of
completed work items.
Average burndown Average work completed per interval or iteration.
Items not estimated Shows only when burning down on a Sum of a field. It
represents the current number of items that do not have a
value in the selected Burndown on field. You may click or
press the number to see a full list of work items without
estimates.
Total Scope Increase show how much work was added to the original scope since
the burndown started.
Projected completion Calculates the projected completion date based on the

remaining work and historical burndown and scope increase
rates. If the projected completion date is before the specified
End Date, it will draw a vertical line on the interval/interation
when the work should be complete. If the projected
completion date is after the specified End Date, then it will
display the projected completion date and how many
additional intervals/iterations are needed to complete the
work.
Original Scope Original scope is all remaining work as of the specified Start
Date. The chart burns down from the original scope. %
Complete and Total Scope Increase are calculated based on
your original scope.
Total Scope Represents to the total scope of the burndown. The plotted
points include both completed and remaining work. The total
scope line tells you how much scope change your project has.
For past data points, the plotted total scope represents actual
total scope as of the end of each interval/iteration. For future
data points, the plotted total scope represents a projected
scope change, based on past scope changes.
Burndown Represents the burndown. The burndown line tells you how
fast you are burning down the work. For past data points, the
plotted burndown represents actual burndown as of the end
of each interval/iteration. For future data points, the plotted
burndown represents a projected burndown, based on past
burndown.
Configure the Burnup widget

Configuring the Burnup widget is exactly like configuring the Burnup widget, except that it plots work completed,
rather than work remaining.
Burnup Widget displaying a Stories Burnup
Related notes
Define sprints for the team project
Select sprints for a team
Add a custom field to a work item type
Industry resources
Managing Myopia with Release Burndowns
Configure a cumulative flow chart

You use cumulative flow diagrams (CFD) to monitor the flow of work through a system. There are two CFD charts,
the one viewed from the Kanban board and the one you access by adding the CFD widget to your dashboard.
NOTE
Feature availability: The CFD widget is available only for VSTS at this time.
The CFD widget provides more configuration options than those supported by the default CFD charts shown on
the backlog and board pages. With the CFD widget, you can monitor the count of work items as they progressively
move through various states which you define. You can configure the CFD chart to monitor the flow of epics,
features, user stories, product backlog items, or requirements, depending on the process (Agile, Scrum, or (CMMI)
you've selected.
Use this topic to learn how to:
Install and configure the Cumulative Flow widget (Analytics service)
View and configure the built-in Cumulative Flow chart (work tracking datastore)
For usage guidance, see Cumulative flow, lead time, and cycle time guidance.
Configure the CFD widget

NOTE
Feature availability: For VSTS, you can add the CFD widget to your dashboard. You need to first install the Analyics
Marketplace extension. You can then add the widget(s) to your dashboard. You must be an account owner or a member of
the Project Collection Administrator group to add extensions.
You will need to be a team administrator or a member of the Project Administrators group to perform these tasks.
See Manage team assetsto get added as a team admin.
1. If you haven't yet configured your Kanban board, do that now. Define the columns and swimlanes that
support your workflow processes.
2. If you want fixed scope CFD charts, make sure that you've defined the sprint iterations for those sprints of
interest.
3. To add a CFD chart to your team dashboard, see Add a widget to a dashboard. Add the Cumulative Flow
Diagram widget.
4. Click the actions icon and choose the Configure option to open the configuration dialog. Modify the
title, and then select the team, backlog level, swimlanes, and time period you want to monitor.
5. For a continuous flow diagram, select Rolling period and specify the number of days you want to view on
the chart.
Or, for a fixed scope view, choose and specify the Start date. Choose this view if your team employs a
Scrumban process or follows a standard sprint process.
The main difference between these two types of CFD charts is that the fixed scope CFD will provide
information (in most cases) of scope change.
6. Choose the color. You can distinguish the CFD for different teams by choosing different colors.
7. Click Save when done. The following image shows an example CFD chart showing 30 days of data.
View the built-in cumulative flow chart
You open the built-in (work tracking datastore) cumulative flow chart for your backlog or portfolio backlog by
clicking the image in the upper-right corner of your Work>Backlogs page.
The CFD shows the count of items in each Kanban column for the past 30 weeks or less. From this chart you can
gain an idea of the amount of work in progress and lead time. Work in progress counts unfinished requirements.
Lead time indicates the amount of time it takes to complete a requirement once work has started.
Configure the built-in cumulative flow chart
Each team can set their preferences for the built-in cumulative flow charts.
1. Open the backlog level for which you want to configure and then open the common configuration dialog.
Click the gear icon.
If you're not a team admin, get added as one. Only team and project admins can customize the team
Kanban boards and CFD charts.
2. Click the Cumulative flow tab and specify the team's preferences.
3. Repeat steps 1 and 2 for each backlog level you want to configure.
For the CFD chart to reflect useful information, you'll want to update the status of work items to reflect progress as
it occurs. The quickest way to make these updates is through your Kanban board.
Try this next

Cumulative flow, lead time, and cycle time guidance or Kanban basics
Lead time and cycle time control charts
VSTS
NOTE
Feature availability: The Lead Time and Cycle Time widgets are only available for VSTS at this time.
Both lead time and cycle time measures are extremely useful to teams as they indicate how long it takes for work
to flow through their development pipeline. Lead time measures the total time elapsed from the creation of work
items to their completion. Cycle time measures the time it takes for your team to complete work items once they
begin actively working on them.
These measures help teams plan, spot variations in efficiency, and identify potential process issues. The lower the
lead and cycle times, the faster the throughput your team has.
In this topic you'll learn:
How to install and configure the Lead Time and Cycle Time widgets (Analytics service)
How to interpret the scatter-plot control charts
How moving average and standard deviation are calculated in the charts
Configure the Cycle Time and Lead Time widgets

The Configuration dialog for the Cycle Time and Lead Time widgets is the same. You configure these widgets for a
team. To learn more about teams, see Add teams and team members.
Pre -requisites
In order to configure the Cycle Time and Lead Time widgets, you must have the following in place:
Installed the Analyics Marketplace extension. You must be an account owner or a member of the Project
Collection Administrator group to add extensions.
Added the widget to a dashboard. You must be a team administratoror have permissions to add and edit
dashboards.
NOTE
While the Cycle Time and Lead Time widgets use the Analytics data store, access to the data store for other report purposes
is not supported at this time.
Configuration dialog
1. If you haven't yet added the Analyics Marketplace extension, do that now.
2. (Optional) If you haven't yet configured your team's Kanban board, do that now. Define the columns and
swimlanes that support your workflow processes.
3. If you haven't yet added the widgets to your dashboard, do that now.
4. Click the actions icon and choose the Configure option icon to open the configuration dialog. Modify the
title, and then select the team, backlog level, swimlanes, and time period you want to monitor.
5. For a continuous flow, choose Rolling period and specify the number of days you want to view on the chart.
Or, for a fixed scope view, choose and specify the Start date. Choose this view if your team employs a
Scrumban process or follows a standard sprint process.
The main difference between these two types of charts is that the fixed scope chart will provide information
(in most cases) of scope change.
6. Click Save when done. The following image shows an example Lead Time chart showing 60 days of data.
For your lead/cycle time charts to provide useful data, your team must Update the status in a timely manner
those work items that the widgets track.
Interpret the scatter-plot control charts

Both Lead Time and Cycle Time widgets display as scatter-plot control charts. They display summary information
as well as provide several interactive elements.
Example Lead Time widget
The chart dots represent completed work items where their position on the horizontal axis represents the date they
were completed. Their position on the vertical axis represents the calculated lead time or cycle time.
Larger dots represent multiple work items with the same lead/cycle time
Dot color corresponds to the work item type displayed in the legend
Dark gray dots correspond to a mix of work item types.
Summary elements include:
Days on average (average lead time or cycle time) for the main work item types configured for the chart
The number of backlog work items used in the chart calculations; if there are more than three types of work
items, you'll see a summary for Other
The black trend line indicates the moving average
The band around the trend line shows the standard deviation.
Interactive elements include:
Hover over any dot to see which work items contributed to the data point and the lead/cycle time for those
items
Click a dot to open the work item or query that lists the work items
To filter the chart, click a work item type in the legend ( , , or other icon) to filter on that type; to return to
the original chart, refresh the dashboard.
Moving average and standard deviation calculations

The daily moving average value corresponds to the average of data points that fall within the moving average
window. The time-based moving average window is calculated based on the current day and previous N days,
where N corresponds to 20% of the number of days the chart displays, rounded down to the nearest odd number.
For example, if the chart displays the last 30 days, then N=5 days (20% of 30 days=6 days, rounded down to 5).
The moving average window for April 10th corresponds to the previous 5 days. Therefore, the April 10th moving
average is the average of all data points that fall on April 5th through April 10th.
If there are no data points that fall within the moving average window, the chart doesn't show a moving average
line. This can happen if you are starting out and there aren't enough days to calculate a moving average.
The standard deviation appears as a band that encompasses the moving average. Standard deviation is calculated
based on all data points falling within the same moving average window. Like moving average, if no data points
fall within the moving average window, the chart doesn't plot standard deviation.
Related notes
We recommend your team review the lead/cycle time charts before or during each retrospective. Use lead time to
help estimate delivery times and track service level agreements (SLAs). Use cycle time to identify potential process
issues, spot variations in trends, and help with planning.
Kanban basics
Cumulative flow diagram
Workflow states and state categories
Agile, Scrum, and CMMI processes
Configure and view Velocity charts

Teams track their velocity to help them determine how much work they can perform sprint-over-sprint. Velocity
provides an indication of how much work a team can complete during a sprint based either on a count of work
items completed or the sum of estimates made to Effort (PBIs), Story Points (user stories), or Size (requirements).
Velocity calculations rely on the team's ability to estimate backlog items.
Once your team has completed a few sprints, they can use their velocity to forecast how much of the backlog they
can finish within upcoming sprints.
Use this topic to learn:
Install and configure the Velocity widget (Analytics service)
How to work with the Velocity chart (work tracking datastore)
Required and recommended team activities to support velocity tracking
For usage guidance, see Velocity metrics and usage guidance .
There are two velocity charts, the one viewed from the backlog of a team and the one you access by adding the
Velocity widget to a dashboard. The Velocity widget enables you to view more sprints and additional information
than that provided by the velocity chart.
NOTE
Feature availability: The Velocity widget is available only for VSTS at this time.
Velocity chart Velocity widget
Configure the Velocity widget

You configure your velocity widget for a team. To learn more about teams, see Add teams and team members.
Pre -requisites
In order to add a Velocity widget to a dashboard, you must have the following in place:
Installed the Analyics Marketplace extension. You must be an account owner or a member of the Project
Collection Administrator group to add extensions.
Added the widget to a dashboard. You must be a team administratoror have permissions to add and edit
dashboards.
NOTE
While the Velocity widget uses the Analytics data store, access to the data store for other report purposes is not supported
at this time.
Configuration dialog
1. If you haven't yet added the Analyics Marketplace extension, do that now.
2. If you haven't yet added the Velocity widget to your dashboard, do that now.
3. Click the actions icon and choose the Configure option to open the configuration dialog.
Modify the title, select the team, and then choose either the backlog level or work item type to track. Select
whether you want to track a count of work items or a sum of a numeric field. The most common summed
field is that of Effort, Story Points, or Size.
4. Specify the number of sprints you want to view. The default is 6 and the maximum is 15.
5. (Optional) Select the check boxes to show additional information for work completed later than planned for
each sprint.
Displayed planned work for iterations: Check this box to display the amount of work planned for an
iteration at the start of the iteration. This is useful for comparing your planned work to actual deliverables.
By default, the count of planned work begins as of the start date of the iteration.
Days past start date of iteration when planned work is final: Specify a number of days past the start
date to count planned work. For example, if the first 2 days of an iteration are for planning, then you can
enter "3", and planned work will be counted on the 3rd day.
Highlight work completed late Work items marked complete after the iteration end date are considered
to be completed late and will show as light green. This is useful for spotting a trend where work items are
marked complete after the iteration is complete.
NOTE
A work item is considered late when the work item's Completed Date is later than End Date of the Iteration the work
item is currently assigned to.
It will take into account the value you enter for Days past end date of iteration after which work is late.
Days past end date of iteration after which work is late: Specify a number of days past which a work
item is considered late if it's status is still new or in progress. For example, entering 3 days will give the
team 3 days after the end of an iteration to mark work items complete or done, before they are considered
late.
6. Click Save when done. The following image shows Velocity based on Story Points and 8 sprints of data.
Work with the built-in team velocity chart

Velocity provides a useful metric for gaining insight into how much work your team can complete during a sprint
cycle. Each team is associated with one and only one velocity chart.
Velocity will vary depending on team capacity, sprint over sprint. However, over time, the velocity should indicate
a reliable average that can be used to forecast the full backlog.
NOTE
The images you see from your web portal may differ from the images you see in this topic. These differences result from
updates made to VSTS or your on-premises TFS, options that you or your admin have enabled, and which process was
chosen when creating your team projectAgile, Scrum, or CMMI. However, the basic functionality available to you remains
the same unless explicitly mentioned. For an overview of changes in the navigation experience and working within the user
and administration contexts, see Work in the web portal.
1. From the backlog page, open the velocity chart.

For charts to appear, your team must perform these activities:
Select sprints for your team
Assign backlog items to sprints
Estimate backlog items by defining the Effort, Story Points, or Size.
2. The chart tracks your estimated backlog work (sum of Effort, Story Points, or Size) that your team has
completed (green) in the previous sprints, or that are still in progress (blue).
As this chart shows, velocity will fluctuate from sprint-to-sprint for a variety of reasons. However, you can
quickly determine the average velocity by averaging the values shown in green for each sprint. You can
then plug the average into the Forecast tool.
NOTE
Work items based on the Scrum process get counted in the chart once their State is set to Committed, whereas
items based on the Agile and CMMI processes get counted once their State is set to Active. This behavior is set
through the workflow states to category state mappings.
Required and recommended activities
For your team to gain the greatest utility from the velocity chart or velocity widget, follow these required and
recommended tasks.
Required:
Define sprints for the team project - Sprints should be of the same duration.
Select sprints for each team
Define and estimate backlog items. If you work from your team's backlog, the items you create will
automatically be assigned to the current sprint (Iteration) and to your team's default Area Path.
Update the status of backlog items once work starts and when completed. Only backlog items whose State
maps to a metastate of In Progress or Done will show up on the velocity chart or velocity widget.
Recommended:
Define and size backlog items to minimize variability.
Determine how your team wants to treat bugs. If your team chooses to treat bugs like requirements, bugs will
show up on the backlog and be counted within the Velocity chart and forecasting.
Set your team's area path. The forecast tool will forecast those items based on your team's default settings.
These settings can specify to include items in area paths under the team's default or exclude them.
Don't create a hierarchy of backlog items and bugs. The Kanban board, sprint backlog, and task board only
show the last node in a hierarchy, called the leaf node. For example, if you link items within a hierarchy that is
four levels deep, only the items at the fourth level appear on the Kanban board, sprint backlog, and task board.
Instead of nesting requirements, bugs, and tasks, we recommend that you maintain a flat listonly creating
parent-child links one level deep between items. Use Features to group requirements or user stories. You can
quickly map stories to features, which creates parent-child links in the background.
At the end of the sprint, update the status of those backlog items that the team has fully completed. Incomplete
items should be moved back to the product backlog and considered in a future sprint planning meeting.
Try this next

Velocity guidance
Add other teams
If you work with several teams, and each team wants to work with their own backlog view, velocity chart, and
forecast tool, you can add teams. Each team then gets access to their own set of Agile tools. Each Agile tool filters
work items to only include those whose assigned area paths and iteration paths meet those set for the team.
Sprint burndown

Throughout your sprint, you can monitor the sprint burndown chart to determine if your team is on track to
complete its sprint plan.
Use this topic to learn
How to view current and past sprint burndowns
Required and recommended activities to support sprint burndown
For usage guidance, see Burndown guidance.
NOTE
The system automatically builds a sprint burndown chart based on the tasks and Remaining Work estimates you define and
update throughout the sprint cycle. For details, see Sprint planning and Task board. To open the sprint burndown chart,
jump to the section Open sprint burndown chart.
A healthy sprint burndown chart will

look something like this. The Ideal
Trend line connects the two points:
- (1) Team's total capacity at the start of
the sprint
- (2) 0 Remaining Work at the end of the
sprint.
The slope represents the rate at
which the team needs to burn down
work to finish the sprint on time.
The actual graph, the blue area,
represents the total amount of
planned sprint work and how it
changes throughout the course of
the sprint. The blue area corresponds
to the sum of all Remaining Work set
for all sprint tasks, and possibly bugs,
that have the current sprint as their
iteration path.
Open sprint burndown chart

Click the chart to display it in a larger view.
NOTE
You can't add the system-generated sprint burndown chart to a dashboard. However, you can add the Sprint burndown
widget, which captures the same information for the current sprint, to a dashboard.
In particular you can review your sprint burndown charts to show the team patterns in execution. The burndown
charts maintain a record of the team's ability to plan and estimate.
SPRINT 1 SPRINT 2 SPRINT 3
Teams may find it useful to review this record periodically during their sprint retrospectives. It may spark useful
discussions and lead to setting one or more sprint goals, such as:
How does our projected velocity match up to our actual velocity?
How can we more accurately determine how much we will be able to accomplish in a sprint?
How can we complete work at a more regular pace throughout the sprint?
Required and recommended activities

In order to access the sprint burndown chart and use it to monitor your sprint progress, your team must perform
the following actions.
Required:
Schedule sprints for your team.
Define and estimate tasks for each product backlog item you're working on in 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.
Update Remaining Work for each sprint task as work progresses.
Recommended:
Define tasks that take a day or less to complete to lessen the impact of poor estimates.
Don't divide tasks into subtasks. 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.
Update Remaining Work daily or several times within a week to support monitoring and achieve a smoother
burndown chart.
At the end of the sprint, update the task status of completed tasks and determine how to handle incomplete
tasks.
Current and past sprint burndown charts

As you complete each sprint, the system maintains a history of your activity. You can always review past sprints
and sprint burndown charts by choosing the sprint listed under the Past section.
Try this next

In addition to the sprint burndown chart, teams can review the velocity at which they work sprint over sprint. The
velocity chart tracks how many backlog items your team works on in a sprint.
You can use your team velocity as input into the forecast tool to help plan your sprints.
Related notes
You can learn more about defining, planning, and executing your sprints from these topics:
Schedule sprints
Sprint planning
Task board
And, from these industry resources:
Understanding the Scrum Burndown Chart
Task sizing in Agile software development
For on-premises TFS deployments, you can specify the format that appearsh for hours or d for daysfor the
remaining work field.
Empty sprint burndown chart
If your sprint burndown chart appears empty, check the following:
Have you assigned tasks to the sprint associated with the chart?
Have you assigned remaining work to the tasks assigned to the sprint?
Are the parent work items of the tasks assigned to the same sprint? If not, the tasks may appear in another
sprint associated with the parent item.

You use cumulative flow diagrams (CFD) to monitor the flow of work through a system. The two primary metrics
to track, cycle time and lead time, can be extracted from the chart. Or, you can add the Lead time and cycle time
control charts to your dashboards (VSTS only at this time).
To configure or view CFD charts, see Configure a cumulative flow chart.
Sample charts and primary metrics

The Continuous flow CFD provides Continuous flow CFD
the chart most favored by teams that
follow a lean process.
However, many teams have begun
combining lean practices with Scrum
or other methodologies which means
they practice lean within the span of
an iteration or sprint. In this situation
the diagram takes on a slightly
different look and provides two
additional, and very valuable, pieces of
information as shown in the next
chart.
The Fixed period CFD shown here is Fixed period CFD for a completed sprint
for a completed sprint.
The top line represents the scope set
for the sprint. And, because the work
must be completed by the last day of
the sprint, the slope of the Closed
state indicates whether or not a team
is on track to complete the sprint. The
easiest way to think of this view is as
a burnup chart.
The data is always depicted with the
first step in the process as the upper
left and the last step in the process as
the bottom right.
Chart metrics
CFD charts display the count of work items grouped by state/Kanban column over time. The two primary metrics
to track, cycle time and lead time, can be extracted from the chart.
METRIC DEFINITION
Cycle Time 1 Measures the time it takes to move work through a single process or workflow state, calculated by the
start of the given process to the start of the subsequent process.
Lead Time 1 For a continuous flow process: measures the amount of time it takes from when a request is made (such
as adding a proposed user story) until that request is completed (closed).
For a sprint or fixed period process: measures the time from when work on a request begins until the
work is completed (i.e. the time from Active to Closed).
Work in Progress Measures the amount of work or number of work items that are actively being worked.
Scope Represents the amount of work committed for the given period of time. Only applies to fixed period
processes.
Note:
1. The CFD widget (Analytics Service) and built-in CFD chart (work tracking data store) do not provide discrete
numbers on Lead Time and Cycle Time. However, the Lead Time and Cycle Time widgets do provide these
numbers.
There is a very tight, well defined correlation between Lead Time/Cycle Time and Work in Progress (WIP). The
more work in progress, the longer the cycle time which leads to longer lead times. The opposite is also truethe
less work in progress, the shorter the cycle and lead time is because the development team can focus on fewer
items. This is a key reason why you can and should set Work In Progress limits on the Kanban board.
The count of work items indicates the total amount of work on a given day. In a fixed period CFD, a change in this
count indicates scope change for a given period. In a continuous flow CFD, it indicates the total amount of work in
the queue and completed for a given day.
Decomposing this work into specific Kanban board columns provides a view into where work is in the process. This
provides insights on where work is moving smoothly, where there are blockages and where no work is being done
at all. It's difficult to decipher a tabular view of the data, however, the visual CFD chart provides clear evidence that
something is happening in a given way.
Identify issues, take appropriate actions

The CFD answers several specific questions and based on the answer, actions can be taken to adjust the process to
move work through the system. Let's look at each of those questions here.
Will the team complete work on time?
This question applies to fixed period CFDs only. You gain an understanding of this by looking at the curve (or
progression) of work in the last column of the Kanban board.
In this scenario it may be appropriate to reduce the scope of work in the iteration if it's clear that work, at a steady
pace, is not being completed quickly enough. It may indicate the work was under estimated and should be factored
into the next sprints planning.
There may however be other reasons which can be determined by looking at other data on the chart.
How is the flow of work progressing?
Is the team completing work at a steady pace? One way to tell this is to look at the spacing between the different
columns on the chart. Are they of a similar or uniform distance from each other from beginning to end? Does a
column appear to flat-line over a period of multiple days? Or, does it seem to "bulge"?
Two problems show up visually as flat lines and as bulges.
Flat lines appear when the team doesn't update Flat lines
their work with a regular cadence. The Kanban
board provides the quickest way to transition work
from one column to another.
Flat lines can also appear when the work across
one or more processes takes longer than planned
for. For this to occur, flat lines must appear across
many parts of the system because if only one part
of the system or two parts of a system have
problems then you'll see a bulge.
Bulges occur when work builds up in one part of Bulges

the system and it isn't moving through a process.
An example of this may be that testing is taking a
long period of time but development is taking a
short period of time therefore work is accumulating
in the development state (bulges indicate that a
succeeding step is having a problem, not
necessarily the step in which the bulge is
occurring).
Mura, the lean term for flat lines and bulges, means unevenness and indicates a form of waste (Muda) in the
system. Any unevenness in the system will cause bulges to appear in the CFD.
Monitoring the CFD for flat lines and bulges supports a key part of the Theory of Constraints project management
process. Protecting the slowest area of the system is referred to as the drum-buffer-rope process and is part of
how work is planned.
How do you fix flow problems?
You can solve the problem of lack of timely updates through daily stand-ups, other regular meetings, or
scheduling a daily team reminder email.
Systemic flat-line problems indicate a more challenging problem (although you should rarely if ever see this). This
problem means that work across the system has stopped. This may be the result of process-wide blockages,
processes taking a very long time, or work shifting to other opportunities that aren't captured on the board.
One example of systemic flat-line can occur with a features CFD. Feature work can take much longer than work on
user stories because features are composed of several stories. In these situations, either the slope is expected (as in
the example above) or the issue is well known and already being raised by the team as an issue, in which case,
problem resolution is outside the scope of this topic to provide guidance.
Teams can proactively fix problems that appear as CFD bulges. Depending on where the bulge occurs, the fix may
be different. As an example, let's suppose that the bulge occurs in the development process because running tests
is taking much longer than writing code, or testers are finding may be finding a large number of bugs and
continually transition the work back to the developers so the developers have a growing list of active work.
Two potentially easy ways to solve this problem are: 1) Shift developers from the development process to the
testing process until the bulge is eliminated or 2) change the order of work such that work that can be done
quickly is interwoven with work that takes longer to do. Look for simple solutions to eliminate the bulges.
NOTE
Because many different scenarios can occur which cause work to proceed unevenly, it's critical that you perform an actual
analysis of the problem. The CFD will tell you that there is a problem and approximately where it is but you must investigate
to get to the root cause(s). The guidance provided here indicate recommended actions which solve specific problems but
which may not apply to your situation.
Did the scope change?

Scope changes apply to fixed period CFDs only. The top line of the chart indicates the scope of work because a
sprint is pre-loaded with the work to do on the first day, this becomes a set level of work. Changes to this top line
indicate worked was added or removed.
The one scenario where you can't track scope changes with a CFD occurs when the same number of works are
added as removed on the same day. The line would continue to be flat. This is the primary reason why several
charts should be used in conjunction with one another to monitor for specific issues. For example, the sprint
burndown chart can also show scope changes.
Too much work in progress?
You can easily monitor whether WIP limits have been exceed from the Kanban board. However, you can also see
monitor it from the CFD.
Not so oddly, a large amount of work in progress usually shows up as a vertical bulge. The longer there is a large
amount of work in progress, the bulge will expand to become an oval which will indicate that the work in progress
is negatively affecting the cycle and lead time.
A good rule of thumb for work in progress is that there should be no more than two items in progress per team
member at any given time. The main reason for two items versus stricter limits is because reality frequently
intrudes on any software development process.
Sometimes it takes time to get information from a stakeholder, or it takes more time to acquire necessary
software. There are any number of reasons why work might be halted so having a secondary item to switch to
provides a little bit of leeway. If both items are blocked, it's time to raise a red flag to get something unblocked
not just switch to yet another item. As soon as there are a large number of items in progress, the person working
on those items will have difficulty context switching, are more likely to forget what they were doing, and likely
incur mistakes.
Lead time versus cycle time

The diagram below illustrates how lead time differs from cycle time. Lead time is calculated from work item
creation to entering a Completed state. Cycle time is calculated from first entering an In Progress state to entering
a Completed state.
Illustration of lead time versus cycle time
If a work item enters a Completed state and then is reactivated and moved out of that state, then any additional
time it spends in a Proposed/In Progress state will contribute to its lead/cycle time when it enters a Completed
state for the second time.
If your team uses the Kanban board, youll want to understand how your Kanban columns map to workflow states.
For more information on configuring your Kanban board, see Add columns.
To learn more about how the system uses the state categoriesProposed, In Progress, and Completedsee
Workflow states and state categories.
Plan using estimate delivery times based on lead/cycle times

You can use the average lead/cycle times and standard deviations to estimate delivery times.
When you create a work item, you can use your teams average lead time to estimate when your team will
complete that work item. Your teams standard deviation tells you the variability of the estimate. Likewise, you can
use cycle time and its standard deviation to estimate the completion of a work item once work has begun.
In the following chart, the average cycle time is 8 days. The standard deviation is +/- 6 days. Using this data, we can
estimate that the team will complete future user stories about 2-14 days after they begin work. The narrower the
standard deviation, the more predictable your estimates.
Example Cycle Time widget
Identify process issues
Review your teams control chart for outliers. Outliers often represent an underlying process issue. For example,
waiting too long to complete pull request reviews or not resolving an external dependency in a timely manner.
As you can see in the following chart, which shows several outliers, several bugs took significantly longer to
complete than the team's average. Investigating why these bugs took longer may help uncover process issues.
Addressing the process issues can help reduce your team's standard deviation and improve your team's
predictability.
Example Cycle Time widget showing several outliers
You can also see how process changes affect your lead and cycle time. For example, on May 15th the team made a
concerted effort to limit the work in progress and address stale bugs. You can see that the standard deviation
narrows after that date, showing improved predictability.
Try this next

Configure your cumulative flow charts Configure a lead time or cycle time chart
Velocity metrics and usage guidance

Velocity provides a useful metric for these activities:
Support sprint planning
Forecast future sprints and the backlog items that can be completed
A guide for determining how well the team estimates and meets their planned commitments
And, with the velocity widget, you can quickly determine the following:
Planned velocity
Actual (completed) velocity
Work completed later than planned
Amount of work not completed
To configure or view Velocity charts, see Configure and view Velocity charts.
The velocity chart requires that teams estimate their backlog items with a number using the Effort, Story Points, or
Size fields.
The velocity widget allows teams to track velocity based on the count of backlog items or with estimates for the
the Effort, Story Points, or Size fields.
Minimize variability in your estimates

Estimates, by their nature, don't reflect reality. They represent a best guess by the team as to the effort required to
complete an item, relative to the effort of other items on the backlog.
By minimizing the size variability of your backlog items, you help strengthen the team's ability to create more
accurate estimates. Variability increases uncertainty. By minimizing the variability of your estimates, you increase
the likelihood of more reliable velocity metrics and forecast results.
Velocity is not a KPI

While velocity provides a measure of a team's ability to deliver work over time, you shouldn't confuse it as a key
performance indicator of the team.
Velocity simply provides an aid to determine team capacity. Nothing more, nothing less. Asking a team to increase
their velocity, basically asks them to accomplish more with the same resources. This request will mostly likely lead
to "Story points inflation" and lead to less desirable outcomes.
Other types of velocity charts

While the velocity chart provides a measure of Effort, Story Points, or Size that gets completed sprint-over-sprint,
there may be other types of velocity that you may want to track. You can create similar charts by creating a work
item query and chart the count of or sum of items.
For example, you can create a chart of the number of Product backlog items and bugs completed for the last
several sprints. For examples on creating this type of chart, see Query by numeric fields.
Try this next
Configure or view velocity chart Forecast your sprints Plan your sprint.
Industry resources
How Should We Use Velocity?
Velocity Is Not the Goal
How to Calculate and Use Velocity to Help Your Team and Your Projects
Add other teams
If you work with several teams, and each team wants to work with their own backlog view, velocity chart, and
forecast tool, you can add teams. Each team then gets access to their own set of Agile tools. Each Agile tool filters
work items to only include those whose assigned area paths and iteration paths meet those set for the team.
Burndown guidance

Review your sprint burndown chart throughout your sprint cycle to check for these indicators:
Is remaining work getting updated regularly? Flat spaces within the blue area indicate a lack of updates.
Is remaining work increasing instead of decreasing? Increases can indicate unestimated or unplanned work.
Both signal a need for the team to discuss how they'll complete the sprint tasks on time.
Based on the actual burn rate, does the team feel confident that they'll complete the work by the end of the
sprint?
To configure or view sprint burndown charts, see Sprint burndown.
Scope management
By estimating remaining work of tasks for each product backlog item, teams have a good understanding of what
they can accomplish within a sprint. Because the sprint tasks represent the overall sprint scope, the sprint scope is
well defined. Anything that is not represented by a task in the sprint should be considered out of scope for the
sprint.
As the team makes progress, divergences from the ideal trend line help the team monitor divergences from scope.
Increases instead of decreases within

the blue graph may indicate:
Poor estimates made to tasks
Discovery of new work not
accounted for in sprint planning
Scope creep, additional work not
agreed to by the team.
Whatever the cause, teams should
come together quickly to determine
how to remedy the increased
workload.
Solutions may include reassigning
tasks or recruiting additional
resources. The team should move all
non-essential sprint work to the
backlog and consider it during the
next sprint planning meeting.
Mitigate risk through daily inspection

Your burn-down chart shows you if your project is on schedule. A daily check can mitigate risks and provide early
warning of potential schedule or cost overruns, two metrics associated with traditional project management.
For example, when the actual
remaining work (blue area) goes flat
for a period of time, or remains high
above the ideal trend line, the team is
at risk of not meeting their sprint
commitments.
Teams should meet immediately to
course correct and either reassign
work, recruit more resources, or reset
expectations.
Try this next

In addition to the sprint burndown chart, teams can review the velocity at which they work sprint over sprint. The
velocity chart tracks how many backlog items your team works on in a sprint.
You can use your team velocity as input into the forecast tool to help plan your sprints.
Industry resources:
Understanding the Scrum Burndown Chart
Task sizing in Agile software development
VSTS | TFS 2018 | TFS 2017 | TFS 2015.1-2015.3

All charts listed in the following table are available from VSTS and TFS 2017.2 and later versions. You can add them
to a dashboard from the widget catalog or directly from the Build, Release, Test, or Work hubs. For TFS 2015 and
earlier versions, some charts require you to add them to a team dashboard from their respective hub.
CHART TFS 2015 TFS 2015.1 TFS 2015.2 TFS 2017.1
Build history chart 1
Release summary chart 1
Test status or result chart 2
Test quality trend chart 1
Work item query 2
Work item query chart 2
1. These charts are configured by the system. You can't edit them.
2. These charts are user-configurable.
NOTE
Required permissions: You must be a team admin to add a chart to a team dashboard or homepage, or be granted
permissions to manage a dashboard. Or, if you're a member of the Project Administrators group, you can add charts to any
team's dashboards or home page.
Add a build history chart

NOTE
Feature availability: This chart is supported from VSTS and TFS 2015.1 and later versions. With VSTS and later versions of
TFS, you can also add it to a team dashboard from the widget catalog.
Each time a build is run, it logs information about the build, including the run time, errors and warnings, and
whether it successfully completed or failed.
1. Select your team context and then open the Build hub to add a build history chart to a team dashboard.
If you aren't a team administrator, get added as one. The Add to dashboard menu selection is disabled when
you don't have permissions to add it to the dashboards of the selected team context.
2. Build summary charts look like this:
Hover over a bar to view build information and run time. Click a bar to go to the build summary page.
Add a release summary chart

NOTE
Feature availability: This chart is supported from VSTS and TFS 2017.1 and later versions. You can also add it to a team
dashboard from the widget catalog.
Each time a release is deployed, it logs information about the release to each of its environments. You can add a
release tile to your team dashboard to monitor release progress and gain quick access to each release.
1. Select your team context and then open the Release hub to add a release definition chart to a team
dashboard.
If you aren't a team administrator, get added as one. The Add to dashboard menu selection is disabled when
you don't have permissions to add it to the dashboards of the selected team context.
2. Release definition charts show the success (green), in progress (blue), cancellation (red), or non-deployment
(grey) to an environment for the current and last four releases:
Add a test status or result chart

NOTE
Feature availability: This feature is supported from VSTS and TFS 2015. From VSTS, you can add a Chart for test plans
widget to a dashboard.
As you create and run tests, you can track your status by defining lightweight charts of test plans and test results.
1. Select your team context, make sure you're a team admin, and if you haven't yet created the dashboard, do
that now.
2. Open the Test hub charts page and select the dashboard to add the test chart to.
Add a test quality trend chart

NOTE
Feature availability: This chart is supported from VSTS and TFS 2015.2 or later versions. From VSTS and TFS 2017 and later
versions, you can add a test result trend chart widget to a dashboard.
You can add trends to the dashboard of the failures and duration of those tests that were run as part of a build.
1. Select your team context, make sure you're a team admin, and if you haven't yet created the dashboard, do
that now.
2. Open a build summary for a build definition to which you've added tests, open the Tests page, and click the
bar chart for either Test failures or Test duration.
3. Click the Actions menu and choose the dashboard to add the chart to.
Learn more about reviewing automated test results after a build.
Add a work item query or chart

NOTE
Feature availability: This feature is supported from VSTS or TFS 2015. With VSTS, you can add a work item query chart
widget to a team dashboard.
You add work item queries and charts to a dashboard from the Queries page. Queries and charts must be
associated with queries under the Shared queries folder.
1. First, make sure you have selected your team context. Only those dashboards created for a team appear in
the context menu for each query or chart. Switch team context as needed.
2. If you aren't a team administrator, get added as one. Only team and project admins can add and customize
team dashboards.
3. If you haven't yet created the dashboard, do that now.
4. From the charts Actions menu, choose the team dashboard.
You can only add charts associated with shared queries. Charts associated with queries under My Queries
folder won't display the add to dashboard option.
Add a markdown file to a dashboard

NOTE
Feature availability: Adding a Markdown file to a team dashboard is available from VSTS and the web portal for TFS 2015.3
and later versions.
Open the Markdown file defined in your repository and make sure you are in your team context.
Click Add to dashboard, and then choose the team dashboard to add the markdown file to. As you update the
Markdown file, changes will automatically appear on the dashboard upon refresh. See Dashboards for more info.
Markdown widgets
Use these widgets to support your team and stakeholders by adding information such as:
Team goals
Provide links to team backlogs or boards, metrics, or other items located in a network share such as a OneNote,
SharePoint site or wiki pages
Important dates or target deadlines
Here's an example:
NOTE
For information on how to specify relative links from a Welcome page or Markdown widget, see Source control relative links.
To edit a markdown widget, you must be a team admin or a member of the Project Administrators group. To be
added as a team admin, go here.
System-generated work tracking charts

There are a number of system-generated charts that you can access from the web portal, but can't add to a
dashboard. However, you may find a comparable widget listed in the widget catalog that tracks the same or similar
data which you can add to the dashboard. These include:
Team velocity
Sprint burndown chart (see Sprint burndown widget)
Cumulative flow (see CFD widget)
Track progress by creating status and trend query-
based charts

You can quickly view the status of work in progress by charting the results of a flat-list query. You can create
several types of chartssuch as pie, column, or trendfor the same query. Charts support viewing a count of
work items or a sum of values for select numeric fields, such as Remaining Work or Original Estimate.
NOTE
For examples of queries based on numeric fields, see Query by numeric fields. For information on creating charts that track
test progress and results, see Track test status.
For example, the following image illustrates four different charts created from the same flat-list query. The pie
chart groups the 146 active bugs by priority, and the bar chart groups the bugs by team and their triage status.
The last two chart show two different views of the active bugs as they trend over the last two weeks.
Add and configure a query-based chart
1. From the Queries page, open the chart editor for a flat list query. You must belong to the Contributors
group to create charts. Stakeholders can view charts but not create them.
2. Select the chart type and field for grouping values. When you use pie, bar, and column charts, select a single
field to view a count of work items.
If you don't see the field you want in the Group by drop-down list, add the field as a column to the query
and save the query. You can group by any field except date-time and free-form text fields. For example:
To group by iterations, include the Iteration Path in the query or column options
To group by team, include the Area Path or Node Name in the query or column options
To group by a custom field, include it in a query clause or column options (See Customize your work
tracking experience to learn about adding a custom field)
If you receive an error message when you close the chart editor, you need to request Basic access.
3. To sort the results, choose value or label as the sort option and then ascending or descending.
4. To change a color, simply click a color on the chart and pick a new color from the color picker.
Charts automatically update when you edit the query or refresh the query results.
Stacked bar chart
A stacked bar chart lets you track progress against two field values. Node Name will display the last leaf within the
hierarchy of area paths. Use this when you want to show data across teams.
Trend chart
Trend charts let you view progress for the last one, two, or four weeks.
Burndown chart
Choose the Sum operator for Remaining Work to view a burndown chart of tasks.
Add a chart to a team dashboard
Select your option from the chart's context menu.
To add a chart to your team's home page, you must be a team administrator. You can only add charts defined for
shared queries.
To add other types of charts, such as test results and build summary charts, see Add widgets and chart to a
dashboard.
NOTE
Feature availability: For on-premises TFS 2015, you can pin charts to the team homepage. From VSTS or TFS 2015.1, you
can add charts to multiple team dashboards and get access to the widget catalog.
Add chart widget to a dashboard

NOTE
Feature availability: The widget, Chart for Work Items, is available from VSTS or TFS 2015.2 or later version. You add it to
a team dashboard from the widget catalog.
If you've already defined your flat list query, you can add and configure a chart to a team dashboard using the
Chart for work items widget.
1. From the web portal for VSTS, open the team dashboard you want to add the chart to.
2. Click to modify a dashboard, and then click to access the widget catalog.
If you don't see these icons, then you need to be added as a team administrator or a member of the Project
Administrators group.
3. Choose the Chart for work items widget and then click Add.
4. Click the widget's or the configure icon to open the configuration dialog.
5. Give the chart a title, select the flat list query on which the chart is based, and choose the chart type.
Based on your chart type, specify values for the remaining fields. Change a chart color simply by choosing
another color from those shown.
NOTE
All rules for configuring charts described previously in this topic apply to configuring the chart for work items widget.
6. After you save your changes, you'll see the new chart has been added to the dashboard.
7. Drag the tile anywhere on the dashboard to put it where you want it.
8. When you're finished with your changes, click to exit dashboard editing.
Related notes
Now you know how to create status and trend charts for work items. A few things to keep in mind...
To create similar charts for tests, see Track your test results
Charts you create for queries that are saved under Shared Queries are viewable by all team members and can
be added to team dashboards or pinned to a team homepage
Charts that you create for queries under your My Queries folder are visible only to you
You can copy and email the URL of any chart page to share it with a team member
For additional examples of charts created from numeric fields, see Query by a numeric field.
Also, from the web portal, you can view the following charts:
Cumulative flow diagram
Team velocity
Sprint burndown charts
Test progress and test results
Add widgets and chart to a dashboard
Widget catalog charts
NOTE
The images you see from your web portal may differ from the images you see in this topic. These differences result from
updates made to VSTS or your on-premises TFS, options that you or your admin have enabled, and which process was
chosen when creating your team projectAgile, Scrum, or CMMI. However, the basic functionality available to you remains
the same unless explicitly mentioned. For an overview of changes in the navigation experience and working within the user
and administration contexts, see Work in the web portal.
Requirements to view and create charts

If you have Stakeholder access or license, you can only view charts. If you need to create charts, ask your project
admin or account owner to grant you elevated access.
Fields that show up in the chart editor
For fields to appear in the chart editor, you must add the field to either the query filter criteria or a displayed
column.
You can't select fields for groupings that aren't supported, such as ID, Title, Tags, date-time fields, Description,
Repro Steps, and other HTML and long text fields.
Charts and the display of areas and iterations
When you select Area Path or Iteration Path, only the leaf node appears in the chart. The leaf node is the last
node of the full path. For example, Phone is the leaf node of FabrikamFiber/Fabrikam Website/Phone . If your query
contains a mixed level of leaf nodes, your chart might not reflect expected results.
Use Node Name , the area path leaf node, to see if that improves your results.
Charts display in browsers that support Scalable Vector Graphics (SVG). This includes Internet Explorer 9 and
Internet Explorer 10, Chrome, Firefox and Safari on Mac. Charts have not been optimized for mobile or touch
displays.
Why some charts don't show all the field values in the results
When a chart contains more than seven items within the data series, values in the eight-plus items are
consolidated into a set labeled "other"?
Additional charts (TFS )

If your team project has a project portal and SharePoint site configured, you can access several Excel charts.
These include charts to monitor code quality, testing, and bug tracking activity.
If your team project has SQL Server reports added, you can access several reports that include status and trend
activities. If you need to add reporting, see Add reports to a team project.
If your team project has reporting services added, you can create an Excel chart from a work item query.
Query-based charts versus Excel-generated PivotCharts (TFS )
Query-based charts generate data from the work item tracking data store and therefore displays the most recent
data. Excel PivotCharts access data published to the Analysis Services cube, which is refreshed every two hours by
default. Also, Excel PivotCharts are only available to users of an on-premises TFS.
Track test status
VS 2017 | VS 2015 | VSTS | TFS 2018 | TFS 2017 | TFS 2015

Quickly view the status of your testing using lightweight charts. For example, find out how many test cases are
ready to run, or how many tests are passing and failing in each test suite. You can pin these charts to your home
page, then all the team can see the progress at a glance.
Track testing progress

Use test results charts to track how your testing is going. Choose from a fixed set of pre-populated fields related
to results. By default, a pie chart is created for each test plan. This chart is grouped by the outcome field to show
the latest results for all the tests in the test plan.
View this default chart from the Charts tab.
Add your own charts for test results to visualize what's important for your team. If you already know how to add a
chart, jump to the examples below of charts that you can create.
1. Select the test plan or test suite for your chart in the Test plan tab. Then create a new chart.
2. Select the chart type. Based on the chart, configure the fields that you want to use to group by, or for rows
and columns.
All charts roll up the information for any child test suites of the test plan or test suite that you selected.
3. Save the chart. Now it will be displayed in the charts tab for the test plan or test suite that you selected.
Test results examples
What's the test status for a specific test suite?
Select the test suite from the Test plan tab and add a test results pie chart. Group by outcome.
What's the test status for user stories that my team's testing this sprint?
If you have created requirement-based test suites in your test plan for your user stories, you can create a chart for
this.
1. Group these requirement-based test suites together in a static test suite.
2. Select this static test suite in the Test plan tab.
3. Add a test results stacked bar chart. Choose Suite as the rows pivot and Outcome as the columns pivot.
How many tests has each tester left to run?

Select your test plan from the Test plan tab and add a test results pivot table chart. Choose Tester as the rows
pivot and Outcome as the columns pivot.
How can I check quality based on the configuration?

Use either a stacked bar chart or a pivot table chart. Choose Configuration as the rows pivot and Outcome as the
columns pivot.
How can I track why tests are failing for my team?
For failure analysis, use either a stacked bar chart or a pivot table chart. Choose Tester for the rows and Failure
type for the columns. (Failure type for test results can only be set using Microsoft Test Manager.)
How can I track the resolution for failing tests for my team?
For resolution analysis, use either a stacked bar chart or a pivot table chart. Choose Tester for the rows and
Resolution for the columns. (Resolution type for test results can only be set using Microsoft Test Manager.)
Track test case status

Use test case charts to find out the progress of your test case authoring. The charts for test cases give you the
flexibility to report on columns that you add to the Tests tab. By default, test case fields are not added to the view
in the Tests tab.
If you already know how to add a chart, jump to the examples below of charts that you can create for test cases.
1. Add any fields you want to use for your test case chart from the Tests tab with Column options. Then the
fields will appear as choices in the drop-down lists for grouping for your test case charts.
2. Select the test plan or test suite for your chart in the Test plan tab. Then add a test case chart.
All charts roll up the information for any child test suites of the test plan or test suite that you selected.
3. Select the chart type. Based on the chart, configure the fields that you want to use to group by, for rows and
columns, or the range (trend charts only).
You can't group by test suite for the test case charts.
4. Save the chart. Now it will be displayed in the charts tab for the test plan or test suite that you selected.
Test case examples
How can I track burndown for test case creation?
Use a stacked area trend chart to view the burndown for how many test cases are ready to be run. Choose State
for the stack by field and Ascending for the sort field.
How can I track burndown for automation status?

Use a stacked area trend chart to view the burndown for how many test cases have been automated. Choose
Automation status for the stack by field and Ascending for the sort field.
If multiple teams own test cases in my test plan, can I see how many each team owns and the priorities
of the tests?
If your teams are organized by area path, then your can use a test case pie chart. Choose Area path for the group
by field.
If you want to know the priorities of these tests, then create a stacked bar chart. Choose Area path for rows and
priority for the columns.
How can I track test creation status by team members?
Test case owners are tracked by the Assigned to field. Use a stacked bar chart or a pivot table chart. Choose
Assigned to for rows and status for the columns.
Share charts on your team's dashboard

Pin a chart to your team's dashboard for all the team to view. Use the chart's context menu.
You can configure the dashboard widget to show a range of chart types. You must be a team administrator to do
this, but team members with Stakeholder access can view the charts on the dashboard.
Learn more about dashboards. Or learn more about team administration.
See also
FAQs for manual testing
Next step
Control how long to keep test results

VSTS | TFS 2018 | TFS 2017.1
NOTE
Feature availability: For VSTS and TFS 2017.1 and later versions, you can set dashboard permissions.
As a team admin you can set dashboard permissions for your team. As a member of the Project Administrators
group, you can set dashboard permissions for all teams.
From the Permissions tab you can grant or restrict permissions to your team members to edit and manage your
team dashboards. The default setting provides all team members permissions to edit and manage dashboards.
Related notes
Add a team administrator
Widget catalog
VSTS | TFS 2018 | TFS 2017 | TFS 2015.1-2015.3

Widgets display information and charts on dashboards. Many of them are configurable and display information
available from one or more data stores or charts maintained within the system.
To add a widget to a dashboard or copy a widget from one dashboard to another, see Add a widget to a
dashboard.
NOTE
Feature availability: You can access the widget catalog from VSTS or the web portal for TFS 2015.1 or later version. All
widgets listed below are available from the web portal for VSTS. Some widgets listed below are only available when you
connect to TFS 2015 Update 2 or later version.
With TFS 2015, you have access to a single team dashboard with which you can pin items but can't add widgets to the
dashboard. Install TFS 2015 Update 1 or later version to get access to the widget catalog and multiple team dashboards.
To determine the platform and version you're on, see Provide product and content feedback, Platforms and version
support.
User-focused and team-scoped widgets

User-focused widgets display information based on the logged-in user.
Team-scoped widgets display data based on the selected team context.
Code
Code tile
Adds a configurable tile to display the summary of a code folder or Git repository. To configure, simply click the
added tile, select a repository, select a branch (Git only) and select a path. The code tile supports both TFVC and
Git repositories.
Pull request (user-focused or team-scoped)

NOTE
Feature availability: Available from VSTS or TFS 2015.2 or later version.
Adds a configurable tile to display active pull requests requested by the team, or assigned to or requested by
the person logged in. Select the Git repository for the pull requests of interest.
You need to add a widget for each Git repository of interest. To learn more about pull requests, see Review code
with pull requests.
Plan and track work

Assigned to me (user-focused)
NOTE
Feature availability: You can access this widget from VSTS and TFS 2017.
Displays the list of work items currently assigned to the currently logged in user. The list ignores closed or
deleted work items.
Burndown chart
NOTE
Feature availability: This widget is available for VSTS. To add it to your dashboard, you first need to install the Analyics
Marketplace extension. You can then add the widget(s) to your dashboard. You must be an account owner or a member
of the Project Collection Administrator group to add extensions.
Adds a tile that displays a burndown chart which you can configure to span one or more teams, work item
types, and time period. With it, you can create a release burndown, sprint burndown, or any burndown that
spans teams and sprints. To learn more, see Configure a Burndown or Burnup widget.
Burnup chart
NOTE
Adds a tile that displays a burnup chart which you can configure to span one or more teams, work item types,
and time period. With it, you can create a release burnup, sprint burnup, or any burnup that spans teams and
sprints. To learn more, see Configure a Burndown or Burnup widget.
Chart for work items
NOTE
Feature availability: You can access this widget from VSTS or TFS 2015.2 or later version. For TFS 2015.1 and earlier
versions, see Add charts to a dashboard to add shared query charts to a dashboard.
Adds a tile to display a progress or trend chart that builds off a shared work item query.
From the configuration dialog, select a shared query and specify the chart type and values.
Cumulative flow diagram (team-scoped)
NOTE
Displays the cumulative flow of backlog items based on the time frame, team, backlog level and swimlane you
select.
From the configuration dialog, specify the team, backlog level, and other parameters you want.
Hover over each color within the chart to see the count of items for a particular Kanban column.
Cycle time (team-scoped)
NOTE
Displays the cycle time of work items closed in a specified timeframe for a single team and backlog level. The
cycle time of a work item is defined as the time taken to close a work item after work on it has started.
Each marker on the chart corresponds to one or more work items with a particular cycle time. The lower the
cycle time, the faster work is progressing through your development pipeline.
Lead time (team-scoped)
NOTE
Displays the lead time of work items closed in a specified timeframe for a single team and backlog level. The
lead time of a work item is defined as the time taken to close a work item after it was created.
Each marker on the chart corresponds to one or more work items with a particular lead time. The lower the lead
time, the faster work is being delivered to the customer.
New Work item (team-scoped)
Enables you to add work items from the dashboard. You use work items to plan and track work.
Work items that you add using this widget are automatically scoped to the team's default area path and the
team's current sprint (TFS) or the default iteration (VSTS). To change team defaults, see Set team defaults.
Other links (team-scoped)
Provides links to the following features:

Opens a form to initiate a request to provide feedback.
Opens the team's quick dialog to add or modify the active sprints or iteration paths for your team. To learn
more see Define sprints.
Opens the team's quick dialog to modify your team's area path.
For on-premises TFS, additional links are displayed when the corresponding resource is configured for the team
project:
On-premises TFS with configured resources
View project portal (opens either a SharePoint site or URL that's been configured as the team project's
portal.
View process guidance (opens either a SharePoint site or URL that's been configured as the team project's
process guidance.
View reports (opens SQL Server Reporting Services). To add or update reports for a team project, see Add
reports to a team project.
Query results
Adds a configurable tile that lists the results of a shared query. From the configuration dialog, select either a
team favorite or shared query.
To create a shared query, see Use the query editor to list and manage queries.
Query tile
Adds a configurable tile to display the summary of a shared query results. From the configuration dialog, select
either a team favorite or shared query. You can optionally specify rules to change the query tile color based on
the number of work items returned by the query. To create a shared query, see Use the query editor to list and
manage queries.
Sprint burndown (team-scoped)
Adds the team's burndown chart for the current sprint to the dashboard. This chart always displays data for the
current sprint. Teams use the burndown chart to mitigate risk and check for scope creep throughout the sprint
cycle.
Sprint capacity (team-scoped)
Inserts the team's capacity bar chart for the current sprint. Teams specify their capacity to plan and monitor
their sprint resources.
Sprint overview (team-scoped)
For VSTS, inserts a configurable overview of sprint progress. You can choose between a count of story points or
number of work items.
For on-premises TFS, inserts a visual overview of sprint progress indicating the number of backlog items in
progress, completed, or not started.
Teams plan their sprints by defining sprints and assigning backlog items to an iteration.
Velocity (team-scoped)
NOTE
Marketplace extension. You can then add the widget to your dashboard. You must be an account owner or a member of
the Project Collection Administrator group to add extensions.
The velocity widget tracks a team's capacity to deliver work sprint after sprint. You configure the widget by
selecting a team, a work item type, an aggregation field, and the number of sprints. The widget takes advantage
of the Analytics service. You can track the velocity for a single team, not multiple teams.
For additional guidance, see Velocity.
Work links (team-scoped)
Provides quick access to open the following Agile tools

and team resources:
Backlog
Kanban Board
Task board
Queries
Build, test, release

Chart for build history
NOTE
Feature availability: You can access this widget from VSTS or TFS 2015.2 or later version. For TFS 2015.1 and earlier
versions, see Add charts to a dashboard to add a build summary chart to a dashboard.
Adds a tile to display a histogram of all builds run for the configured build definition. From the configuration
dialog, select the build you want to monitor. Hover over a bar to learn how long the build took to complete.
Click the bar to open the summary for that specific build. Bar color indicates: green-completed, red-failed, and
yellow-completed without tests.
Chart for test plans
NOTE
Feature availability: You can access this widget from VSTS and TFS 2017.2 and later versions. For TFS 2015.1 and
earlier versions, see Add charts to a dashboard to add other supported chart types to a dashboard.
Adds a configurable widget that lets you track the progress of test case authoring or status of test execution for
tests in a test plan. Get started by selecting a test plan and a test suite. Then select test case chart for test
authoring progress or test results for test execution progress. Finally, select the chart type and the pivots.
To learn more, see Track your test results.
Deployment status
NOTE
Feature availability: You can access this widget from VSTS or TFS 2017.1 or later versions.
Configurable widget that shows a consolidated view of the deployment status and test pass rate across multiple
environments for a recent set of builds. You configure the widget by specifying a build definition, branch, and
linked release definitions.
To learn more, see View and manage releases.
Release definition overview
NOTE
Feature availability: You can access this widget from VSTS.
Configurable widget that you can use to view and track the status of a release definition. The widget shows the
release as a series of environments, with the name of the release and the date or time it was started. The color
of the heading and the icon in each environment indicate the current status of the release, which are the same
as are used on the Releases page. Select a release definition in the left column to filter the list to just releases
for that definition. To learn more, see Add release information to the dashboard.
Requirements quality
NOTE
Feature availability: You can access this widget from VSTS or TFS 2017.
Configurable widget that you can use to track quality continuously from a build or release definition. To learn
more, see Associate automated test results with requirements.
Test results trend
NOTE
Feature availability: You can access this widget from VSTS or TFS 2017.
Adds a configurable tile that displays the trend of test results, such as passed or failed tests, for the selected
build definition.
From the configuration dialog, select the build whose test results you'd like to monitor. Then, choose the type of
chart you want displayed. You can track the trend of test duration by adding an optional line chart.
To learn more about creating charts for tracking test results, see Review continuous test results after a build.
Informational content and other links

Embedded web page
NOTE
Feature availability: You can access this widget from VSTS or TFS 2017 or later version.
Adds a configurable tile to display the contents of a web page. Only webpages that allow iframe embedding are
supported.
Markdown
NOTE
Feature availability: For VSTS and TFS 2015.2 or later versions, you can configure the widget to point to a file stored in
your repository.
Adds a configurable tile to display any type of information, guidance, or links that you want. From the
configuration dialog, add the information you want to share with your team.
To learn more, see Add Markdown to a dashboard.
Team members (team-scoped)
Sows team member profiles and, on-hover, their user account alias. For team admins, supports access to the
quick dialog to add or remove team members.
NOTE
This widget is a convenient way to add team members to specific teams within projects. If you remove it, you can still add
members to your team from the team administration page.
Team room (team-scoped)
Provides status and access to team rooms. Team rooms support increased team productivity by providing a
space to discuss work in progress, ask questions, share status, and clarify issues that arise. Team administrators
can create additional team rooms.
Visual Studio Shortcuts
Provides links to open or download Visual Studio. The Visual Studio IDE client comes with the Team Explorer
plug-in which provides quick access to several features (some of which aren't available through the web portal).
Welcome
Provides links to the Work, Code, and Build hubs and reference documentation on how to add charts.
Related notes
These represent the basic widgets. Look forward to more widgets becoming available in the coming months.
Marketplace widgets
You may find additional widgets of interest from the Marketplace.
If your account or project collection administrator disables a marketplace widget, you'll see the following image:
To regain access to it, request your admin to reinstate or reinstall the widget.
Extensibility
Using the REST API service, you can create a dashboard widget. To learn more about the REST APIs for
dashboards and widgets, see Dashboards.
Syntax guidance for Markdown files, widgets, wikis,
and pull request comments
VSTS | TFS 2018 | TFS 2017 | TFS 2015

Having the right guidance at the right time is critical to success. To support your team or contributors to your
project, use markdown to add rich formatting, tables, and images to your project pages, readme files, dashboards,
and pull request comments.
You can provide guidance to your team in these places using markdown:
Project vision page or Welcome pages
Team project wiki
Readme files
Pull request comments
In this topic you'll find some basic Markdown syntax guidance. You can use both common Markdown conventions
and Github-flavored extensions.
Headers
Structure your comments using headers. Headers segment longer comments, making them easier to read.
Start a line with a hash character # to set a heading. Organize your remarks with subheadings by starting a line
with additional hash characters, for example #### . Up to six levels of headings are supported.
Example:
# This is an H1 header
## This is an H2 header
### This is an H3 header
#### This is an H4 header
##### This is an H5 header
Result:
Paragraphs and line breaks

Make your text easier to read by breaking it up with paragraphs or line breaks.
In pull request comments, press Enter to insert a line break and begin text on a new line.
In a Markdown file or widget, enter two spaces prior to the line break to begin a new paragraph, or enter two line
breaks consecutively to begin a new paragraph.
Example - pull request comment:
Add lines between your text with the Enter key.

This spaces your text better and makes it easier to read.
Result:
Add lines between your text with the return key
This spaces your text better and makes it easier to read.
Example - markdown file or widget:
Add two spaces prior to the end of the line.(space, space)

This adds space in between paragraphs.
Result:
Add two spaces prior to the end of the line.
This adds space in between paragraphs.
Quotes
Quote previous comments or text to set context for your comment or text.
Quote single lines of text be putting a > before the text. Use multiple > characters to nest quoted text. Quote
blocks of lines of text by using the same level of > across multiple lines.
Example:
> Single line quote

>> Nested quote
> multiple line
> quote
Result:
Horizontal rules
Add a horizontal rule by adding a new line that's just a series of dashes --- . There must be a blank line above the
line containing the --- .
Example:
above
----
below
Result:
above
below
Lists
Organize related items with lists. You can add ordered lists with numbers, or unordered lists with just bullets.
Ordered lists start with a number followed by a period for each list item. Unordered lists start with a - . Begin each
list item on a new line.
Example:
1. First item.
2. Second item.
3. Third item.
Result:
1. First item.
2. Second item.
3. Third item.
Example:
- Item 1
- Item 2
- Item 3
Result:
Item 1
Item 2
Item 3
Links
In pull request comments and wiki, HTTP and HTTPS URLs are automatically formatted as links. Also, within pull
requests, you can link to work items by typing the # key and a work item ID, and then choosing the work item from
the list.
In markdown files and widgets, you can set text hyperlinks for your URL using the standard markdown link syntax:
[Link Text](Link URL)
When linking to another Markdown page in the same Git or TFVC repository, the link target can be a relative path
or an absolute path in the repository.
Supported links for Welcome pages:
Relative path: [text to display](./target.md)
Absolute path in Git: [text to display](/folder/target.md)
Absolute path in TFVC: [text to display]($/project/folder/target.md)
URL: [text to display](http://address.com)
Supported links for Markdown widget:

Supported links for Wiki:

Absolute path of Wiki pages: [text to display](/parent-page/child-page)
NOTE
For information on how to specify relative links from a Welcome page or Markdown widget, see Source control relative links.
Example:
[C# language reference](https://msdn.microsoft.com/en-us/library/618ayhy6.aspx)
Result:
C# language reference
Source control relative links
Links to source control files are interpreted differently depending on whether you specify them in a Welcome page
or a Markdown widget. The system interprets relative links as follows:
Welcome page: relative to the root of the source control repository in which the welcome page exists
Markdown widget: relative to the team project collection URL base.
For example:
WELCOME PAGE MARKDOWN WIDGET EQUIVALENT
/BuildTemplates/AzureContinuousDeploy.11.xaml /DefaultCollection/Fabrikam
Fiber/_versionControl#path=$/Tfvc
Welcome/BuildTemplates/AzureContinuousDeploy.11.xaml
./page-2.md /DefaultCollection/Fabrikam
Fiber/_versionControl#path=$/Tfvc Welcome/page-2.md
Anchor links
Within Markdown files, anchor IDs are assigned to all headings when rendered as HTML. The ID is the heading text,
with the spaces replaced by dashes (-) and all lower case.
Example:
###Link to a heading in the page
Result:
The syntax for an anchor link to a section...
[Link to a heading in the page](#link-to-a-heading-in-the-page)
The ID is all lower case, and the link is case sensitive, so be sure to use lower case, even though the heading itself
uses upper case.
You can also reference headings within another Markdown file:
[text to display](./target.md#heading id)
In wiki, you can also reference heading in another page:
[text to display](/page-name#section-name)
Images
Add images and animated GIFs to your pull request comments, markdown files, or wiki pages to highlight issues
or just to liven the discussion.
Use the following syntax to add an image:
![Text](URL)
The text in the brackets describes the image being linked and the URL points to the image location.
Example:
![Let's use this flow for the login experience](http://dev.fabrikam.net/images/uxflow.png)
Result:
The path to the image file can be a relative path or the absolute path in Git or TVFC, just like the path to another
Markdown file in a link.
Relative path:
![Image alt text](./image.png)
Absolute path in Git:
![Image alt text](/_img/markdown-guidance/image.png)
Absolute path in TFVC:
![Image alt text]($/project/folder/_img/markdown-guidance/image.png)
Resize image:
![Image alt text]($/project/folder/_img/markdown-guidance/image.png =WIDTHxHEIGHT)
NOTE
Feature availability: The syntax to support image resizing is only supported in pull requests and the Wiki.
Tables
Organize structured data with tables. Tables are especially useful for describing function parameters, object
methods, and other data that has a clear name to description mapping.
Place each table row on its own line
Separate table cells using the pipe character |
The first two lines of a table set the column headers and the alignment of elements in the table
Use colons ( : ) when dividing the header and body of tables to specify column alignment (left, center, right)
Make sure to end each row with a CR or LF.
Example:
| Heading 1 | Heading 2 | Heading 3 |

|-----------|:-----------:|-----------:|
| Cell A1 | Cell A2 | Cell A3 |
| Cell B1 | Cell B2 | Cell B3 |
Result:
HEADING 1 HEADING 2 HEADING 3
Cell A1 Cell A2 Cell A3
Cell B1 Cell B2 Cell B3
Checklist or task list

Use [ ] or [x] to support checklists. You need to precede the checklist with either -<space> or 1.<space> (any
numeral).
Example:
- [ ] A
- [ ] B
- [ ] C
- [x] A
- [x] B
- [x] C
Result:
Emphasis (bold, italics, underscore)
You can emphasize text by applying bold, italics, or strikethrough to characters:
To apply italics: surround the text with an asterisk * or underscore _
To apply bold: surround the text with double asterisks ** .
To apply strick-through: surround the text with double tilde characters ~~ .
Combine these elements to apply multiple emphasis to text.

Example:
Use _emphasis_ in comments to express **strong** opinions and point out ~~corrections~~
**_Bold, italizied text_**
**~~Bold, strike-through text~~**
Result:
Use emphasis in comments to express strong opinions and point out corrections
Bold, italizied text
Bold, strike-through text
Code highlighting
Highlight suggested code segments using code highlight blocks. To indicate a span of code, wrap it with three
backtick quotes ( ``` ) on a new line at both the start and end of the block.
Example:
```
$ sudo npm install vsoagent-installer -g
```
Result:
$ sudo npm install vsoagent-installer -g
Within a markdown file, text with four spaces at the beginning of the line automatically converts to a code block.
Set a language identifier for the code block to enable syntax highlighting for any of the supported languages.
```language
code
```
Additional examples:
```js
const count = records.length;
```
js
const count = records.length;
```csharp
Console.WriteLine("Hello, World!");
```
csharp
Console.WriteLine("Hello, World!");
Emoji
In pull request comments and wiki pages, you can use emojis to add character and react to comments in the
request. Type in what you're feeling surrounded by : characters to get a matching emoji in your text. The full set
of emojis are supported.
Example:
:smile:
:angry:
Result:
Special characters
SYNTAX EXAMPLE/NOTES
To insert one of the following characters, prefix with Some examples on inserting special characters
a backslash: Enter \\ to get \
\ backslash Enter \_ to get _
` backtick
Enter \# to get #
_ underscore
{} curly braces
Enter \( to get (
[] square brackets Enter \. to get .
() parentheses
Enter \! to get !
# hash mark
+ plus sign
- minus sign (hyphen)
. dot
! exclamation mark
Attachments
In pull request comments and wiki pages, you can attach files to illustrate your point or to give more detailed
reasoning behind your suggestions. To attach a file, drag and drop it into the comment field or wiki page edit
experience. You can also select the paper-clip icon in the upper-right of the comment box or the format pane in
wiki page.
If you have an image in your clipboard, you can paste it from the clipboard into the comment box or wiki page and
it will render directly into your comment or wiki page.
Attachments support the following file formats:
Images: PNG (.png), GIF (.gif), JPEG (both .jpeg and .jpg)
Documents: Word (.docx), Excel (.xlsx), and Powerpoint (.pptx), text files (.txt), and PDFs (.pdf)
Compressed files: ZIP (.zip) and GZIP (.gz)
Video files: MOV (.mov), MP4 (.mp4)
Attaching non-image files creates a link to the file in your comment. Update the description text between the
brackets to change the text displayed in the link. Attached image files render directly into your comment or wiki
pages.
Once you save or update a comment or wiki page with an attachment, you can see the attached image(s) and can
select links to download attached files.
HTML Tags
In wiki pages, you can also create rich content using HTML tags.
Example - Embedded video
<video src="<path of the video file>" width=400 controls>
</video>
Result:
Example - Rich text format
This text needs to <del>strikethrough</del> <ins>since it is redundant</ins>!

<tt>This text is teletype text.</tt>
Colored text
<center>This text will be center-aligned.</center>
This text contains superscript text.
This text contains subscript text.
The project status is GREEN even though the bug count /
developer may be in red. - Capability of span
Disclaimer: Wiki also supports showing small text
<big>Bigger text</big>
Result:
This text needs to strikethrough since it is redundant!
This text is teletype text.
Colored text
This text will be center-aligned.
This text contains superscript text.
This text contains subscript text.
The project status is GREEN even though the bug count / developer may be in red. - Capability of span
Disclaimer: Wiki also supports showing small text
Bigger text
Related notes
Project vision page or Welcome pages
Readme files
Pull requests
Markdown widget
Dashboards
Widget catalog
Wiki

Report

Uploaded by

Copyright:

Available Formats

Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Report

Uploaded by

Copyright:

Available Formats

Table of Contents

VSTS | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

VSTS | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

Add widgets to your dashboard

Sample chart widgets

Monitor code activity, build progress and deployment status

Generate status and trend charts from queries

Sequence for adding query-based charts to a dashboard

Test progress, results, and trends

System-generated work tracking charts

Sprint chart widgets

Try this next

VSTS | TFS 2018 | TFS 2017 | TFS 2015.1-2015.3

Connect to the web portal for your team project

Add and name your dashboard

Reorder and auto -refresh

2. Click to delete a dashboard and then click Save.

Move or delete a widget from a dashboard

To remove a widget, click the widget's or delete icons.

Try this next

VSTS | TFS 2018 | TFS 2017

Connect to the web portal for your team project

Add a widget to a dashboard

Click to modify a dashboard. Click to add a widget to the dashboard.

Move or delete a widget from a dashboard

To remove a widget, click the widget's or delete icons.

Try this next

VSTS | TFS 2018 | TFS 2017 | TFS 2015.1-2015.3

Connect to the web portal for your team project

Add the markdown widget to a dashboard

1. Click to modify a dashboard.

2. Click to open the widget catalog.

This renders the following widget:

7. Optionally, you can choose to point to a file in your repository.

Burndown and burnup metrics

Add the widget to your dashboard

Choose the teams and work items to chart

Choose how you want to calculate burndown or burnup

And, here we choose a sum based on Story Points.

Choose the time period and plotting interval

End Date Specifies the target date of completion. Your goal is to

Plot based on an iteration schedule

Add multiple iterations by selecting Add iterations.

Interpret a Burndown or Burnup widget chart

Main metric Current remaining work based on the selected burndown

% Completed The percentage of work completed based on original scope.

Average burndown Average work completed per interval or iteration.

Projected completion Calculates the projected completion date based on the

Configure the Burnup widget

VSTS | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

Configure the CFD widget

Try this next

Configure the Cycle Time and Lead Time widgets

Interpret the scatter-plot control charts

Moving average and standard deviation calculations

VSTS | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

Velocity chart Velocity widget

Configure the Velocity widget

Work with the built-in team velocity chart

1. From the backlog page, open the velocity chart.