Azure DevOps Services - Dashboards Index To Content

Contents
Dashboards
Overview
Dashboards & widgets
Quickstarts
Add, rename, & delete dashboards
Add widgets to a dashboard
Add an Analytics widget to a dashboard
Add markdown to a dashboard
Tutorials
Configure burndown/burnup
Configure cumulative flow
Configure lead/cycle time
Configure velocity widget
View the built-in velocity chart
Work with sprint burndown
Configure test trend results
Concepts
Burndown guidance
Cumulative flow & lead/cycle time guidance
Velocity guidance
Analytics widgets
How-to Guides
Add charts to a dashboard
Create work tracking charts
Create test progress & result charts
Set dashboard permissions (Security)
Samples (REST API)
Add a dashboard widget
Add a chart widget
Add an Analytics widget
Reference
Widget catalog
Markdown guidance
Default permissions & access (Security)
Reporting roadmap
REST API, Dashboards
Resources
Analytics
Azure Boards
Azure Test Plans
Marketplace widgets
Dashboards
1/31/2019 • 2 minutes to read • Edit Online
Azure DevOps Services | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
Gain visibility into your team's progress by adding one or more widgets to your dashboard. Each team can
customize and configure dashboards to share information and monitor their progress.
To learn about our reporting solutions, read Reporting Roadmap.
5-Minute Quickstarts
Add, rename, and delete dashboards
Add charts and widgets to a dashboard
Add Markdown to a dashboard
Add, rename, and delete dashboards
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 the Velocity widget
Concepts
Cumulative flow, lead time, and cycle time guidance
Velocity metrics and usage guidance
Burndown guidance
How-to Guides
Configure work item query-based charts
Configure test status, progress, and result charts
Set dashboard permissions
Samples
Add a chart widget
Add an Analytics widget
Add a chart widget
Reference
Widget catalog
Markdown guidance
Default permissions & access (Security)
REST API, Dashboards
Resources
Azure Boards
Azure Test Plans
Marketplace widgets
Agile
Testing
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
The Analytics Service and Analytics widgets

The Analytics Service is in preview and available to all Azure DevOps users. To learn more, see the following
articles:
Widgets based on the Analytics Service
What is the Analytics Service?
Monitor code activity, build progress and deployment status
With the code tile widgets, you can monitor the activity occurring within a repo or branch folder. Build history
displays a histogram of all builds run for a specific build pipeline. 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 status—pie, bar,
column, stacked bar, and pivot—and trend—stacked area, line, and area—charts.
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 activities—such as
Development, Test, Design—and 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 by adding a custom field.
You can add data to support reporting requirements by adding a custom field Inheritance process or On-premises
XML process.
You can add data to support reporting requirements by adding a custom field.
Extensibility
Using the REST API service, you can create a custom widget.
Add, rename, and delete team dashboards in Azure
DevOps
Azure DevOps Services | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015
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 project.
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.
NOTE
Multiple team dashboards and the widget catalog are available from TFS 2015.1 or later versions. For TFS 2015 and
earlier versions, 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.
NOTE
For information on SharePoint dashboards, see Project portal dashboards.
Prerequisites
You must be a member of a team project. If you don't have a team project yet, create one.
If you haven't been added as a team member,get added now.
Anyone with access to a project, including stakeholders, can view dashboards.
To add, edit, or manage a team dashboard, you must have Basic access or greater and be a team admin, a
project admin, or have dashboard permissions. In general, you need to be a team member for the currently
selected team to edit dashboards.
Prerequisites
project admin, or have dashboard permissions. 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.
Prerequisites
To add, edit, or manage a team dashboard, you must have Basic access or greater and be added to the team
administrator role for the team.
Connect to the web portal for your project

NOTE
Your web portal uses either the New navigation or Previous navigation user interface. Choose the New navigation
tab if the New Navigation feature is enabled. You'll see a vertical sidebar along with other navigational features when
New Navigation has been enabled for the signed-in user or the organization. Choose Previous navigation when you
see a top-level, blue-bar—indicating that New navigation isn't enabled. For more information, see Web portal
navigation.
NOTE
Choose the New navigation tab for guidance as Azure DevOps Server 2019 only supports the new navigation user
interface. For more information, see Web portal navigation.
NOTE
Choose the Previous navigation tab for guidance as TFS 2018 and earlier versions only support the previous navigation
user interface. For more information, see Web portal navigation.
All dashboards are associated with a team.

New navigation
Previous navigation
Open a web browser, connect to your project, and choose Overview>Dashboards. The dashboard directory
page opens.
It lists dashboards in the following order:
Your last visited dashboard
Your favorited dashboards
All dashboards of teams that you belong to
All dashboards defined for the project in alphabetical order.
Choose the filter icon to filter the list by keyword or team. Keywords apply to dashboard titles, descriptions,
and team names.
If you need to switch to a different project, choose the Azure DevOps logo to browse all projects.
Choose the Previous navigation tab for guidance. New navigation isn't supported for TFS 2018 and earlier
versions.
Select a dashboard to view, modify, or favorite

1. Choose a dashboard from the directory list, or from the selector. To return to the dashboard directory,
choose the Browse all dashboards option.
2. To favorite a dashboard, hover over the dashboard and choose the .

Favoriting a dashboard will cause it to appear under My Favorites dashboards list on the dashboards
directory. Also, it will appear towards the top in the Dashboards selector and in your personal Favorites
list. .
Select a dashboard to view or modify

1. Select the team whose dashboards you want to view. To switch your team focus, see Switch project, repo
or team.
2. From Dashboards, choose the name of the dashboard to view it.
For example, here we choose to view the Work in Progress dashboard.
Add and name your dashboard

Add a new dashboard as needed to support your team's needs. You can also edit and rename any existing
dashboards associated with your team.
1. From the Dashboards directory, choose New Dashboard. Or, when viewing a dashboard, open the
selector and choose the New Dashboard option.
If you don't see the New Dashboard option, then you're not a team admin for the currently selected
team, or you don't have permissions to add and edit dashboards. Either switch the context to your team,
or request you be added as a team admin.
2. Enter the name of the dashboard and other information you want to capture.
Choose Save.
3. The widget catalog opens. You can add one or more widgets to the dashboard. You can then configure
and resize each widget as needed.
4. You can move the widgets around the dashboard to place them where you want them.
5. When you're done making changes, choose Done Editing.
From Dashboards, choose the and enter a dashboard name.
If you don't see the , then you're not a team admin for the currently selected team, or you don't have
permissions to add and edit dashboards. 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 pages.
Rename, delete, and enable auto-refresh

You can rename or delete a dashboard. Also, you can enable auto-refresh, and the dashboard will automatically
update every 5 minutes.
NOTE
You can configure the auto-refresh setting for each dashboard for TFS 2015.2 and later versions. For TFS 2017.1 and later
versions, you can set dashboard permissions.
To rename a dashboard, modify it's description, or change it's automatic refresh setting, open the
dashboard, choose the gear icon, and change the field options shown. Save your changes.
To delete a dashboard, open the Dashboards directory, choose the actions icon for the dashboard,
and select the Delete menu option.
To set permissions for a dashboard, choose the Security option. For details, see Set dashboard
permissions.
1. To manage dashboards, choose the wrench icon.
2. Drag and drop the dashboards into the sequence you want them to appear.
3. (Optional) Select the Auto-refresh checkbox when you want the dashboard to refresh every five minutes.
4. To delete a dashboard, choose the delete icon.

5. Choose Save to save your changes.
You can also manage dashboard permissions.
1. To manage dashboards, choose the gear icon.
2. Drag and drop the dashboards into the sequence you want them to appear.
3. (Optional) Select the Auto-refresh checkbox when you want the dashboard to refresh every five minutes.
The Auto-refresh feature requires TFS 2015.2 or later version.
4. To delete a dashboard, choose the delete icon.

5. Choose Save to save your changes.
Move or delete a widget from a dashboard

NOTE
Just as you have to be a team admin, a project admin, or have the necessary permissions to add items to a dashboard,
you must have the necessary permissions to remove items.
Choose Edit to modify your dashboard.

You can then add widgets or drag tiles to reorder their sequence on the dashboard.
To remove a widget, choose the actions icon and select the Delete option from the menu.
When you're finished with your changes, choose Done Editing to exit dashboard edit mode.
TIP
When you're in dashboard edit mode, you can remove, rearrange, and configure widgets, as well as add new widgets.
Once you leave edit mode, the widget tiles remain locked, reducing the chances of accidentally moving a widget.
Choose to modify your dashboard. You can then drag tiles to reorder their sequence on the
dashboard.
To remove a widget, choose the widget's or delete icons.
When you're finished with your changes, choose to exit dashboard editing.
TIP
When you're in dashboard edit mode, you can remove, rearrange, and configure widgets, as well as add new widgets.
Once you leave edit mode, the widget tiles remain locked, reducing the chances of accidentally moving a widget.
Note that you can drag and drop a widget from the catalog onto the dashboard.
Try this next

As you can see, you can use team dashboards to provide guidance and keep your team in sync, providing
visibility across your org about status, trends, and progress.
Add a widget to a dashboard
Related articles
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).
Add widgets to a dashboard
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. Up to 200 widgets total. 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.
Prerequisites
Prerequisites
Prerequisites
NOTE
Widgets specific to a service are disabled if the service they depend on has been disabled. For example, if Boards is
disabled, New Work item and all Analytics widgets are disabled and won't appear in the widget catalog. To re-enable a
service, see Turn an Azure DevOps service on or off.
Select a dashboard to modify

All dashboards are associated with a team. You need to be a team administrator, project administrator, or a team
member with permissions to modify a dashboard.
NOTE
Your web portal uses either the New navigation or Previous navigation user interface. Choose the New navigation tab
if the New Navigation feature is enabled. You'll see a vertical sidebar along with other navigational features when New
Navigation has been enabled for the signed-in user or the organization. Choose Previous navigation when you see a
top-level, blue-bar—indicating that New navigation isn't enabled. For more information, see Web portal navigation.
NOTE
NOTE
New navigation
Previous navigation
1. Open a web browser, connect to your project, and choose Overview>Dashboards. The dashboard
directory page opens.
2. Choose the dashboard you want to modify.
versions.

To add widgets to the dashboard, choose Edit.
The widget catalog will automatically open. Add all the widgets that you want and drag their tiles into the
sequence you want.
When you're finished with your additions, choose Done Editing to exit dashboard editing. This will dismiss the
widget catalog. You can then configure the widgets as needed.
TIP
When you're in dashboard edit mode, you can remove, rearrange, and configure widgets, as well as add new widgets. Once
you leave edit mode, the widget tiles remain locked, reducing the chances of accidentally moving a widget.
Choose to modify a dashboard. Choose 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.
Or, you can drag and drop a widget from the catalog onto the dashboard.
Configure a widget
Most widgets support configuration, which may include specifying the title, setting the widget size, and other
widget-specific variables.
To configure a widget, add the widget to a dashboard, choose open the menu, and select Configure.
Additional information is provided to configure the following widgets:
Burndown/burnup
Cumulative flow
Lead time or cycle time
Velocity widget
Test trend results
Additional information is provided to configure the following widgets:
Burndown/burnup
Cumulative flow
Lead time or cycle time
Velocity widget
To configure a widget, add the widget to a dashboard and then choose the configure icon.
Once you've configured the widget, you can edit it by opening the actions menu.
Move or delete a widget from a dashboard
To move a widget, you need to enable the dashboard edit mode. To delete a widget, simply select the delete
option provided from the widget's options menu.
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.
Choose Edit to modify your dashboard. You can then add widgets or drag tiles to reorder their sequence on
the dashboard.
When you're finished with your changes, choose Done Editing to exit dashboard editing.
Choose to modify your dashboard. You can then drag tiles to reorder their sequence on the dashboard.
To remove a widget, choose the widget's or delete icons.

When you're finished with your changes, choose to exit dashboard editing.
Copy a widget to another dashboard

You can copy a widget to another dashboard defined for your team. If you want to move widgets you have
configured to another dashboard, this is how you do it. Before you begin, add the dashboard you want to copy or
move the widget to. Once you've copied the widget, you can delete it from the current dashboard.
To copy a configured widget to another team dashboard, choose the actions icon and select Copy to
dashboard and then the dashboard to copy it to.
To copy a configured widget to another team dashboard, choose the actions icon and select Add to
dashboard and then the dashboard to copy it to.
Analytics Service widgets

The Analytics Service is in preview and provides access to several widgets. To learn more, see these topics:
What is the Analytics Service?
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 organization owner 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.
Azure DevOps Services | Azure DevOps Server 2019

The Analytics Service is the reporting platform for Azure DevOps. Using Analytics, you and your team can gain
new insights into the health and status of your work. Follow this short guide to get started in a few simple steps.
In this topic we walk you through the steps for adding the Analytics-based Velocity widget to a dashboard. For a
review of all Analytics-based widgets, see Widgets based on the Analytics Service
Prerequisites
You must have a project defined for an organization in Azure DevOps. If you don't have one, see Sign up for
free.
You will have to have defined several work items. See Plan and track work.
Boards must be enabled. To re-enable it, see Turn an Azure DevOps service on or off.
Install the Analytics Marketplace extension.
You must have a project. If you don't have one, add one now.
You must be a member of the project. If you haven't been added yet, get added now.
You will have to have defined several work items. See Plan and track work. - To add a widget to a dashboard,
you must be a team admin, a project admin, or have dashboard permissions.
The Analytics Marketplace extension must be installed.
Add the Velocity widget to your dashboard

To add a widget to a dashboard, you connect to your project using a supported web browser. If you need to add a
project, see Create a project
New navigation
Previous navigation
1. Connect to the web portal for your project and choose Overview>Dashboards.
If you need to switch to a different project, choose the Azure DevOps logo to browse all projects and
teams.
2. Choose the dashboard that you want to modify.
3. Choose Edit to modify a dashboard. The widget catalog opens.
4. In the right pane search box, type Velocity to quickly locate the Velocity widget within the widget catalog.
5. Choose the widget, then Add to add it to the dashboard. Or, you can drag-and-drop it onto the dashboard.
Learn more on adding widgets to dashboard
Congratulations! A new Velocity widget has been added to your dashboard.
TIP
You'll gain the greatest utility from the Velocity widget by assigning work to sprints and completing work defined in those
sprints. To quickly define sprints, see Schedule sprints.
Learn about your team's velocity using the Velocity widget

The Velocity widget will help you learn how much work your team can complete during a sprint. The widget
shows the team's velocity by Story Points, work item count, or any custom field. You can also compare the work
delivered against your plan and track work completed late. Using the Velocity widget, you will be able to answer
questions like:
On average, what is the velocity of my team?
Is my team consistently delivering what we planned?
How much work can we commit to deliver in upcoming sprints?
Velocity widget showing 8 sprints of data based on Story Points.
Here, the Velocity widget shows this team has a history of closing stories late. It also shows a discrepancy between
planned and completed work in the past 4 sprints. The team can drill into the data to determine the root causes.
After implementing new practices, the team can use the Velocity widget to track their effectiveness.
Learn more about the Velocity widget in Configure and view Velocity charts.
Try this next

Configure and view Velocity charts
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:
Prerequisites
Prerequisites
Prerequisites
Connect to the web portal for your project

To add the markdown widget to a dashboard, you connect to your project using a supported web browser.
NOTE
NOTE
NOTE
New navigation
Previous navigation
Open a web browser, connect to your project, and choose Overview>Dashboards.
versions.
Add the markdown widget to a dashboard

If you need to add a dashboard, see Add, rename, and delete dashboards.
NOTE
Requires TFS 2015.1 or later version.
To add the markdown widget to the dashboard, choose Edit. The widget catalog will automatically open.
1. Add or drag the Markdown widget onto the dashboard where you want it located.
2. Choose Done Editing to exit dashboard editing. This will dismiss the widget catalog. You can then
configure the markdown widget as needed.
3. Choose 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 Set dashboard permissions.
4. 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.
5. 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
TIP
To link to a wiki page,use the following syntax:
/ProjectName/_wiki/wikis/WikiRepositoryName?pagePath=/FileName
To link to a repository file, page, or image within the project, rich-click the file and use the full URL.
This renders the following widget:
NOTE
Links to documents on file shares using file:// are not supported. This restriction has been implemented for
security purposes.
6. Optionally, you can choose to point to a file in your repository.
1. Choose to modify a dashboard.
2. Choose to open the widget catalog.

3. Drag the Markdown widget onto the dashboard where you want it located.
4. Choose 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 Set dashboard permissions.
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, or page within the 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 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, choose to exit dashboard editing.
Related articles
Add and manage dashboards
Syntax guidance for Markdown files, widgets, wikis, and pull request comments
Marketplace widgets
Configure a Burndown or Burnup widget

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.
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
How to configure a sprint burndown
NOTE
The Burnup and Burndown widgets are available by installing the Analytics extension
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.
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. Choose the actions icon and select the Configure option to open the configuration dialog.
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 projects.
The Burndown chart will display the burndown of remaining work for all selected teams.
NOTE
While you can select teams from other projects, all of the available configuration options—Work items, Field
criteria, and Burndown on will show selections from your current project.
The list of selectable backlogs, work item types, and fields are based on your current project.
For example, if you select a work item type that doesn't exist in another project, the burndown will not include work
items from that project. If you select a field that doesn't exist in another project, that field will be considered blank for
the burndown. Therefore, a burndown created across multiple 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.
NOTE
If your project has been customized using a Hosted XML process and has created a customized bug work item
category name, then the Burndown and Burnup widgets won't be able to query for work items within that category.
To query for bugs, the customized bug work item type must belong to the default Bug Category, reference name
Microsoft.BugCategory .
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.
NOTE
When setting filters in this step or the following step, it is important to understand how filters are applied to
historical data. Read Filters applied to historical data for more information.
4. (Optional) Select field criteria to limit the work items that appear in the chart.
You can filter by any field available in your 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 criteria, 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.
NOTE
Burndown works best when aggregating size fields like story points. If you choose to Burndown on fields that
change during the sprint, like Remaining Work for Tasks, the calculation of "Items not Estimated" will grow as items
are closed.
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 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 project, even if you selected teams from other projects.
Since the burndown chart plots remaining work based on the end date of the iteration, it calculates
remaining work across all teams/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/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 consider 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 results, 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 calculated based the last day of each month.
NOTE
The Average Burndown assumes that every interval is the same length. It does not consider 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 month'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 month's start date. This is also true when plotting by weekly intervals.
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 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.
% Completed The percentage of work completed based on original scope.

You may choose 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 choose 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/iteration
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.
ELEMENT DESCRIPTION
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.
Example: Configuring the Burndown widget to act as a Sprint

Burndown
One of the most common burndowns is the sprint burndown. A Sprint burndown is useful to determine if your
team is on track to complete their sprint plan. You can use the following example on how to configure your
Burndown widget to represent a sprint burndown. For this example we'll choose to show burndown for the
Fabrikam Fiber - Website team for Sprint 120. The sprint starts on 10/30/2017 and ends on 11/19/2017.
1. Select a single team that you want to burndown for.
2. Choose your work items. For this example choose the story backlog.
3. Select the iteration path you want to create the sprint burndown for. Add a field criteria on "Iteration Path"
to match your sprint. You can also choose to add other field criteria like Priority to filter your burndown.
4. Select how you want to calculate burndown. You can use Count of work items, or sum of any field.
5. Set the start date to be the first day of your sprint. For example, 10/22/2017.
6. Set Plot burndown by to Date.
7. Set the end date to be the last day of your sprint. For example 11/9/2017.
8. Save your configuration. This widget now shows a daily burndown of the Fabrikam Fiber - Website team
for Sprint 120. The burndown shows a count of work items completed per day. To change the sprint this
widget is monitoring, for example Sprint 121, you will need to manually change the dates in the widget
configuration.
Configure the Burnup widget

Configuring the Burnup widget is exactly like configuring the Burndown widget, except that it plots work
completed, rather than work remaining.
Burnup Widget displaying a Stories Burnup
Try this next
Burndown guidance
Related articles
Define iteration paths (aka sprints) and configure team iterations
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.
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.
You use cumulative flow diagrams (CFD ) to monitor the flow of work through a system. Use this topic to learn
how to:
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

You will need to be a team administrator or a member of the Project Administrators group to perform these
tasks. See Manage teams and configure team tools to get added as a team admin.
1. If you haven't yet, install the Analytics extension
2. If you haven't yet configured your Kanban board, do that now. Define the columns and swimlanes that
support your workflow processes.
3. If you want fixed scope CFD charts, make sure that you've defined the sprint iterations for those sprints of
interest.
4. To add a CFD chart to your team dashboard, see Add a widget to a dashboard. Add the Cumulative Flow
Diagram widget.
5. Choose the actions icon and select 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.
6. 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.
7. Choose the color. You can distinguish the CFD for different teams by choosing different colors.
8. Choose Save when done. The following image shows an example CFD chart showing 30 days of data.
View the built-in cumulative flow chart
NOTE
NOTE
Choose the New navigation tab for guidance. Azure DevOps Server 2019 supports the New Navigation user interface.
For more information, see Web portal navigation.
NOTE
Choose the Previous navigation tab for guidance. TFS 2018 and earlier versions only support the previous navigation
New navigation
You open the built-in (work tracking datastore) CFD for your product or portfolio backlog by choosing the image
in the upper-right corner of your Boards>Boards page.
::: moniker-end ��
::: moniker range=">= tfs-2013 <= tfs-2018"
versions.
::: moniker-end��
Previous navigation
::: moniker range=">= tfs-2013 <= tfs-2018 || azure-devops"
You open the built-in (work tracking datastore) CFD for your product or portfolio backlog by choosing the image
in the upper-right corner of your Work>Backlogs page.
Choose New navigation for guidance. Previous navigation isn't supported for Azure DevOps Server 2019.
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.
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.
New navigation
1. Open the backlog level for which you want to configure and then open the common configuration dialog.
Choose the gear icon.
If you're not a team admin, get added as one. Only team and project admins can customize the Kanban
boards and CFD charts.
2. Choose Cumulative flow and specify the team's preferences.
::: moniker-end ��
versions.
Previous navigation
1. Open the backlog level for which you want to configure and then open the common configuration dialog.
Choose 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. Choose Cumulative flow and specify the team's preferences.
Try this next

Cumulative flow, lead time, and cycle time guidance or Kanban basics
Lead time and cycle time control charts

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.
The following diagram 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.
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
To learn more, see Cumulative flow, lead time, and cycle time guidance.
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.
Pre -requisites
In order to configure the Cycle Time and Lead Time widgets, you must have the following in place:
Installed the Analytics Marketplace extension. You must be an organization 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.
Configuration dialog
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. Choose 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. Choose 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
Choose a dot to open the work item or query that lists the work items
To filter the chart, choose 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 the Velocity widget

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).
Example: Velocity widget showing six sprints of velocity
NOTE
The Velocity widget is available by installing the Analytics extension. For TFS 2018 and earlier, you have access to the
velocity chart provided by the work tracking datastore.
Use this topic to learn:

How to install and configure the Velocity widget
Required and recommended team activities to support velocity tracking
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. For usage guidance, see Velocity metrics and usage guidance.
There are two velocity charts, the one you access by adding the Velocity widget to a dashboard, and the one
viewed from the backlog of a team. The Velocity widget enables you to view more sprints and additional
information than that provided by the velocity chart.
Prerequisites
In order to add a Velocity widget to a dashboard, you must have the following in place:
Added the widget to a dashboard. You must be a team administratoror have permissions to add and edit
dashboards.
Configure the widget
You configure your velocity widget for a single team. If you want to view the velocity for several teams, then you
must configure a portfolio management team which rolls up from several teams. To learn more about teams, see
Add teams.
2. If you haven't yet added the Velocity widget to your dashboard, do that now.
3. Choose 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.
For example, if the Iteration starts on 01/01/2018, and 3 backlog items are assigned to the
iteration on 01/01/2018 end-of-day, then those 3 backlog item items will be considered as
Planned. If your team doesn't complete planning until a few days into the iteration, then you can
update the Days past start date of iteration when planned work is final.
NOTE
Work is considered Planned if it is assigned to the iteration as-of the Iteration Start Date.
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.
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.
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.
6. Choose Save when done. The following image shows Velocity based on Story Points and 8 sprints of
data.
Required and recommended activities

For your team to gain the greatest utility from the velocity chart, follow these required and recommended tasks.
Required:
Define iteration paths (aka sprints) and configure team iterations Sprints should be of the same duration.
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 list-only 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.
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.
Try this next

Velocity guidance
View and work with the built-in team velocity chart
Azure Boards | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
Teams track their velocity to help them determine how much work they can perform sprint-over-sprint. The built-
in team velocity chart provides an indication of how much work a team can complete during a sprint. The chart is
only available for the product backlog and is based on 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.
Example Velocity chart from the work tracking data store
Use this topic to learn:

How to view and work with the Velocity chart (work tracking datastore)
Required and recommended team activities to support velocity tracking
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. For usage guidance, see Velocity metrics and usage guidance.
NOTE
In addition to the built-in velocity chart, Azure DevOps users have access to the Velocity widget. The Velocity widget
enables you to view more sprints and additional information than that provided by the velocity chart.
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 article. These differences result from
updates made to your web app, options that you or your admin have enabled, and which process was chosen when
creating your project—Agile, Basic, Scrum, or CMMI.
From your web browser, open your product backlog.
NOTE
NOTE
NOTE
Choose the Previous navigation tab for guidance. TFS 2018 and earlier versions only support the previous navigation user
New navigation
1. (1) Check that you have selected the right project, (2) choose Boards>Backlogs, and then (3) select the
correct team from the team selector menu.
To choose another team, open the selector and select a different team or choose the Browse all
backlogs option. Or, you can enter a keyword in the search box to filter the list of team backlogs for the
project.
TIP
Choose the star icon to favorite a team backlog. Favorited artifacts ( favorited icon) appear at the top of the
team selector list.
2. Check that you have selected Backlog items (for Scrum), Stories (for Agile), or Requirements (for
CMMI) as the backlog level.
3. 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.
4. 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. ::: moniker-end��
::: moniker range=">= tfs-2013 <= tfs-2018"��

versions.
Previous navigation
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.

For your team to gain the greatest utility from the velocity chart, follow these required and recommended tasks.
Required:
Define iteration paths (aka sprints) and configure team iterations Sprints should be of the same duration.
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 list-only 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.
Add other teams

Try this next

Velocity guidance
Monitor sprint burndown
Azure Boards | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
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 article 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 taskboard. 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 the Sprint backlog for your team

NOTE
NOTE
NOTE
New navigation
Previous navigation
1. From your web browser, open your team's sprint backlog. (1) Check that you have selected the right project,
(2) choose Boards>Sprints, (3) select the correct team from the team selector menu, and lastly (4), choose
Backlog.
2.
To choose another team, open the selector and select a different team or choose the Browse all
sprints option. Or, you can enter a keyword in the search box to filter the list of team backlogs for the
project.
3. To choose a different sprint than the one shown, open the sprint selector and choose the sprint you want.
The system lists only those sprints that have been selected for the current team focus. If you don't see the
sprints you want listed, then choose New Sprint from the menu, and then choose Select existing
iteration. For details, see Define iteration paths (aka sprints).
versions.
Open the sprint burndown chart

Choose the chart to display it in a larger view.
New navigation
Previous navigation
versions.
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?

In order to access the sprint burndown chart and use it to monitor your sprint progress, your team must perform
the following actions.
Required activities:
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 taskboard, 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 activities:
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.
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.
Current and past sprint burndown charts

As you complete each sprint, the system maintains a history of your activity.
New navigation
Previous navigation
To view a past sprint and its burndown chart, select the sprint from the Sprint selector.
versions.
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 articles
You can learn more about defining, planning, and executing your sprints from these topics:
Schedule sprints
Sprint planning
taskboard
And, from these industry resources:
Understanding the Scrum Burndown Chart
Task sizing in Agile software development
For on-premises deployments, you can specify the format that appears—h for hours or d for days—for the
remaining work field.
Configure the Test Results Trend (Advanced) widget
Azure DevOps Services

Teams track their test collateral health—for example, test pass percentage, test failures, and test duration—to
ensure effective continuous testing in a pipeline. With the test results trend widget, you can monitor test trends
over a period of time, detect patterns around test failures, test duration, and more, and generate actionable
insights.
Example Test Results Trend widget showing pass percentage and test failure for last 7 days
In this article you'll learn:

The type of insights you can get by monitoring Test Results Trend charts
Prerequisites for gaining actionable insights from the Test Results Trend charts
How to install and configure the Test Results Trend widget
NOTE
The Test Results Trend (Advanced) widget is based on the Analytics Service and is available only for Azure DevOps at this
time. For on-premises TFS, you can use the Test Results Trend widget.
Insights supported with Test Results Trend charts

With the Test Results Trend charts, you can gain the following insights:
Identify if test health is improving over time by monitoring trends of failures and average pass rate on each day
Identify long running tests which are impacting a pipeline's efficiency by monitoring the average test duration
on each day
Identify patterns in test outcomes. Has the test recently started to fail? Or, has the test always failed for the
selected period? Or, is the test showing non-deterministic behavior?
Obtain insights into specific areas of interest to you based on test file, branch, or stage you own by configuring
specific filters.
Obtain insights into a specific area you test by configuring the widget to focus on a test file, branch or stage.
Test Results Trend charts require that you set up continuous testing in your build pipeline. To get deeper insights
and data you can view the Test Failure report in the pipeline. To learn more, see details Analyze test results.
Prerequisites
In order to configure the Test Results Trend widget, you must have the following in place:
Set up continuous testing for your build pipeline. For details, see Run unit tests with your builds
Added the widget to a dashboard. You must be a team administrator or have permissions to add and edit
dashboards. Default settings provide all team members wit permissions.
Configure the Test Results Trend widget

You can configure your Test Results Trend widget to show results for either build or release pipelines.
1. From your team's dashboard, choose the actions icon for the Test Results Trend (Advanced) widget you
want to configure and select Configure.
Modify the Title and choose either Build or Release for the type of Pipelines that you'll select.
Choose the plus icon to add one or more pipelines.
2. Next, choose the Period, and then choose the metrics that you want to track. Optionally, apply filters for
Branch, Test file, Owner, and Test run.
3. Choose Save when done.
The following image shows a chart with pass rate and test results for last 7 days.
Try this next
Test Analytics report.
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 work that wasn't estimated or
planned. 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
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.
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.
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 true—the
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, you'll 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 categories—Proposed, In Progress, and Completed—see
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 team's average lead time to estimate when your team will
complete that work item. Your team's 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 team's 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 or Configure a lead time or cycle time chart
Try this next

Configure your cumulative flow 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
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
Related articles
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

The Analytics extension includes several dashboard widgets that take advantage of the power of the Analytics
Service. Once you install the Analytics extension you can add Widgets to your dashboard. Using widgets, you and
your team can gain valuable insights into the health and status of your work.
NOTE
You need to first install the Analytics Marketplace extension.
You can then add the widget(s) to your dashboard. You must be an organization owner or a member of the
Project Collection Administrator group to add extensions.
You can then add the widget(s) to your dashboard. You must be an organization owner or a member of the
Project Collection Administrator group to add extensions.
If Boards is disabled, then all widgets associated with work item tracking, including those based on the Analytics
Service, will also be disabled. To re-enable a service, see Turn an Azure DevOps service on or off.
Burndown
The Burndown widget lets you display a trend of remaining work across multiple teams and multiple sprints. You
can use it to create a release burndown, a bug burndown, or a burndown on any scope of work over time. It will
help you answer questions like:
Will we complete the scope of work by the targeted completion date? If not, what is the projected completion
date?
What kind of scope creep does my project have?
What is the projected completion date for my project?
Burndown widget showing a release Burndown
To learn more, see Configure a Burndown or Burnup widget.
Burnup
The Burnup widget lets you display a trend of completed work across multiple teams and multiple sprints. You
can use it to create a release burnup, a bug burnup, or a burnup on any scope of work over time. When completed
work meets total scope, your project is done!
Burnup widget showing a release Burnup
To learn more, see Configure a Burndown or Burnup widget.

Cumulative Flow Diagram (CFD)
The CFD widget shows the count of work items (over time) for each column of a Kanban board. This allows you
to see patterns in your team's development cycle over time. It will help you answer questions like:
Is there a bottleneck in my process?
Am I consistently delivering value to my users?
Cumulative flow diagram widget showing 30 days of data
To learn more, see Cumulative flow diagram widget.
Cycle Time
The Cycle time widget will help you analyze the time it takes for your team to complete work items once they
begin actively working on them. A lower cycle time is typically indicative of a healthier team process. Using the
Cycle time widget you will be able to answer questions like:
On average, how long does it take my team to build a feature or fix a bug?
Are bugs costing my team a lot of development time?
Cycle time widget showing 30 days of data
To learn more, see Cycle time and lead time control charts.
Lead Time
The Lead time widget will help you analyze the time it takes to deliver work from your backlog. Lead time
measures the total time elapsed from the creation of work items to their completion. Using the Lead time widget
you will be able to answer questions like:
How long does it take for work requested by a customer to be delivered?
Did work items take longer than usual to complete?
Lead time widget showing 60 days of data
To learn more, see Cycle time and lead time control charts.
Velocity
The Velocity widget will help you learn how much work your team can complete during a sprint. The widget
shows the team's velocity by Story Points, work item count, or any custom field. You can also compare the work
delivered against your plan and track work completed late. Using the Velocity widget, you will be able to answer
questions like:
On average, what is the velocity of my team?
Is my team consistently delivering what we planned?
How much work can we commit to deliver in upcoming sprints?
Velocity widget showing 8 sprints of data based on Story Points
To learn more, see Configure and view Velocity widgets.
Test Results Trend (Advanced)

With the Test Results Trend (Advanced) widget, you can track the test quality of your pipelines over time. Tracking
test quality and improving test collateral are essential tasks to maintaining a healthy DevOps pipeline.
The widget shows a trend of your test results for either build or release pipelines. You can track the daily count of
tests, pass rates, and test duration. The highly configurable widget allows you to use it for a wide variety of
scenarios.
You can find outliers in your test results and answer questions like:
What tests taking longer to run than usual?
What micro services are affecting my pass rate?
Test trend widget showing passed test results and pass rate for the last 7 days grouped by Priority
To learn more, see Configure a test results widget.
NOTE
Adding charts to a dashboard is not a supported feature in TFS 2013, instead, you can pin items to a team homepage.
Consider upgrading to the latest TFS version to get access to the widget catalog and multiple team dashboards.
You can add the charts described in this topic to a dashboard from their corresponding functional page, such as
Builds, Releases, or Queries.
NOTE
Adding charts to a dashboard is requires TFS 2015.1 or later version. For TFS 2015, you can pin items to a team homepage.
Consider upgrading to the latest TFS version to get access to the widget catalog and multiple team dashboards.
Prerequisites
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 release summary chart

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. (Requires
TFS 2017.1 or later versions).
NOTE
You can also add this chart to a team dashboard from the widget catalog.
NOTE
Your web portal uses either the New navigation or Previous navigation user interface. Choose the New navigation tab if
the New Navigation feature is enabled. You'll see a vertical sidebar along with other navigational features when New
Navigation has been enabled for the signed-in user or the organization. Choose Previous navigation when you see a top-
level, blue-bar—indicating that New navigation isn't enabled. For more information, see Web portal navigation.
NOTE
Choose the New navigation tab for guidance. Azure DevOps Server 2019 supports the New Navigation user interface. For
more information, see Web portal navigation.
NOTE
Choose the Previous navigation tab for guidance. TFS 2018 and earlier versions only support the previous navigation user
1. Select your team context and then open Pipelines>Releases to add a release definition chart to a team
dashboard.
New navigation
Previous navigation
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 pipeline 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
As you create and run tests, you can track your status by defining lightweight charts of test plans and test results.
NOTE
You can also add a Chart for test plans widget to a dashboard.
Select your team context, make sure you're a team admin, and if you haven't yet created the dashboard, do that
now.
Open Test>Test Plans and then Charts and select the dashboard to add the test chart to.
Add a test quality trend chart

You can add trends to the dashboard of the failures and duration of those tests that were run as part of a build.
NOTE
You can also add a test result trend chart widget to a dashboard.
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 pipeline to which you've added tests, open the Tests page, and choose the
bar chart for either Test failures or Test duration.
3. Open 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

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.
NOTE
You can also add a work item query chart widget to a team dashboard.
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

Open the Markdown file defined in your repository and make sure you are in your team context.
Choose 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.
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 charts—such as pie, column, or trend—for 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 trend views of the active bugs over the last two weeks.
Prerequisites
By default, users with Basic access or higher can create charts from a flat list query. Users with Stakeholder
access can't view or create charts from the Queries page, however, they can view charts added to a team
dashboard. For details, see About access levels.
You must connect to a project. If you don't have a project yet, create one.
To create a chart, you must be added to a project as a member of the Contributors or Project
Administrators security group. To get added, Add users to a project or team.
To add a chart to a team dashboard, you must be a member of the team, be a team administrator, or be a
member of the Project Administrators security group.
You can add charts to multiple team dashboards and get access to the widget catalog, which is another way to
add charts to a dashboard.
NOTE
Users with Stakeholder access for a public project have full access to query chart features just like users with Basic access.
For details, see About access levels.
You can add charts to multiple team dashboards and get access to the widget catalog, which is another way to
add charts to a dashboard.
You can pin charts to a team homepage, and with TFS 2015.1 and later versions, you can add charts to
multiple team dashboards and get access to the widget catalog
To learn more about default groups, see About permissions and groups.
Create a query-based chart

1. From Queries, 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 work assignments, include the Assigned To in the query or column options
To group by sprints or 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.
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.
To change a color, simply choose a color from the Series set of color pickers.
To change a color, simply choose 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 over time. You can select a rolling period ranging from the last week to the last
year (earlier versions of TFS may have limited selections).
Trend data is extracted from the work tracking data store. Like most data stores, the schema of the relational
database is designed and optimized for the online transactional processing of data. As the tool or plug-in
performs an activity, it writes the latest information to the operational store. Therefore, data in the operational
store is constantly changing and being updated, and all data is current.
Burndown chart
Choose the Sum operator for Remaining Work to view a burndown chart of tasks.
Add a chart to a team dashboard
To add a chart to your team's home page, you must be a team administrator or have permissions to edit a
dashboard (default settings). You can only add charts defined for shared queries.
Choose the actions icon for the chart you want to add, and select Add to dashboard.
In the dialog that opens, select the team dashboard to add the chart to.
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 TFS 2013 and TFS 2015, you can pin charts to the team homepage. For TFS 2015.1 and later
versions, you can add charts to multiple team dashboards and get access to the widget catalog.
Add chart widget to a dashboard

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, open the team dashboard you want to add the chart to.
2. To add widgets to the dashboard, choose Edit. The widget catalog will automatically open. Add all the
widgets that you want and drag their tiles into the sequence you want.
If you don't see these icons, then you need to be added as a team administrator or get permissions to edit
dashboards.
3. Choose the Chart for work items widget and then choose Add.
4. Choose the widget's gear 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 article 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, choose Done Editing to exit dashboard edit mode.
The widget requires TFS 2015.2 or a later version. You add it to a team dashboard from the widget catalog.
1. From the web portal, open the team dashboard you want to add the chart to.
2. To add widgets to the dashboard, choose Edit. The widget catalog will automatically open. Add all the
widgets that you want and drag their tiles into the sequence you want.
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 choose Add.
4. Choose the widget's gear 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 article 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, choose to exit dashboard editing.
Related articles
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:
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 article. These differences result from
updates made to your web app, options that you or your admin have enabled, and which process was chosen when creating
your project—Agile, Basic, Scrum, or CMMI.
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"?
Widgets and the Analytics Service

The Analytics service, which is in preview, provides a number of additional widgets based on the Analytics Service.
Query-based charts versus Excel-generated PivotCharts
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.
Track test status
Azure Test Plans | Azure DevOps Server 2019 | 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.
To use all the features described in this topic you must have either an Enterprise, Test Professional, or MSDN
Platforms subscription; or have installed the Test Manager extension for Azure Test Plans available from Visual
Studio Marketplace. See Manual testing permissions and access.
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 page.
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 Plans page. 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 the
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 page 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 Plans page 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 Plans page.
3. Add a test results stacked bar chart. Choose Suite as the Y -axis (rows) pivot and Outcome as the Group
by (columns) pivot.
How many tests has each tester left to run?

Select your test plan from the Test Plans page 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 page. By default, test case fields are not added to the
view in the tests page.
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 page 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 Plans page. 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 page 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
Set dashboard permissions

Azure DevOps Services | Azure DevOps Server 2019 | TFS 2018 | TFS 2017
As a member of the Project Administrators group, you can set the default dashboard permissions for all teams.
As a team or project administrator, you can set individual dashboard permissions for team members. The
permissions only affect the team members to which the dashboards belongs.
As a team or project administrator, you can set individual dashboard permissions for team members. The
permissions only affect the team members to which the dashboards belongs.
NOTE
The set dashboard permissions feature is available for TFS 2017.1 and later versions. For TFS 2017 and earlier versions, only
team and project administrators can add and edit dashboards.
To learn more about adding and viewing dashboards, see Add, rename, and delete dashboards.
TIP
If a user reports that they can't create or edit a team dashboard, and you've set the permissions to allow them to do so,
check that they have been added as a member of the team. This includes adding them as a team member to the default
project team. For details, see Add users to a project or specific team.
Prerequisites
Set default dashboard permissions for a project

By default, all team members have permissions to edit dashboards defined for the team. All other valid users of
the project have view only permissions, except for members of the Project Administrators group. You can change
the default permissions a project from the Project settings.
NOTE
NOTE
NOTE
New navigation
Previous navigation
1. Choose Project Settings and then Dashboards.
2. Check or uncheck those permissions you want to grant or restrict. Your changes are automatically saved
by the system.
1. Choose Project Settings and then Dashboards.
2. Check or uncheck those permissions you want to grant or restrict. Your changes are automatically saved
by the system.
Set individual dashboard permissions for team members

1. Open the Dashboards directory, choose the actions icon for the dashboard, and then select the
Security menu option.
2. Change Allow or Deny to grant or restrict a permission.

Here we lock down the permissions for members of the Fabrikam team to edit the Analytics dashboard.
NOTE
The dashboard permissions dialog doesn't support granting permissions to other users or groups at this time.
3. Choose Save changes and then Close.

::: moniker-end�
Set individual dashboard permissions for team members

By default, all team members have permissions to edit dashboards defined for the team. All other valid users of
the project have view only permissions, except for administrators. You can change the view, edit, and manage
permissions for all team dashboards for members of your team.
1. To change the permissions for a specific dashboard, open the dashboard and then choose the wrench
icon for the dashboard.
For example, here we open the Manage Dashboards dialog for the Fabrikam Fiber Web team's Test
dashboard.
2. Choose the Permissions tab and check those checkboxes to grant or restrict permissions to your team
members to edit and manage team dashboards. The default settings, as shown in the illustration, provide
all team members permissions to edit and manage dashboards.
NOTE
The dashboard security dialog doesn't support granting permissions to other users or groups.
3. Choose Save to save your changes and dismiss the Settings dialog.
Related articles
Add users to a project or specific team
Add a team administrator
Widgets on a dashboard are implemented as contributions in the extension framework. A single extension can
have multiple contributions. In this guide we will show you how to create an extension with multiple widgets as
contributions.
This guide is divided into three parts, each building on the previous ones. The goal is to start with a simple widget
and end with a comprehensive one.
Preparation and required setup for this tutorial

In order to create extensions for Azure DevOps Services, there are some prerequisite software and tools you'll
need:
Knowledge: Some knowledge of JavaScript, HTML, CSS is required for widget development.
An organization in Azure DevOps Services for installing and testing your widget, more information can be
found here
A text editor. For many of the tutorials we used Visual Studio Code , which can be downloaded here
The latest version of node, which can be downloaded here
TFS Cross Platform Command Line Interface (tfx-cli) to package your extensions.
tfx-cli can be installed using npm , a component of Node.js by running npm i -g tfx-cli
A home directory for your project. This directory will be referred to as home throughout the tutorial.
Extension File Structure:
|--- README.md
|--- sdk
|--- node_modules
|--- scripts
|--- VSS.SDK.min.js
|--- img
|--- logo.png
|--- scripts
|--- hello-world.html // html page to be used for your widget
|--- vss-extension.json // extension's manifest
What you'll find in the tutorial

1. The first part of this guide shows you how to create a new widget which prints a simple "Hello World"
message.
2. The second part builds on the first one by adding a call to an Azure DevOps Services REST API.
3. The third part explains how to add configuration to your widget.
If you're in a hurry and want to get your hands on the code right away, you can download the complete
samples here. Once downloaded, go to the widgets folder, then follow Step 6 and Step 7 directly to publish
the sample extension which has the three sample widgets of varying complexities.
Get started with some basic styles for widgets that we provide out of the box for you and some guidance on
widget structure.
Part 1: Hello World
This part presents a widget that prints "Hello World" using JavaScript.
Step 1: Get the client SDK - VSS.SDK.min.js
The core SDK script, VSS.SDK.min.js , enables web extensions to communicate to the host Azure DevOps
Services frame and to perform operations like initializing, notifying extension is loaded or getting context about
the current page. Get the Client SDK VSS.SDK.min.js file and add it to your web app. Place it in the
home/sdk/scripts folder.
Use the 'npm install' command to retrieve the SDK:
npm install vss-web-extension-sdk
To learn more about the SDK, visit the Client SDK GitHub Page.
Step 2: Your HTML page - hello-world.html
This is the glue that holds your layout together and includes references to CSS and JavaScript. You can name this
file anything, just be sure to update all references to hello-world with the name you use.
Your widget is HTML based and will be hosted in an iframe. Add the below HTML in hello-world.html . We add
the mandatory reference to VSS.SDK.min.js file and include an h2 element in the body which will be updated
with the string Hello World in the upcoming step.
<!DOCTYPE html>
<html>
<head>
<script src="sdk/scripts/VSS.SDK.min.js"></script>
</head>
<body>
<div class="widget">
<h2 class="title"></h2>
</div>
</body>
</html>
Even though we are using an HTML file, most of the HTML head elements other than script and link will be
ignored by the framework.
Step 3: Your JavaScript

We use JavaScript to render content in the widget. In this guide we wrap all of our JavaScript code inside a
<script> element in the HTML file. You can choose to have this in a separate JavaScript file and refer it in the
HTML file. Apart from the logic to render the content, this JavaScript code will initialize the VSS SDK, map the
code for your widget to your widget name, and notify the extension framework of widget success or failure. In our
case, below is the code that would print "Hello World" in the widget. Add this script element in the head of the
HTML.
<script type="text/javascript">
VSS.init({
explicitNotifyLoaded: true,
usePlatformStyles: true
});
VSS.require("TFS/Dashboards/WidgetHelpers", function (WidgetHelpers) {

WidgetHelpers.IncludeWidgetStyles();
VSS.register("HelloWorldWidget", function () {
return {
load: function (widgetSettings) {
var $title = $('h2.title');
$title.text('Hello World');
return WidgetHelpers.WidgetStatusHelper.Success();
}
}
});
VSS.notifyLoadSucceeded();
});
</script>
VSS.init initializes the handshake between the iframe hosting the widget and the host frame.. We pass
explicitNotifyLoaded: true so that the widget can explicitly notify the host when we are done loading. This
control allows us to notify load completion after ensuring that the dependent modules are loaded. We pass
usePlatformStyles: true so that the Azure DevOps Services core styles for html elements (such as body, div etc)
can be used by the Widget. If the widget prefers to not use these styles, they can pass in
usePlatformStyles: false .
VSS.require is used to load the required VSS script libraries. A call to this method automatically loads general
libraries like JQuery and JQueryUI. In our case we depend on the WidgetHelpers library which is used to
communicate widget status to the widget framework. Therefore, we pass the corresponding module name
TFS/Dashboards/WidgetHelpers and a callback to VSS.require . The callback is called once the module is loaded.
This callback will have the rest of the JavaScript code needed for the widget. At the end of the callback we call
VSS.notifyLoadSucceeded to notify load completion.
WidgetHelpers.IncludeWidgetStyles will include a stylesheet with some basic css to get you started. Make sure to
wrap your content inside a HTML element with class widget to make use of these styles.
VSS.register is used to map a function in javascript which uniquely identifies the widget among the different
contributions in your extension. The name should match the id that identifies your contribution as described in
Step 5. For widgets, the function that is passed to VSS.register should return an object that satisfies the IWidget
contract, i.e. the returned object should have a load property whose value is another function that will have the
core logic to render the widget. In our case, it is simply to update the text of the h2 element to "Hello World". It is
this function that is called when the widget framework instantiates your widget. We use the WidgetStatusHelper
from WidgetHelpers to return the WidgetStatus as success.
Warning: If this name used to register the widget doesn't match the ID for the contribution in the manifest, then the widget
will behave unexpectedly.
The vss-extension.json should always be at the root of the folder (in this guide, HelloWorld ). For all the
other files, you can place them in whatever structure you want inside the folder, just make sure to update the
references appropriately in the HTML files and in the vss-extension.json manifest.
Step 4: Your extension's logo: logo.png
Your logo is displayed in the Marketplace, and in the widget catalog once a user installs your extension.
You will need a 98px x 98px catalog icon. Choose an image, name it logo.png , and place it in the img folder.
To support TFS 2015 Update 3, you will need an additional image that is 330px x 160px. This is a preview image
shown in this catalog. Choose an image, name it preview.png , and place it in the img folder as before.
You can name these images however you want as long as the extension manifest in the next step is updated with
the names you use.
Step 5: Your extension's manifest: vss-extension.json
Every extension must have an extension manifest file

Please read the extension manifest reference
Find out more about the contribution points in the extension points reference
Create a json file ( vss-extension.json , for example) in the home directory with the following contents:
{
"manifestVersion": 1,
"id": "vsts-extensions-myExtensions",
"version": "1.0.0",
"name": "My First Set of Widgets",
"description": "Samples containing different widgets extending dashboards",
"publisher": "fabrikam",
"targets": [
{
"id": "Microsoft.VisualStudio.Services"
}
],
"icons": {
"default": "img/logo.png"
},
"contributions": [
{
"id": "HelloWorldWidget",
"type": "ms.vss-dashboards-web.widget",
"targets": [
"ms.vss-dashboards-web.widget-catalog"
],
"properties": {
"name": "Hello World Widget",
"description": "My first widget",
"catalogIconUrl": "img/CatalogIcon.png",
"previewImageUrl": "img/preview.png",
"uri": "hello-world.html",
"supportedSizes": [
{
"rowSpan": 1,
"columnSpan": 2
}
],
"supportedScopes": ["project_team"]
}
}
],
"files": [
{
"path": "hello-world.html", "addressable": true
},
{
"path": "sdk/scripts", "addressable": true
},
{
"path": "img", "addressable": true
}
]
}
NOTE
The publisher here will need to be changed to your publisher name. To create a publisher now, visit Package/Publish/Install.
Icons
The icons stanza specifies the path to your extension's icon in your manifest.
Contributions
Each contribution entry defines certain properties.
The id to identify your contribution. This should be unique within an extension. This ID should match with the
name you used in Step 3 to register your widget.
The type of contribution. For all widgets, this should be ms.vss-dashboards-web.widget .
The array of targets to which the contribution is contributing. For all widgets, this should be
[ms.vss-dashboards-web.widget-catalog] .
The properties is an object that includes properties for the contribution type. For widgets, the below
properties are mandatory.
PROPERTY DESCRIPTION
name Name of the widget to display in the widget catalog.
description Description of the widget to display in the widget catalog.
catalogIconUrl Relative path of the catalog icon that you added in Step 4 to
display in the widget catalog. The image should be 98px x
98px. If you have used a different folder structure or a
different file name, then this is the place to specify the
appropriate relative path.
previewImageUrl Relative path of the preview image that you added in Step 4
to display in the widget catalog for TFS 2015 Update 3 only.
The image should be 330px x 160px. If you have used a
different folder structure or a different file name, then this is
the place to specify the appropriate relative path.
uri Relative path of the HTML file that you added in Step 1. If
you have used a different folder structure or a different file
name, then this is the place to specify the appropriate relative
path.
supportedSizes Array of sizes supported by your widget. When a widget

supports multiple sizes, the first size in the array is the default
size of the widget. The widget size is specified in terms of
the rows and columns occupied by the widget in the
dashboard grid. One row/column corresponds to 160px. Any
dimension above 1x1 will get an additional 10px that
represent the gutter between widgets. For example, a 3x2
widget will be 160*3+10*2 wide and 160*2+10*1 tall. The
maximum supported size is 4x4 .
supportedScopes At the moment we support only team dashboards. Therefore,

the value here has to be project_team . In the future when
we support other dashboard scopes, there will be more
options to choose from here.
Files
The files stanza states the files that you want to include in your package - your HTML page, your scripts, the SDK
script and your logo. Set addressable to true unless you include other files that don't need to be URL -
addressable.
NOTE
For more information about the extension manifest file, such as its properties and what they do, check out the extension
manifest reference.
Step 6: Package, Publish and Share

Once you've written your extension, the next step towards getting it into the marketplace is to package all of your
files together. All extensions are packaged as VSIX 2.0 compatible .vsix files - Microsoft provides a cross-platform
command line interface (CLI) to package your extension.
Get the packaging tool
You can install or update the TFS Cross Platform Command Line Interface (tfx-cli) using npm , a component of
Node.js, from your command line.
npm i -g tfx-cli
Package your extension

Packaging your extension into a .vsix file is effortless once you have the tfx-cli, simply navigate to your extension's
home directory and run the following command.
tfx extension create --manifest-globs vss-extension.json
NOTE
An extension/integration's version must be incremented on every update.
When updating an existing extension, either update the version in the manifest or pass the --rev-version command line
switch. This will increment the patch version number of your extension and save the new version to your manifest.
After you have your packaged extension in a .vsix file, you're ready to publish your extension to the marketplace.
Create publisher for the extension
All extensions, including those from Microsoft, are identified as being provided by a publisher. If you aren't
already a member of an existing publisher, you'll create one.
1. Sign in to the Visual Studio Marketplace Publishing Portal
2. If you are not already a member of an existing publisher, you'll be prompted to create a publisher. If you're not
prompted to create a publisher, scroll down to the bottom of the page and select Publish Extensions
underneath Related Sites.
Specify an identifier for your publisher, for example: mycompany-myteam
This will be used as the value for the publisher attribute in your extensions' manifest file.
Specify a display name for your publisher, for example: My Team
3. Review the Marketplace Publisher Agreement and click Create
Now your publisher is defined. In a future release, you'll be able to grant permissions to view and manage your
publisher's extensions. This will make it easy (and more secure) for teams and organizations to publish extensions
under a common publisher, but without the need to share a set of credentials across a set of users.
You need to update the vss-extension.json manifest file in the samples to replace the dummy publisher
ID fabrikam with your publisher ID.
Publish and share the extension
After creating a publisher, you can now upload your extension to the marketplace.
1. Find the Upload new extension button, navigate to your packaged .vsix file, and select upload.
You can also upload your extension via the command line by using the tfx extension publish command instead
of tfx extension create to package and publish your extension in one step. You can optionally use --share-with
to share your extension with one or more accounts after publishing. You'll need a personal access token, too.
tfx extension publish --manifest-globs your-manifest.json --share-with yourOrganization

Step 7: Add Widget From the Catalog
Now, go to your team dashboard at http://dev.azure.com/{yourOrganization}/{yourProject}. If this page is already
open, then refresh it. Hover on the Edit button in the bottom right, and click on the Add button. This should open
the widget catalog where you will find the widget you just installed. Choose your widget and click the 'Add'
button to add it to your dashboard.
Part 2: Hello World with Azure DevOps Services REST API

Widgets can call any of the REST APIs in Azure DevOps Services to interact with Azure DevOps Services
resources. In this example, we use the REST API for WorkItemTracking to fetch information about an existing
query and display some query info in the widget right below the "Hello World" text.
Step 1: HTML
Copy the file hello-world.html from the previous example, and rename the copy to hello-world2.html . Your
folder will now look like below:
|--- README.md
|--- sdk
|--- node_modules
|--- scripts
|--- VSS.SDK.min.js
|--- img
|--- logo.png
|--- scripts
|--- hello-world2.html // renamed copy of hello-world.html
Add a new div element right below the h2 to hold the query information. Update the name of the widget from
HelloWorldWidget to HelloWorldWidget2 in the line where you call VSS.register . This will allow the framework to
uniquely identify the widget within the extension.
<!DOCTYPE html>
<html>
<head>
VSS.init({
});

VSS.register("HelloWorldWidget2", function () {
return {
}
}
});
});
</script>
</head>
<body>
<div id="query-info-container"></div>
</div>
</body>
</html>
Step 2: Access Azure DevOps Services Resources

To enable access to Azure DevOps Services resources, scopes need to be specified in the extension manifest. We
will add the vso.work scope to our manifest.
This scope indicates the widget needs read-only access to queries and workitems. See all available scopes here.
Add the below at the end of your extension manifest.
{
...,
"scopes":[
"vso.work"
]
}
Warning: Adding or changing scopes after an extension is published is currently not supported. If you have already uploaded
your extension, you need remove it from the marketplace. Go to Visual Studio Marketplace Publishing Portal, right-click on your
extension and select "Remove".
Step 3: Make the REST API Call

There are many client-side libraries that can be accessed via the SDK to make REST API calls in Azure DevOps
Services. These are called REST clients and are JavaScript wrappers around Ajax calls for all available server side
endpoints. You can use methods provided by these clients instead of writing Ajax calls yourself. These methods
map the API responses to objects that can be consumed by your code.
In this step, we will update the VSS.require call to load TFS/WorkItemTracking/RestClient which will provide the
WorkItemTracking REST client. We can use this REST client to get information about a query called Feedback
under the folder Shared Queries .
Inside the function that we pass to VSS.register , we will create a variable to hold the current project ID. We need
this to fetch the query. We will also create a new method getQueryInfo to use the REST client. This method that is
then called from the load method.
The method getClient will give an instance of the REST client we need. The method getQuery returns the query
wrapped in a promise. The updated VSS.require will look as follows:
VSS.require(["TFS/Dashboards/WidgetHelpers", "TFS/WorkItemTracking/RestClient"],
function (WidgetHelpers, TFS_Wit_WebApi) {
var projectId = VSS.getWebContext().project.id;
var getQueryInfo = function (widgetSettings) {

// Get a WIT client to make REST calls to Azure DevOps Services
return TFS_Wit_WebApi.getClient().getQuery(projectId, "Shared Queries/Feedback")
.then(function (query) {
// Do something with the query
}, function (error) {
return WidgetHelpers.WidgetStatusHelper.Failure(error.message);
});
}
return {
// Set your title
return getQueryInfo(widgetSettings);
}
}
});
});
Notice the use of the Failure method from WidgetStatusHelper . It allows you to indicate to the widget framework
that an error has occurred and take advantage to the standard error experience provided to all widgets.
If you do not have the Feedback query under the Shared Queries folder, then replace
Shared Queries\Feedback in the code with the path of a query that exists in your project.
Step 4: Display the Response

The last step is to render the query information inside the widget. The getQuery function returns an object of
type Contracts.QueryHierarchyItem inside a promise. In this example, we will display the query ID, the query
name, and the name of the query creator under the "Hello World" text. Replace the
// Do something with the query comment with the below:
// Create a list with query details
var $list = $('<ul>');
$list.append($('<li>').text("Query Id: " + query.id));
$list.append($('<li>').text("Query Name: " + query.name));
$list.append($('<li>').text("Created By: " + ( query.createdBy? query.createdBy.displayName: "<unknown>"
) ) );
// Append the list to the query-info-container

var $container = $('#query-info-container');
$container.empty();
$container.append($list);
Your final hello-world2.html will be as follows:

<!DOCTYPE html>
<html>
<head>
VSS.init({
});
VSS.require(["TFS/Dashboards/WidgetHelpers", "TFS/WorkItemTracking/RestClient"],
function (WidgetHelpers, TFS_Wit_WebApi) {
var projectId = VSS.getWebContext().project.id;
var getQueryInfo = function (widgetSettings) {

// Get a WIT client to make REST calls to Azure DevOps Services
return TFS_Wit_WebApi.getClient().getQuery(projectId, "Shared Queries/Feedback")
.then(function (query) {
// Create a list with query details
var $list = $('<ul>');
$list.append($('<li>').text("Query ID: " + query.id));
$list.append($('<li>').text("Query Name: " + query.name));
$list.append($('<li>').text("Created By: " + (query.createdBy ?
query.createdBy.displayName: "<unknown>") ));
// Append the list to the query-info-container

$container.empty();
$container.append($list);
// Use the widget helper and return success as Widget Status

}, function (error) {
// Use the widget helper and return failure as Widget Status
return WidgetHelpers.WidgetStatusHelper.Failure(error.message);
});
}
return {
// Set your title
}
}
});
});
</script>
</head>
<body>
<div id="query-info-container"></div>
</div>
</body>
</html>
Step 5: Extension Manifest Updates

In this step we will update the extension manifest to include an entry for our second widget. Add a new
contribution to the array in the contributions property and add the new file hello-world2.html to the array in
the files property. You will need another preview image for the second widget. Name this preview2.png and place
it in the img folder.
{
...,
"contributions":[
...,
{
"id": "HelloWorldWidget2",
"targets": [
],
"properties": {
"name": "Hello World Widget 2 (with API)",
"description": "My second widget",
"previewImageUrl": "img/preview2.png",
"uri": "hello-world2.html",
"supportedSizes": [
{
"rowSpan": 1,
"columnSpan": 2
}
],
}
}
],
"files": [
{
},
{
"path": "hello-world2.html", "addressable": true
},
{
},
{
}
],
"scopes":[
"vso.work"
]
}

If you have not published your extension yet, then read this to package, publish and share your extension. If you
have already published the extension before this point, you can repackage the extension as described here and
directly update it to the marketplace.
open, then refresh it. Hover on the Edit button in the bottom right, and click on the Add button. This should open
the widget catalog where you will find the widget you just installed. Choose your widget and click the 'Add'
button to add it to your dashboard.
Part 3: Hello World with Configuration

In Part 2 of this guide, you saw how to create a widget that shows query information for a hard-coded query. In
this part, we add the ability to configure the query to be used instead of the hard-coded one. When in
configuration mode, the user will get to see a live preview of the widget based on their changes. These changes
get saved to the widget on the dashboard when the user clicks the Save button.
Step 1: HTML
Implementations of Widgets and Widget Configurations are a lot alike. Both are implemented in the extension
framework as contributions. Both use the same SDK file, VSS.SDK.min.js . Both are based on HTML as well as
JavaScript and CSS.
Copy the file html-world2.html from the previous example and rename the copy to hello-world3.html . Add
another HTML file called configuration.html . Your folder will now look like the below:
|--- README.md
|--- sdk
|--- node_modules
|--- scripts
|--- VSS.SDK.min.js
|--- img
|--- logo.png
|--- scripts
|--- configuration.html
|--- hello-world2.html // renamed copy of hello-world.html
|--- hello-world3.html // renamed copy of hello-world2.html
Add the below HTML in configuration.html . We basically add the mandatory reference to the VSS.SDK.min.js
file and a select element for the dropdown to select a query from a preset list.
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
</head>
<body>
<div class="container">
<fieldset>
<label class="label">Query: </label>
<select id="query-path-dropdown" style="margin-top:10px">
<option value="" selected disabled hidden>Please select a query</option>
<option value="Shared Queries/Feedback">Shared Queries/Feedback</option>
<option value="Shared Queries/My Bugs">Shared Queries/My Bugs</option>
<option value="Shared Queries/My Tasks">Shared Queries/My Tasks</option>
</select>
</fieldset>
</div>
</body>
</html>
Step 2: JavaScript - Configuration

We use Javascript to render content in the widget configuration just like we did for the widget in Step 3 of Part 1
in this guide. Apart from the logic to render the content, this Javascript code will initialize the VSS SDK, map the
code for your widget configuration to the configuration name and pass the configuration settings to the
framework. In our case, below is the code that loads the widget configuration. Open the file configuration.html
and the below <script> element to the <head> .
VSS.init({
});

VSS.register("HelloWorldWidget.Configuration", function () {
var $queryDropdown = $("#query-path-dropdown");
return {
load: function (widgetSettings, widgetConfigurationContext) {
var settings = JSON.parse(widgetSettings.customSettings.data);
if (settings && settings.queryPath) {
$queryDropdown.val(settings.queryPath);
}
},
onSave: function() {
var customSettings = {
data: JSON.stringify({
queryPath: $queryDropdown.val()
})
};
return WidgetHelpers.WidgetConfigurationSave.Valid(customSettings);
}
}
});
});
</script>
VSS.init , VSS.require and VSS.register play the same role as they played for the widget as described in Part 1.
The only difference is that for widget configurations, the function that is passed to VSS.register should return an
object that satisfies the IWidgetConfiguration contract.
The load property of the IWidgetConfiguration contract should have a function as its value. This function will
have the set of steps to render the widget configuration. In our case it is simply to update the selected value of the
dropdown element with existing settings if any. It is this function that is called when the framework instantiates
your widget configuration
The onSave property of the IWidgetConfiguration contract should have a function as its value. This is the
function that is called by the framework when user clicks the "Save" button in the configuration pane. If the user
input is ready to save, then serialize it to a string, form the custom settings object and use
WidgetConfigurationSave.Valid() to save the user input..
In this guide we use JSON to serialize the user input into a string. You can choose any other way to serialize the
user input to string. It will be accessible to the widget via the customSettings property of the WidgetSettings
object. The widget will then have to deserialize this which is covered in Step 4.
Step 3: JavaScript - Enable Live Preview
To enable live preview update when the user selects a query from the dropdown, we attach a change event
handler to the button. This handler will notify the framework that the configuration has changed. It will also pass
the customSettings to be used for updating the preview. To notify the framework, the notify method on the
widgetConfigurationContext needs to be called. It takes two parameters, the name of the event, which in this case
is WidgetHelpers.WidgetEvent.ConfigurationChange , and an EventArgs object for the event, created from the
customSettings with the help of WidgetEvent.Args helper method.
Add the below in the function assigned to the load property.
$queryDropdown.on("change", function () {
var customSettings = {
data: JSON.stringify({
queryPath: $queryDropdown.val()
})
};
var eventName = WidgetHelpers.WidgetEvent.ConfigurationChange;
var eventArgs = WidgetHelpers.WidgetEvent.Args(customSettings);
widgetConfigurationContext.notify(eventName, eventArgs);
});
You need to notify the framework of configuration change at least once so that the "Save" button can be
enabled.
At the end, your configuration.html looks like this:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
VSS.init({
});

VSS.register("HelloWorldWidget.Configuration", function () {
var $queryDropdown = $("#query-path-dropdown");
return {
load: function (widgetSettings, widgetConfigurationContext) {
if (settings && settings.queryPath) {
$queryDropdown.val(settings.queryPath);
}
$queryDropdown.on("change", function () {
var customSettings = {data: JSON.stringify({queryPath:
$queryDropdown.val()})};
var eventName = WidgetHelpers.WidgetEvent.ConfigurationChange;
var eventArgs = WidgetHelpers.WidgetEvent.Args(customSettings);
widgetConfigurationContext.notify(eventName, eventArgs);
});
},
onSave: function() {
var customSettings = {data: JSON.stringify({queryPath:
$queryDropdown.val()})};
return WidgetHelpers.WidgetConfigurationSave.Valid(customSettings);
}
}
});
});
</script>
</head>
<body>
<div class="container">
<fieldset>
<label class="label">Query: </label>
<select id="query-path-dropdown" style="margin-top:10px">
<option value="" selected disabled hidden>Please select a query</option>
<option value="Shared Queries/Feedback">Shared Queries/Feedback</option>
<option value="Shared Queries/My Bugs">Shared Queries/My Bugs</option>
<option value="Shared Queries/My Tasks">Shared Queries/My Tasks</option>
</select>
</fieldset>
</div>
</body>
</html>
Step 4: JavaScript - Implement Reload in The Widget

Till this point what we have done is set up widget configuration to store the query path selected by the user. We
now have to update the code in the widget to use this stored configuration instead of the hard-coded
Shared Queries/Feedback from the previous example.
Open the file hello-world3.html and update the name of the widget from HelloWorldWidget2 to
HelloWorldWidget3 in the line where you call VSS.register . This will allow the framework to uniquely identify the
widget within the extension.
The function mapped to HelloWorldWidget3 via VSS.register currently returns an object that satisfies the
IWidget contract. Since our widget now needs configuration, this function needs to be updated to return an
object that satisfies the IConfigurableWidget contract. To do this, update the return statement to include a
property called reload as below. The value for this property will be a function that calls the getQueryInfo method
one more time. This reload method gets called by the framework every time the user input changes to show the
live preview. This is also called when the configuration is saved.
return {
// Set your title
},
reload: function (widgetSettings) {
}
}
The hard-coded query path in getQueryInfo should be replaced with the configured query path which can be
extracted from the parameter widgetSettings that is passed to the method. Add the below in the very beginning
of the getQueryInfo method and replace the hard-coded querypath with settings.queryPath .

if (!settings || !settings.queryPath) {
$container.empty();
$container.text("Sorry nothing to show, please configure a query path.");
}
At this point, your widget is ready to render with the configured settings.
You will notice that both the load and the reload properties have a similar function. This would be the case
for most simple widgets. For complex widgets, there would be certain operations that you would want to run
just once no matter how many times the configuration changes. Or there might be some heavy-weight
operations that need not run more than once. Such operations would be part of the function corresponding
to the load property and not the reload property.
Step 5: Extension Manifest Updates

Open the vss-extension.json file to include two new entries to the array in the contributions property. One for
the HelloWorldWidget3 widget and the other for its configuration. You will need yet another preview image for the
third widget. Name this preview3.png and place it in the img folder. Update the array in the files property to
include the two new HTML files we have added in this example.
{
...
"contributions": [
... ,
{
"targets": [
"ms.vss-dashboards-web.widget-catalog",
"fabrikam.vsts-extensions-myExtensions.HelloWorldWidget.Configuration"
],
"properties": {
"name": "Hello World Widget 3 (with config)",
"description": "My third widget",
"supportedSizes": [
{
"rowSpan": 1,
"columnSpan": 2
}
],
}
},
{
"id": "HelloWorldWidget.Configuration",
"type": "ms.vss-dashboards-web.widget-configuration",
"targets": [ "ms.vss-dashboards-web.widget-configuration" ],
"properties": {
"name": "HelloWorldWidget Configuration",
"description": "Configures HelloWorldWidget",
"uri": "configuration.html"
}
}
],
"files": [
{
},
{
},
{
},
{
"path": "configuration.html", "addressable": true
},
{
},
{
}
],
...
}
Note that the contribution for widget configuration follows a slightly different model than the widget itself. A
contribution entry for widget configuration has:
The id to identify your contribution. This should be unique within an extension.
The type of contribution. For all widget configurations, this should be
ms.vss-dashboards-web.widget-configuration
The array of targets to which the contribution is contributing. For all widget configurations, this will have a
single entry: ms.vss-dashboards-web.widget-configuration .
The properties that contains a set of properties which includes name, description, and the URI of the HTML
file used for configuration.
To support configuration, the widget contribution needs to be changed as well. The array of targets for the
widget needs to be updated to include the ID for the configuration in the form < publisher >.<
id for the extension >.< id for the configuration contribution > which in this case will be
fabrikam.vsts-extensions-myExtensions.HelloWorldWidget.Configuration
Warning: If the contribution entry for your configurable widget does not target the configuration using the right publisher and
extension name as described above, then configure button will not show up for the widget.
At the end of this part, the manifest file should contains three widgets and one configuration. You can get the
complete manifest from the sample here.
If you have not published your extension yet, then read this to package, publish and share your extension. If you
have already published the extension before this point, you can repackage the extension as described here and
directly update it to the marketplace.
open, refresh it. Hover on the Edit button in the bottom right, and click on the Add button. This should open the
widget catalog where you will find the widget you just installed. Choose your widget and click the 'Add' button to
add it to your dashboard.
You would see a message asking you to configure the widget.
There are 2 ways to configure widgets. One is to hover on the widget, click on the ellipsis that appears on the top
right corner and then click Configure. The other is to click on the Edit button in the bottom right of the dashboard,
and then click the configure button that appears on the top right corner of the widget. Either will open the
configuration experience on the right side, and a preview of your widget in the center. Go ahead and choose a
query from the dropdown. The live preview will show the updated results. Click on "Save" and your widget will
display the updated results.
Step 8: Configure More (optional)
You can add as many HTML form elements as you need in the configuration.html for additional configuration.
There are two configurable features that are available out of the box: widget name and widget size.
By default, the name that you provide for your widget in the extension manifest is stored as the widget name for
every instance of your widget that ever gets added to a dashboard. You can allow users to configure this, so that
they can add any name they want to their instance of your widget. To allow such configuration, add
isNameConfigurable:true in the properties section for your widget in the extension manifest.
If you provide more than one entry for your widget in the supportedSizes array in the extension manifest, then
users can configure the widget's size as well.
The extension manifest for the third sample in this guide would look like the below if we enable the widget name
and size configuration:
{
...
"contributions": [
... ,
{
"targets": [
"ms.vss-dashboards-web.widget-catalog", "fabrikam.vsts-extensions-
myExtensions.HelloWorldWidget.Configuration"
],
"properties": {
"name": "Hello World Widget 3 (with config)",
"description": "My third widget",
"isNameConfigurable": true,
"supportedSizes": [
{
"rowSpan": 1,
"columnSpan": 2
},
{
"rowSpan": 2,
"columnSpan": 2
}
],
}
},
...
}
With the above change, repackage and update your extension. Refresh the dashboard that has this widget (Hello
World Widget 3 (with config)). Open the configuration mode for your widget, you should now be able to see the
option to change the widget name and size.
Go ahead and choose a different size from the drop down. You will see the live preview get resized. Save the
change and the widget on the dashboard will be resized as well.
Warning: If you remove an already supported size, then the widget will fail to load properly. We are working on a fix for a
future release.
You will notice that changing the name of the widget does not result in any visible change in the widget. This is
because our sample widgets do not display the widget name anywhere. Let us modify the sample code to display
the widget name instead of the hard-coded text "Hello World".
To do this, replace the hard-coded text "Hello World" with widgetSettings.name in the line where we set the text of
the h2 element. This will ensure that the widget name gets displayed every time the widget gets loaded on page
refresh. Since we want the live preview to be updated every time the configuration changes, we should add the
same code in the reload part of our code as well. The final return statement in hello-world3.html will be as
follows:
return {
// Set your title
$title.text(widgetSettings.name);
},
reload: function (widgetSettings) {
// Set your title
$title.text(widgetSettings.name);
}
}
Repackage and update your extension again. Refresh the dashboard that has this widget. Any changes to the
widget name in the configuration mode will update the widget title now.
Add a chart
This page demonstrates how you can add charts to your extensions. Charts can be added to any Azure DevOps
Services extension.
These charts are easy to create, resizable, interactive and consistent with the Azure DevOps Services look and feel.
The following chart types are supported:
1. Line
2. Bar
3. Column
4. Area
5. Stacked bar
6. Stacked column
7. Stacked area
8. Pie
9. Pivot table
10. Histogram
If you're in a hurry and want to get your hands on the code right away, you can download the complete
samples. Once downloaded, go to the charts folder, then follow the packaging and publishing instructions to
publish the sample extension. The extension contains sample chart widgets.
How to organize your code

For the purposes of this tutorial, we'll be creating a widget and adding a chart to it. To do so, in the home folder for
your project, create a chart.html file with the following contents:
HTML file
<!DOCTYPE html>
<html>
<head>
<script src="sdk/scripts/VSS.SDK.js"></script>
<script src="scripts/pie-chart.js"></script>
</head>
<body>
<h2 class="title">Chart Widget</h2>
<div id="Chart-Container"></div>
</div>
</body>
</html>
Use the npm install command to retrieve the SDK: npm install vss-web-extension-sdk . To learn more about
the SDK, visit the Client SDK GitHub Page.
Ensure that the VSS.SDK.js file is inside the sdk/scripts folder so that the path is home/sdk/scripts/VSS.SDK.js .
Images
Add the following images to an img folder in your project directory so that the path is home/img/logo.png and
home/img/CatalogIcon.png :
1. Extension logo
2. Catalog icon
Extension manifest file
In the home folder of your project, create your extension manifest file. Create a vss-extension.json file with the
following contents:
{
"manifestVersion": 1,
"id": "samples-charts",
"version": "1.0.0",
"name": "Interactive Charts in Azure DevOps Services",
"description": "Samples of interactive charts from the Chart SDK.",
"publisher": "Fabrikam",
"targets": [
{
"id": "Microsoft.VisualStudio.Services"
}
],
"icons": {
"default": "img/logo.png"
},
"demands": ["contribution/ms.vss-dashboards-web.widget-sdk-version-2", "contribution/ms.vss-web.charts-
service"],
"contributions": [
{
"id": "chart",
"targets": [
],
"properties": {
"name": "Sample Chart",
"description": "A simple chart widget with no configuration and hard-coded data.",
"catalogIconUrl": "img/CatalogIcon.png",
"uri": "chart.html",
"supportedSizes": [
{
"rowSpan": 2,
"columnSpan": 2
}
],
"supportedScopes": [
"project_team"
]
}
}
],
"files": [
{
"path": "chart.html",
"addressable": true
},
{
"path": "sdk/scripts/VSS.SDK.js",
"addressable": true
},
{
"path": "img",
"addressable": true
},
{
"path": "scripts",
"addressable": true
}
],
"scopes": [
]
}
Before uploading this extension, you'll need to update the publisher to yours.
Put the following code snippets into a chart.js file in a scripts folder, so that the path is home/scripts/chart.js .
Then follow the packaging and publishing instructions to publish your extension.
Charts
Pie chart
This sample renders a pie chart. The data and labelValues have been hardcoded here, and would need to be
changed to the data you want to visualize.
VSS.init({
});
VSS.require([
"TFS/Dashboards/WidgetHelpers",
"Charts/Services"
],
function (WidgetHelpers, Services) {
VSS.register("PieChart", function () {
return {
load:function() {
return Services.ChartsService.getService().then(function(chartService){
var $container = $('#Chart-Container');
var chartOptions = {
"hostOptions": {
"height": "290",
"width": "300"
},
"chartType": "pie",
"series": [{
"data": [11, 4, 3, 1]
}],
"xAxis": {
"labelValues": ["Design", "On Deck", "Completed", "Development"]
},
"specializedOptions": {
"showLabels": "true",
"size": 200
}
};
chartService.createChart($container, chartOptions);
});
}
}
});
});
Here, the chart's size is defined in hostOptions . The series property is an array and contains a single object with
data in it. The xAxis object contains labelValues which correspond to the data . For pie charts, we also have
some special options that are defined by the specializedOptions property. Here, we're explicitly enabling data
labels for the pie chart. We also need to set the size of the pie chart by specifying its outer diameter.
Rendering the chart requires a container to render it in, the chart options, and a call to the Chart Service to get
initialize the chart and render it.
Stacked area chart
This sample renders a stacked area chart.This chart type is ideal for comparing a relationship of parts to a whole
and highlighting general trends across categories. It is commonly used to compare trends over time. This sample
also specifies a custom color for one of the series being rendered.
VSS.init({
});
VSS.require([
"Charts/Services"
],
VSS.register("StackedAreaChart", function () {
return {
load:function() {
"hostOptions": {
"height": "290",
"width": "300"
},
"chartType": "stackedArea",
"series": [
{
"name": "Completed",
"data": [1,3,4,3,6,1,9,0,8,11]
},
{
"name": "Development",
"data": [1,1,0,3,0,2,8,9,2,8]
},
{
"name": "Design",
"data": [0,0,0,6,1,1,9,9,1,9],
"color": "#207752"
},
{
"name": "On Deck",
"data": [1,2,4,5,4,2,1,7,0,6]
}
],
"xAxis": {
"labelFormatMode": "dateTime_DayInMonth",
"labelValues": [
"1/1/2016",
"1/2/2016",
"1/3/2016",
"1/4/2016",
"1/5/2016",
"1/6/2016",
"1/7/2016",
"1/8/2016",
"1/9/2016",
"1/10/2016"
]
}
}
});
}
}
});
});
Pivot table
This sample renders a Pivot Table. This chart type helps arrange and summarize complex data in a tabular form.
VSS.init({
});
VSS.require([
"Charts/Services"
],
VSS.register("PivotTable", function () {
return {
load:function() {
"hostOptions": {
"height": "290",
"width": "300"
},
"chartType": "table",
"xAxis": {
"labelValues": ["Design","In Progress","Resolved","Total"]
},
"yAxis": {
"labelValues": ["P1","P2","P3","Total"]
},
"series": [
{
"name": "Design",
"data": [
[0,0,1],
[0,1,2],
[0,2,3]
]
},
{
"name": "In Progress",
"data": [
[1,0,4],
[1,1,5],
[1,2,6]
]
},
{
"name": "Resolved",
"data": [
[2,0,7],
[2,1,8],
[2,2,9]
]
},
{
"name": "Total",
"data": [
[3,0,12],
[3,1,15],
[3,2,18],
[0,3,6],
[1,3,15],
[2,3,24],
[3,3,10]
],
"color": "rgba(255,255,255,0)"
"color": "rgba(255,255,255,0)"
}
]
}
});
}
}
});
});
Create an Analytics widget for Azure DevOps

You can build your own Analytics widget to display in a Dashboard in Azure DevOps. The example widget on
github demonstrates the following:
How to render trend lines associated with work item states
How to query a dataset, whe a user will configure through the widget configuration view
How to build and publish the widget to the Azure DevOps marketplace With this information, you'll be able to
create your own Analytics widget.
NOTE
Feature availability: The Analytics Marketplace extension is available for Azure DevOps and Azure DevOps Server 2019 and
later. Installing it provides several advanced widgets, Power BI integration, and access to the OData feed.
If you are looking for information about the Azure Analysis Services, see Azure Analysis Services.
Prerequisites
This example provides a ready-made widget, covering basics from topics in Dashboards, Charting and Analytics.
The following documents provide more grounding on details demonstrated in this example:
1. Create an Azure DevOps Widget Extension, reference the Widget extensions sample
2. Render an Azure DevOps Chart Control, reference Add a Chart
3. Query OData from Analytics
Provide a configuration view

1. Run simple analytics queries required by UI controls used for configuring a view.
2. Manage state of configuration UI, with updates based on user actions, and with new data from Analytics
queries.
3. Render configuration UI using Typescript and React.
Render data within a Widget

1. Run a user configured query as a POST Request
2. Interpret data from analytics to render a chart
Next steps
To avoid excess complexity in the sample, we omitted certain technologies and practices, which a production
widget should certainly include. The ui-fabric-react sample on github highlights a build process which exercises
these details.
1. Javascript bundling and content minification - The set of small, loose script files in the sample can load much
more quickly when consolidate into a single file, and minified.
2. Fabric UI Controls - Fabric UI controls provide a rich set of configuration UI components for React.
Widget catalog
NOTE
Widgets and multiple dashboards are not supported features in TFS 2013, instead, you can pin items to a team
homepage. Consider upgrading to the latest TFS version to get access to the widget catalog and multiple team
dashboards.
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.
The following widgets are available to you. Team-scoped widgets display data based on the selected team
context. User-focused widgets display information based on the logged-in user.
ANALYTICS TEAM-SCOPED OTHER
- Burndown chart - New Work item - Code tile

- Burnup chart - Other links - Chart for work items
- Cumulative flow diagram - Pull request - Embedded web page
- Cycle time - Sprint burndown - Query results
- Lead time - Sprint capacity - Query tile
- Test results trend (Advanced) - Sprint overview - Markdown
- Velocity - Team members - Visual Studio Shortcuts
- Team room - Welcome
Build, test, release - Work links
- Chart for build history User-focused

- Chart for test plans
- Deployment status - Assigned to me
- Release pipeline overview - Pull request
- Requirements quality
- Test results trend
ANALYTICS TEAM-SCOPED OTHER
- Burndown chart - New Work item - Code tile

- Burnup chart - Other links - Chart for work items
- Cumulative flow diagram - Pull request - Embedded web page
- Cycle time - Sprint burndown - Query results
- Lead time - Sprint capacity - Query tile
- Velocity - Sprint overview - Markdown
- Team members - Visual Studio Shortcuts
Build, test, release - Team room - Welcome
- Work links
- Chart for build history
- Chart for test plans User-focused
- Deployment status
- Release pipeline overview - Assigned to me
- Requirements quality - Pull request
- Test results trend
TEAM-SCOPED USER-FOCUSED BUILD, TEST, RELEASE OTHER
- New Work item - Assigned to me - Chart for build history - Code tile
- Other links - Pull request - Chart for test plans - Chart for work items
- Pull request - Deployment status - Embedded web page
- Sprint burndown - Requirements quality - Query results
- Sprint capacity - Test results trend - Query tile
- Sprint overview - Markdown
- Team members - Visual Studio Shortcuts
- Team room - Welcome
- Work links
TEAM-SCOPED USER-FOCUSED BUILD, TEST, RELEASE OTHER
- New Work item - Assigned to me - Chart for build history - Code tile
- Other links - Pull request - Chart for work items
- Pull request - Query results
- Sprint burndown - Query tile
- Sprint capacity - Markdown
- Sprint overview - Visual Studio Shortcuts
- Team members - Welcome
- Team room
- Work links
NOTE
Widgets specific to a service are disabled if the service they depend on has been disabled. For example, if Boards is
disabled, work tracking Analytics widgets are disabled and won't appear in the widget catalog. To re-enable a service, see
Turn an Azure DevOps service on or off.
Azure Boards/Work widgets

Assigned to me
Displays the list of work items currently assigned to the currently logged in user. The list ignores closed or
deleted work items.
Chart for work items
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.
Requires 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.
New Work item
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 or default iteration. To change team defaults, see About teams and Agile tools.
Other links
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.
The following links are displayed when the corresponding resource is configured for the project:
View project portal (opens either a SharePoint site or URL that's been configured as the project's portal.
View process guidance (opens either a SharePoint site or URL that's been configured as the project's
process guidance.
View reports (opens SQL Server Reporting Services). To add or update reports for a project, see Add
reports to a 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
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
Inserts the team's capacity bar chart for the current sprint. To plan and monitor their sprint resources, team set
capacity and update Remaining Work throughout the sprint. See Set capacity.
Sprint overview
Inserts a configurable overview of sprint progress. You can choose between a count of story points or number
of work items. Teams plan their sprints by defining sprints and assigning backlog items to an iteration.
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 assign backlog items to an iteration.
Work links
Provides quick access to open the following Agile tools and team resources:
Backlog
Kanban Board
Task board
Queries
Analytics widgets
To add Analytics widgets to your dashboard, you first need to install the Analytics Marketplace extension. You
can then add the widget(s) to your dashboard. You must be the organization owner or a member of the Project
For an overview of each of these widgets, see Widgets based on the Analytics Service.
Burndown chart
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
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.
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
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
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.
Test Results Trend (Advanced)
NOTE
Feature availability: The Test Results Trend (Advanced) widget is only available for an Azure DevOps Services
organization that has the Analytics Marketplace extension installed.
The Test Results Trend (Advanced) widget provides near real-time visibility into test data for multiple builds
and releases. The widget shows a trend of your test results for selected pipelines. You can use it to track the
daily count of test, pass rate, and test duration. Tracking test quality over time and improving test collateral is
key to maintaining a healthy DevOps pipeline.
The widget supports tracking advanced metrics for one or more build pipelines or release pipelines. The
widget also allows filtering of test results by outcome, stacking metrics, and more.
To learn more, see Configure the Test Results Trend (Advanced) widget.
Velocity
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.
Azure Repos/Code widgets

Code tile
Adds a configurable tile to display the summary of a code folder or Git repository. To configure, simply choose
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
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.
Azure Pipelines/Build and Release widgets

Chart for build history
Adds a tile to display a histogram of all builds run for the configured build pipeline. From the configuration
dialog, select the build you want to monitor. Hover over a bar to learn how long the build took to complete.
Choose the bar to open the summary for that specific build. Bar color indicates: green-completed, red-failed,
and yellow -completed without tests.
Requires 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.
Deployment status
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 pipeline,
branch, and linked release pipelines.
In order view the test summary across multiple environments in a release, the widget provides a matrix view of
each environment and corresponding test pass rate. You can choose any cell to see a more detailed view for the
selected environment.
Release pipeline overview

Configurable widget that you can use to view and track the status of a release pipeline. 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 pipeline in the left column to filter the list to just releases for
that pipeline.
Requirements quality
Configurable widget that you can use to track quality continuously from a build or release pipeline. The widget
shows the mapping between a requirement and latest test results executed against that requirement. It
provides insights into requirements traceability e.g. requirements not meeting the quality, requirements not
tested etc. To learn more about setting up traceability see Requirements traceability
Azure Test Plans/Test widgets

Chart for test plans
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.
Test results trend
Adds a configurable tile that displays the trend of test results, such as passed or failed tests, for the selected
build or release pipeline. The widget helps you visualize the test trends over a period of time, thereby surfacing
patterns about test failures, test duration etc.
From the configuration dialog, select the build or release whose test results you'd like to monitor. There are
multiple chart options to choose from (Line, Column & Stacked Column) based on your preference. Optionally
you can map the trend of test duration on the existing chart by adding a secondary line chart.
The widget provides the basic trend of the test results. To get deeper insights and higher configurability view
Test Analytics
Informational content and other links

Embedded web page
Adds a configurable tile to display the contents of a web page. Only webpages that allow iframe embedding
are supported.
Markdown
Adds a configurable tile to display any type of information, guidance, or links that you want. You can also
configure the widget to point to a file stored in your repository. From the configuration dialog, add the
information you want to share with your team. To learn more, see Add Markdown to a dashboard.
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.
Requires TFS 2015.1 or later version. For TFS 2015.2 or later versions, you can configure the widget to point
to a file stored in your repository.
Team members
Shows team member profiles and, on-hover, their user 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
Provides status and access to team rooms. Available for TFS 2015.1 through TFS 2017.2 versions.
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.
NOTE
Feature availability: Team Rooms have been deprecated as described in Deprecation of Team Rooms blog post. Several
good solutions are available that integrate well with TFS that support notifications and chat, such as Microsoft Teams
and Slack.
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 Boards/Boards (Work/Boards), Repos (Code), and Pipelines (Build or Build-
Release) pages 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 organization owner 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 (API).
Syntax guidance for Markdown usage
Here you can find some basic Markdown syntax guidance and specific guidance for using Markdown in Azure
DevOps features. You can use both common Markdown conventions and GitHub-flavored extensions.
Having the right guidance at the right time is critical to success. Use Markdown to add rich formatting, tables, and
images to your project pages, README files, dashboards, and pull request comments.
You can provide guidance in the following areas using Markdown:
Project wiki
Publish code as wiki
Markdown widget added to a dashboard
Project page or Welcome pages
Repository README files
Pull request comments
Definition of Done (Kanban board)
Project wiki
NOTE
Rich Markdown rendering in code repositories is supported for TFS 2018.2 and later versions. You can create rich
README.md files in the code repositories. TheMarkdown rendering of the MD files in code repositories supports HTML tags,
block quotes, emojis, image resizing, and mathematical formulas. There is parity inMarkdown rendering in Wiki and MD files
in code.

NOTE
With TFS 2017.1, welcome pages, theMarkdown widget on team dashboards, and the Definition of Done on Kanban boards
no longer supports file links in theirMarkdown. As a workaround, you can include your file link as text in the Markdown.

Basic format elements

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 a H1 header
## This is a H2 header
### This is a H3 header
#### This is a H4 header
##### This is a 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, select Enter to insert a line break, and begin text on a new line.
In a Markdown file or widget, enter two spaces before the line break to begin a new paragraph, or enter two
consecutive line breaks to begin a new paragraph.
In pull request comments, select 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 consecutive line breaks to
begin a new paragraph.
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 Enter 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.
Space is added in between paragraphs.
Block quotes
Quote previous comments or text to set the context for your comment or text.
Quote single lines of text with > before the text. Use many > characters to nest quoted text. Quote blocks of
lines of text by using the same level of > across many lines.
Example:
> Single line quote

>> Nested
>> multiple line
>> quote
Result:
Horizontal rules
To add a horizontal rule, add a line that's a series of dashes --- . The line above the line containing the --- must
be blank.
Example:
above
----
below
Result:
above
below
Emphasis (bold, italics, strikethrough)
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 strikethrough: surround the text with double tilde characters ~~ .
Combine these elements to apply emphasis to text.

NOTE
There is noMarkdown syntax that supports underlining text. Within a wiki page, you can use the HTML <u> tag to
generate underlined text. For example, <u>underlined text</u> yields underlined text`.
NOTE
There is noMarkdown syntax that supports underlining text. Within a wiki page in TFS 2018.2 and later versions, you can
use the HTML <u> tag to generate underlined text. For example, <u>underlined text</u> yields underlined text`.
NOTE
There is noMarkdown syntax that supports underlining text.
Example:
Use _emphasis_ in comments to express **strong** opinions and point out ~~corrections~~
**_Bold, italicized text_**
**~~Bold, strike-through text~~**
Result:
Use emphasis in comments to express strong opinions and point out corrections Bold, italicized 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. To indicate code inline, wrap it with one
backtick quote ( ` ).
Example:
```
$ sudo npm install vsoagent-installer -g
```
Result:
$ sudo npm install vsoagent-installer -g
Example:
To install the Microsoft Cross Platform Build & Release Agent, run the following: `$ sudo npm
install vsoagent-installer -g`.
Result: To install the Microsoft Cross Platform Build & Release Agent run the following command:
$ sudo npm install vsoagent-installer .
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;
```
const count = records.length;
``` csharp
Console.WriteLine("Hello, World!");
```
Console.WriteLine("Hello, World!");
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. You can format tables in pull requests, wiki,
and Markdown files such as README files and Markdown widgets.
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)
To start a new line, use the HTML break tag ( <br/> ) (Works within a Wiki but not elsewhere)
Make sure to end each row with a CR or LF.
A blank space is required before and after work item or pull request (PR ) mentions inside a table cell.
Example:
| Heading 1 | Heading 2 | Heading 3 |

|-----------|:-----------:|-----------:|
| Cell A1 | Cell A2 | Cell A3 |
| Cell B1 | Cell B2 | Cell B3<br/>second line of text |
Result:
HEADING 1 HEADING 2 HEADING 3
Cell A1 Cell A2 Cell A3
Cell B1 Cell B2 Cell B3

second line of text
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. 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.
Ordered or numbered lists
Example:
1. First item.
2. Second item.
3. Third item.
Result:
1. First item.
2. Second item.
3. Third item.
Bullet lists
Example:
- Item 1
- Item 2
- Item 3
Result:
Item 1
Item 2
Item 3
Nested lists
Example:
1. First item.
- Item 1
- Item 2
- Item 3
1. Second item.
- Nested item 1
- Nested item 2
- Nested item 3
Result:
1. First item.
Item 1
Item 2
Item 3
2. Second item.
Nested item 1
Nested item 2
Nested item 3
Links
In pull request comments and wikis, HTTP and HTTPS URLs are automatically formatted as links. You can link to
work items by entering the # key and a work item ID, and then choosing the work item from the list.
Avoid auto suggestions for work items by prefixing # with a backslash ( \ ). This can be useful if you want to use #
for color hex codes.
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
Links to documents on file shares using file:// aren't supported on TFS 2017.1 and later versions. This restriction has
been implemented for security purposes.
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/library/618ayhy6.aspx)
Result:
C# language reference
Link to work items from a Wiki page
Enter the pound sign ( # ), and then enter a work item ID.
NOTE
This feature is available with TFS 2018.2 and later versions.
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. In general, the following conventions:
Punctuation marks and leading white spaces within a file name are ignored
Upper case letters are converted to lower
Spaces between letters are converted to dashes (-).
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
To highlight issues or make things more interesting, you can add images and animated GIFs to the following in
your pull requests:
Comments
Markdown files
Wiki pages
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:
![Illustration to use for new users](https://docs.microsoft.com/media/illustrations/bcs-user-

management-add-customer-1.svg)
Result:
The path to the image file can be a relative path or the absolute path in Git or TFVC, 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
The syntax to support image resizing is only supported in pull requests and in the Wiki.
Checklist or task list

Lightweight task lists are great ways to track progress on a list of todos as a pull request creator or reviewer in the
PR description or in a wiki page. Select the Markdown toolbar to get started or apply the format to selected text.
You can Use [ ] or [x] to support checklists. You need to precede the checklist with either -<space> or
1.<space> (any numeral).
Example - Apply the task list Markdown to a highlighted list

After you've added a task list, you can check the boxes to mark items as completed. These are expressed and
stored within the comment as [ ] and [x] in Markdown.
Example - Format a list as a task list
- [ ] A
- [ ] B
- [ ] C
- [x] A
- [x] B
- [x] C
Result:
NOTE
A checklist within a table cell isn't supported.
Emoji
In pull request comments and wiki pages, you can use emojis to add character and react to comments in the
request. Enter what you're feeling surrounded by : characters to get a matching emoji in your text. The full set of
emojis are supported.
In pull request comments, you can use emojis to add characters and react to comments in the request. Enter 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:
To escape emojis, enclose them using the ` character.

Example:
`:smile:` `:)` `:angry:`
Result:
:smile: :) :angry:
Ignore or escape Markdown syntax to enter specific or literal

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.
In pull request comments, 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. You can also select the paper-clip icon
in the upper right of the comment box.
NOTE
Attachments in pull requests is available with TFS 2017.1 and later versions.
If you have an image in your clipboard, you can paste it from the clipboard into the comment box or wiki page and
it renders directly into your comment or wiki page.
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. After 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.
Attachments support the following file formats.
TYPE FILE FORMATS
Code CS (.cs), Extensible Markup Language (.xml), JavaScript Object

Notation (.json), Hypertext Markup Language(.html, .htm),
Layer (.lyr), Windows PowerShell script (.ps1), Roshal Archive
(.rar), Remote Desktop Connection (.rdp), Structured Query
Language (.sql) - Note: Code attachments aren't permitted
in PR comments
Compressed files ZIP (.zip) and GZIP (.gz)
Documents Markdown (.md), Microsoft Office Message (.msg), Microsoft

Project (.mpp), Word (.doc and .docx), Excel (.xls, .xlsx and .csv),
and Powerpoint (.ppt and .pptx), text files (.txt), and PDFs
(.pdf)
Images PNG (.png), GIF (.gif), JPEG (both .jpeg and .jpg), Icons (.ico)
Visio VSD (.vsd and .vsdx)
Video MOV (.mov), MP4 (.mp4)
NOTE
Not all file formats are supported within pull requests, such as Microsoft Office Message (.msg) files.
HTML tag support in wiki pages

In wiki pages, you can also create rich content using HTML tags.
NOTE
Pasting rich content as HTML is supported in TFS 2018.2 and later versions.
Example - Embedded video
<video src="path of the video file" width=400 controls>

</video>
For example:
<video src="https://sec.ch9.ms/ch9/7247/7c8ddc1a-348b-4ba9-ab61-51fded6e7247/vstswiki_high.mp4" width=400

controls>
</video>
Result:
Example - Rich text format
<p>This text needs to <del>strikethrough</del> <ins>since it is redundant</ins>!</p>

<p><tt>This text is teletype text.</tt></p>
<font color="blue">Colored text</font>
<center>This text is center-aligned.</center>
<p>This text contains <sup>superscript</sup> text.</p>
<p>This text contains <sub>subscript</sub> text.</p>
<p>The project status is <span style="color:green;font-weight:bold">GREEN</span> even though the bug count /
developer may be in <span style="color:red;font-weight:bold">red.</span> - Capability of span
<p><small>Disclaimer: Wiki also supports showing small text</small></p>
<p><big>Bigger text</big></p>
Result:
This text needs to strikethrough since it is redundant!
This text is teletype text.
Colored text
This text is 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
Mathematical notation and characters

Both inline and block KaTeX notation is supported in wiki pages and pull requests. The following supported
elements are included:
Symbols
Greek letters
Mathematical operators
Powers and indices
Fractions and binomials
Other KaTeX supported elements
To include mathematical notation, surround the mathematical notation with a $ sign, for inline, and $$ for block,
as shown in the following examples:
NOTE
This feature is supported within Wiki pages and pull requests for TFS 2018.2 or later versions.
Example: Greek characters
$
\alpha, \beta, \gamma, \delta, \epsilon, \zeta, \eta, \theta, \kappa, \lambda, \mu, \nu, \omicron, \pi, \rho,
\sigma, \tau, \upsilon, \phi, ...
$
$\Gamma, \Delta, \Theta, \Lambda, \Xi, \Pi, \Sigma, \Upsilon, \Phi, \Psi, \Omega$
Result:
Example: Algebraic notation
Area of a circle is $\pi r^2$
And, the area of a triangle is:
$$
A_{triangle}=\frac{1}{2}({b}\cdot{h})
$$
Result:
Example: Sums and Integrals

$$
\sum_{i=1}^{10} t_i
$$
$$
\int_0^\infty \mathrm{e}^{-x}\,\mathrm{d}x
$$
Result:
Table of contents (TOC) for Wiki pages

You can now just add a tag [[_TOC_]] to enable a table of contents in your page. The TOC is generated when the
tag is added and there is at least one heading in the page.
The [[_TOC_]] can be placed anywhere in the page to render the table of contents. Only Markdown headings are
considered for TOC (HTML heading tags aren't).
All HTML and Markdown tags are stripped from the headings while adding it inside the TOC block. For example:
Adding bold and italics to a heading text renders the TOC as follows.
Consistency is maintained in the formatting in TOC.

NOTE
The tag [[_TOC_]] is case-sensitive. For example, [[_toc_]] may not render the TOC. Also, only the first instance of [[_TOC_]] is
rendered and the rest are ignored.
Embed Videos in a Wiki page

To embed videos from YouTube and Microsoft Streams in a wiki page, use the following syntax:
::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/OtqFyBA6Dbk" frameborder="0"
allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::
The iframe is the embed iframe block of the YouTube or Microsoft Streams video.
Result:
https://www.youtube.com/embed/OtqFyBA6Dbk
(The ending ":::" is required to prevent a break in the page)
YAML tags
Any file that contains a YAML block in a Wiki is processed by a table with one head and one row. The YAML block
must be the first thing in the file and must take the form of valid YAML set between triple-dashed lines. It
supports all basic datatypes, lists, and objects as values. The syntax is supported in wiki, code file preview.
Basic example:
---
tag: post
title: Hello world
---
Tags with list:
---
tags:
- post
- code
- web
title: Hello world
---
Embed Azure Boards query results in Wiki

To embed Azure Boards query results in a wiki page as a table, use the following syntax:
::: query-table <queryid>

:::
Alternatively, you can also use the toolbar icon and the query selector to embed the query results in a wiki page.
Related articles
README files
Pull requests
Markdown widget
Dashboards
Widget catalog
Wiki
Default permissions and access for charts and
dashboards
Team members and members of the of the Contributors group for a project can view charts and dashboards. The
most common built-in groups include Readers, Contributors, and Project Administrators. For a simplified view of
all default permissions assigned to built-in groups, see Default permissions and access.
Stakeholders have limited access to view charts and dashboards. To learn more, see About access levels.
For an overview of dashboard and chart features, see Dashboards, charts, & widgets.
::: moniker range="azure-devops"
TASK STAKEHOL READERS CONTRIBU TEAM ORGANIZATION

DERS TORS ADMINS OWNER/
PROJECT ADMINS
View work item query charts (from the

Queries page)
View dashboards (including work item query

charts added to the dashboard)
Create work item query and test tracking

charts 1
View the project page
Edit the project page 1
Navigate using the Project pages
Add and configure dashboards 1 With

permissio
ns set
Notes:
1. Public project Stakeholders have full access to all features.
::: moniker-end �
::: moniker range="<= azure-devops-2019"
TASK STAKEHOL READERS CONTRIBU TEAM PROJECT ADMINS

DERS TORS ADMINS
View charts and dashboards
Create work item and test tracking charts

View the project page
Edit the project page
Navigate using the Project pages
Add and configure dashboards With

permissio
ns set
::: moniker-end �
Related notes
Work across projects
Add a team administrator
Reporting roadmap for Azure DevOps and Azure
DevOps Server

The future of reporting for Azure DevOps and Azure DevOps Server is the Analytics Service.
The Analytics Service

The Analytics Service is in Public Preview. It currently contains partial data. We are working to add all reportable
data to the Analytics Service. See Data Available in Analytics for more information.
Analytics is enabled it by installing the Analytics extension
Azure DevOps Server 2019 RC1 and later versions support installation of the Analytics extension. Team
Foundation Server (TFS ) version 2018 and earlier versions do not support the Analytics extension.
Pricing for the Analytics extension

While in Public Preview, the Analytics extension is free.
We are currently working out what our pricing model will be. We plan to share details in Q4, 2018.
Azure DevOps Server, TFS, and SQL Server Reporting

Since Team Foundation Server (TFS ) was released in 2005, we've offered a reporting solution based on a data
warehouse and OLAP cube, coupled with an SSRS server to host reports.
While the configuration is somewhat complex, it provides a powerful solution. You can create custom reports by
writing customized SSRS reports. You can also create reports using Excel, and share them on SharePoint once
you've configured SharePoint to host Excel Charts.
We have no plans to bring a cloud version of our SQL Server Reporting story to Azure DevOps Services.
Future of SQL Server Reporting

We currently support SQL Server Reporting through TFS 2018, and will continue to support it in Azure DevOps
Server 2019.
We will continue to support SQL Server Reporting until Analytics can replace its functionality. After that, we will
likely support both SQL Server Reporting and Analytics for one additional major Azure DevOps Server release.
This allows customers time to convert their reports to Analytics.
Roadmap timeline
Check out the Features Timeline for the roadmap of reporting features.
Analytics

Analytics provides advanced widgets you can add to a dashboard, Power BI integration for more advanced
reporting, and OData access for extensibility. Analytics is the reporting solution for Azure DevOps.
For more information, read What is Analytics? and Reporting roadmap.
5-Minute Quickstart
Videos
https://channel9.msdn.com/Events/Connect/2017/T251/player
https://www.youtube.com/embed/VXdgjRdtBQI
Step-by-Step Tutorials
Configure a Lead Time or Cycle Time widget
Configure or view Velocity chart
Create an Analytics view
Manage Analytics views
Concepts
Data available in the Analytics Service
Analytics widgets
What are Analytics views
Default Analytics views
Performance and latency
How-to Guides
Set permissions for the Analytics Service
Manage Analytics views
Connect using Excel
Troubleshooting
Resolve errors associated with an Analytics view
Reference
Analytics OData v4 endpoint
API versioning
Resources
Dashboards
Connect to Azure DevOps using Power BI
Connect to Azure DevOps using Excel
Power BI integration
Extend Analytics with OData

Azure DevOps Services - Dashboards Index To Content

Uploaded by

Document Information

Original Description:

Original Title

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

Azure DevOps Services - Dashboards Index To Content

Uploaded by

Copyright:

Available Formats

Contents

Add widgets to your dashboard

Sample chart widgets

The Analytics Service and Analytics widgets

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

Connect to the web portal for your project

All dashboards are associated with a team.

Select a dashboard to view, modify, or favorite

2. To favorite a dashboard, hover over the dashboard and choose the .

Select a dashboard to view or modify

Add and name your dashboard

Rename, delete, and enable auto-refresh

1. To manage dashboards, choose the wrench icon.

4. To delete a dashboard, choose the delete icon.

4. To delete a dashboard, choose the delete icon.

Move or delete a widget from a dashboard

Choose Edit to modify your dashboard.

Try this next

Select a dashboard to modify

Add a widget to a dashboard

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

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

Copy a widget to another dashboard

Analytics Service widgets

Disabled Marketplace widget

Azure DevOps Services | Azure DevOps Server 2019

Add the Velocity widget to your dashboard

Learn about your team's velocity using the Velocity widget

Try this next

Connect to the web portal for your project

Add the markdown widget to a dashboard

This renders the following widget:

1. Choose to modify a dashboard.

2. Choose to open the widget catalog.

This renders the following widget:

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

Azure DevOps Services | Azure DevOps Server 2019

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

OPTION PURPOSE FOR BURNDOWN

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.

Choose additional options

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

Example: Configuring the Burndown widget to act as a Sprint

Configure the Burnup widget

Configure the CFD widget

Configure the built-in cumulative flow chart