Contents

Start using Azure Boards

What is Azure Boards?
Why use Azure Boards?
Sign up and invite some teammates
Plan and track work
Create your backlog
Kanban board quickstart
Default permissions (Security)
Key concepts
Resources
Web portal navigation
Work items
Process customization
Security & identity
 Start using Azure Boards
9/22/2018 • 2 minutes to read • Edit Online

Azure Boards | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
Use this guide to sign up and start using Azure Boards.
Start with Sign up and invite some teammates.
Then, read Plan and track work to get familiar with work items and work item types.
Next, to develop your product backlog, read Create your backlog or Use Kanban boards.
Video: Plan your work with Azure Boards
https://channel9.msdn.com/Events/Microsoft-Azure/Azure-DevOps-Launch-2018/A105/player
Additional resources
Other resources to get you up and running:
Web portal navigation
Work items
About projects and scaling your organization
 What is Azure Boards?
9/12/2018 • 6 minutes to read • Edit Online

Azure Boards | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
Azure Boards provides a suite of interactive Agile tools with which you can plan and track work, bugs, and issues.
Azure Boards is available from Azure DevOps Services and Team Foundation Server (TFS ).
Agile, a term coined in 2001 in the Agile Manifesto, encompasses approaches to software development that
emphasize incremental delivery, team collaboration, continual planning, and continual learning. The set of Agile
tools that Azure Boards provides are designed to support teams working with Agile methodologies, such as
Kanban and Scrum. To learn more, see What is Agile?.
All tools support viewing and defining work items. Each work item represents an object stored in the work item
data store. Each work item is assigned a unique identifier, an ID, which is unique within an account or project
collection.
Your Agile tool set, available from Azure Boards, consists of the following main interactive lists and signboards.
Each of these pages provide a filtered set of work items.

NOTE
The New navigation feature provides a vertical navigation experience and is in preview for Azure DevOps Services. When
you enable new navigation, you automatically enable several new Agile tool features that are described in the New Work
Hubs blog post.
On-premises Microsoft Team Foundation Server users can select Previous navigation for guidance.

New navigation
Previous navigation
Work items: Use to quickly find work items assigned to you or pivot or filter work items based on other
criteria, such as work items you're following, you're mentioned in, you've viewed or updated
Boards: Use to implement Kanban practices and visualize the flow of work for a team
Backlogs: Use to plan, prioritize, and organize the work for a team to do within a product or portfolio backlogs
Sprints: Use to plan work for a team to perform during a specific time frame referred to as a sprint
Queries: Use to define a set of filter criteria to list work items for the purposes of sharing with others or
performing bulk updates
Plans: Use to review the schedule of stories or features your teams plan to deliver. Plans show scheduled work
items defined assigned to sprints (iteration path) of selected teams against a calendar view. Requires installation
of the Delivery Plans extension.
New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.

Teams and Agile tools

A team refers to a group of project members that work in a particular product area. Those areas are represented as
area paths, hierarchical paths denoting the possible areas of ownership in an organization. A team is defined by a
name, its members, and its area paths.
These Agile tool—Boards, Backlogs, Sprints, and Plans—rely on team configurations. For example, if you want
to add a Kanban board or product backlog, you define a team. For more information on teams, see About teams
and Agile tools.
Your view and options available will differ somewhat depending on if you have enabled the New Navigation
feature, which displays a vertical navigation interface along with several changes to navigation of Agile tools.

Work items and work item types

Open Work Items to access several personalized pivots and filter functions to focus on work items you care about.
You can quickly find work items assigned to you, that you're following, or have viewed or modified recently—event
when defined for different teams and projects. To learn more, see View and add work items.
New navigation
Previous navigation

New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.

Boards
Boards present work items as cards and support quick status updates through drag-and-drop, similar to sticky
notes on a physical whiteboard. Each board supports many Kanban practices such as defining columns and
swimlanes, setting Work-in-Progress (WIP ) limits, defining the Definition of Done, and more. To get started, see
Kanban quickstart.
New navigation
Previous navigation
New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.

Backlogs
Backlogs present work items as lists. A product backlog represents your project plan, the roadmap for what your
team plans to deliver. Your backlog also provides a repository of all the information you need to track and share
with your team. Portfolio backlogs allow you to group and organize your backlog into a hierarchy. To get started,
see Create your backlog.
New navigation
Previous navigation

New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.

Sprints
Sprint backlogs and taskboards provide a filtered view of work items a team has assigned to a specific iteration
path, or sprint. Sprints are defined for a project and then selected by teams. From your backlog, you can map work
to an iteration path using drag-and-drop, and then view that work in a separate sprint backlog.
New navigation
Previous navigation
New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.
You can also filter the cards on your taskboard to show only those cards mapped to a given sprint. It is
recommended that an entire organization share the same sprint interval in order to align multiple teams in a single
org to the same rhythm. A common sprint rhythm is sometimes referred to as the "heartbeat" of an org.

Queries
Queries are filtered lists of work items based on criteria that you define using a query editor. You use queries to
find groups of work items with something in common,to triage a set of items to prioritize or assign them, or to
create status and trend charts that you can then add to dashboards. To get started, see Create a managed query.

Delivery plans
Delivery plans display work items as cards along a timeline or calendar view. This can be an effective
communication tool with managers, partners and stakeholders for a team or for several teams collaborating on
specific features or requirements.
 Why use Azure Boards?
9/22/2018 • 4 minutes to read • Edit Online

Azure Boards | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
We know you have a choice of tracking systems. So why use Azure Boards to plan and track your work, your bugs,
your customer issues?
In What is Azure Boards? we describe the main features you get with Azure Boards. Here, we provide 12
compelling reasons to take Azure Boards for a free test spin.

1. Start simply, scale as you grow

Azure Boards provides you a set of predefined work item types to support tracking features, user stories, bugs, and
tasks. You can quickly get up and running using your product backlog or Kanban board. Whatever Agile method
you use, Azure Boards supports you with the tools you need to implement that method.
As your organization grows, you can add teams to provide them the autonomy to track their work according to
their needs.

TIP
Quickly add work items using your backlog or Kanban board. Or, use work item templates to simplify defining work items by
setting values for select fields.

2. Visual, interactive tools

Visual tools help teams quickly see and share progress. For example, Kanban boards allow you to add work, update
the status of work, and monitor work in progress.

Product backlogs allow you to quickly add work items and prioritize work to keep the most important work at the
top of the stack. And, delivery plans allow teams to share their plans against a calendar view.
Use built-in scrum boards and planning tools to help your teams run effective stand-ups, planning meetings, and
retrospectives.

3. Easy to customize
Kanban boards, taskboards, and delivery plans are easily configured and customized through the user interface.
For example, with Kanban boards, you can configure columns, swimlanes, card styles, fields shown on cards, and
more—all through a common configuration dialog.

TIP
Define area paths and iteration paths to group work items by product or feature and into sprints, milestones, or other time-
related periods.

And, you can easily add custom fields, work item types, and portfolio backlogs.

4. Built-in social tools and communication

Work item forms provide built-in discussion which allows you to capture questions, notes, and communication as
they occur—maintaining a history of what a team decides on any particular work item. You can quickly bring a
team member or an entire team into the conversation using @mentions.
5. Capture information, generous cloud storage
Work items are designed to track all the information you need to track. This includes rich text editing with simple
drag-and-drop of inline images as well as adding larger attachments. You can add attachments up to 60 MB and as
many as 100 attachments.
In addition, you can link work items within a hierarchy or simple related links. Each work item form maintains a
history of changes, so you can review what changed, by whom, and when.

7. Quickly find what you need, get notified of changes

As your project grows, the number of work items used to track it grows. To support your ability to quickly find a
specific work item, Azure Boards provides you with easy-to-use tools:
Choose to follow work items to monitor updates and changes
Pivot views that show you work items assigned to you, that you elected to follow, that was recently
modified, and more
Powerful query engine to filter work item lists based on any field and use to update or triage work items
Fast, flexible adhoc search with quick inline filters
Personalize the alerts you receive for when work items are assigned to you, are changed, or other filter criteria

8. Monitor status and progress with built-in dashboards and analytics

With Azure Boards, you gain access to a number of tools to generate reports to support tracking status and trends.
The first of these are configurable dashboards to which you add one or more widgets. You configure widgets to
display the information and data you want, such as the following bug burndown widget.

In addition to dashboards, you have access to the Analytics service which has been optimized for fast read-access
and server-based aggregations. Using Analytics views and Power BI, you can create highly-sophisticated reports
on the project data of interest.

9. Office integration
For project managers that want to use familiar tools, they can import and export work item queries to and from
Microsoft Office Excel and Project. To learn more, see:
Bulk add or modify work items with Excel
Create your backlog and tasks using Project

10. Extensions and extensibility

You can gain even greater functionality by adding Marketplace extensions, many of which are free. An extension is
an installable unit that contributes new capabilities into Visual Studio, Azure DevOps Services, Team Foundation
Server, or Visual Studio Code. You can find extensions from within these products or from the Visual Studio
Marketplace.
Here's a few extensions available from the Marketplace.

In addition, using the REST API, you can create your own extensions or tools to integrate with Azure DevOps
Services.

11. Mobile app

Azure Boards makes it easy to stay on top of changes as they occur. Using our mobile browser, you can get notified
and respond to changes made to work items.
12 Start for free
Last but not least, you can start for free and add up to five free users and unlimited stakeholders.
Get started today. See Sign up for free and invite others to collaborate on your project.
 Sign up for free and invite others to collaborate on
your project
9/20/2018 • 3 minutes to read • Edit Online

Azure Boards
Sign up for an Azure DevOps organization and Azure Boards to begin planning and tracking work.

Sign up for Azure DevOps with a personal Microsoft account

1. Select the sign-up link for Azure DevOps.
2. Enter your email address, phone number, or Skype ID for your Microsoft account. If you're a Visual Studio
subscriber and get Azure DevOps as a benefit, use the Microsoft account associated with your subscription.
Choose Next.

3. Enter your password and select Sign in.

If you don't have a Microsoft account, you can create a Microsoft account at this time.
4. To get started with Azure DevOps , choose Continue.

5. Enter a name for your organization. The name you enter cannot contain spaces or special characters (such
as / \ [ ] : | < > + = ; ? or *), cannot end in a period or comma, must be less than 256 characters, and must be
unique within the DevOps namespace. You can also choose between several locations for where you want
your data hosted. Select Continue.
 You see the following dialog box as your organization is created.

Congratulations, you're now an organization owner!

To sign in to your organization at any time, go to https://dev.azure.com/{yourorganization} .
6. Enter a name for your project and select the visibility. The name you enter cannot contain spaces or special
characters (such as / : \ ~ & % ; @ ' " ? < > | # $ * } { , + = [ ]), cannot begin with an underscore, cannot begin
or end with a period, and must be 64 characters or less. Visibility can be either public or private. With public
visibility, anyone on the internet can view your project. With private visibility, only people who you give
access to can view your project. Select Create project.

Welcome to your project

When your project has been created, the welcome page appears.

NOTE
Your first project was created by using a Git repository and the Agile process. If you want a project that uses the Team
Foundation Version Control (TFVC) repository or the Scrum or CMMI process, see Choose a process for a comparison of
processes. Then, you can choose a process by adding another project.

Select one of the following tasks to get started:

Boards to begin adding work items.
Repos to open the Repos > Files page. There, you can clone or import a repository or initialize a README file
for your project summary page.
Pipelines to start defining a pipeline.
Test Plans to start defining test plans and test suites.
Manage your services to disable the visibility of one or more services.
To get started managing your project, see Get started as an administrator.
For more information about organizations and projects, see these articles:
Define organizations and projects
About projects and scaling your organization
Manage projects

Invite team members

Give a team member access to your organization by adding their email address to your organization.
1. Sign in to your organization ( https://dev.azure.com/{yourorganization} ).
2. Select Organization settings.

3. Select Users > Add new users.

4. Complete the form by entering or selecting the following information:
Users: Enter the email addresses (Microsoft account) for the users. You can add several email addresses
by separating them with a semicolon (;). An email address appears in red when it's accepted.
Access level: Leave the access level as Basic for users who will contribute to the code base. To learn
more, see About access levels.
Add to project: Select the project you named in the preceding procedure.
DevOps Groups: Leave as Project Contributors, the default security group for users who will
contribute to your project. To learn more, see Default permissions and access assignments.

NOTE
You must add email addresses for personal Microsoft accounts unless you plan to use Azure Active Directory
(Azure AD) to authenticate users and control organization access. If a user doesn't have a Microsoft account,
ask the user to sign up for a Microsoft account.

5. When you're done, select Add to complete your invitation.

For more information on managing users and organization access, see Add organization users for Azure DevOps
Services.

Try this next

Plan and track work
 Plan and track work
9/22/2018 • 2 minutes to read • Edit Online

Azure Boards | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
You add work items to plan and manage your project. You use different types of work items to track different types
of work—such as user stories or product backlog items, tasks, bugs, or issues. You can describe the work to be
done, assign work, track status, and coordinate efforts within your team.
Here we show how to add work items from the web portal and view work items you've created.

Prerequisites
You can start adding work items once you connect to a team project. If you don't have a team project yet, create
one in Azure DevOps.

Open the Work Items page

You can start viewing and adding work items once you connect to a project.

NOTE
The New navigation feature, which provides a vertical navigation experience, is in preview for Azure DevOps. Go here to
enable it. When you enable New navigation, you automatically enable several new Agile tool features described in the New
Work Hubs blog post. > For on-premises TFS users, choose Previous navigation for guidance.

New navigation
Previous navigation
(1) Check that you have selected the right project, then (2) choose Boards>Work Items.

NOTE
Depending on the process chosen when the project was created—Agile, Scrum, or CMMI—the types of work items you can
create will differ. For example, backlog items may be called user stories (Agile), product backlog items (Scrum), or
requirements (CMMI). All three are similar: they describe the customer value to deliver and the work to be performed.
For an overview of all three processes, see Choose a process.

Add a work item

1. Adding a work item is just one click away. Simply choose the work item type from the New Work Item
drop down menu.
For example, here we choose User Story.
2. Enter a title and then save the work item. Before you can change the State from its initial default, you must
save it.

You can add tags to any work item to filter backlogs, queries, and work item lists.
That's it!
Create as many work items as you need of the type you need to track the work you want to manage.

View the work items you've just created

Using the drop-down menu, you can focus on relevant items inside a project using one of the seven pivots as
described next. Additionally, you can filter and sort each pivot view.
 Assigned to me: lists all work items assigned to you in
the project in the order they were last updated. To
open or update a work item, simply click its title.
Following: lists work items that you've elected to
follow.
Mentioned: lists work items in which you've been
mentioned in the last 30 days.
My activity: lists work items that you have recently
viewed or updated.
Recently updated: lists work items recently updated
in the project.
Recently completed: lists work items completed or
closed in the project.
Recently created: lists work items created within the
last 30 days in the project.

For example, choose My activity to list all work items you've recently viewed, created, or modified.

To view any work item listed, choose the title.

For more information on using Work Items, see View and add work items.

Try this next

Create your backlog Kanban quickstart
Or, learn more about planning and tracking work.
 Create your backlog
9/26/2018 • 10 minutes to read • Edit Online

Azure Boards | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
Your product backlog corresponds to your project plan, the roadmap for what your team plans to deliver. Once
defined, you have a prioritized list of features and requirements to build. Your backlog also provides a repository
of all the information you need to track and share with your team.
Your backlog consists of a list of work items. You use work items to share information, assign work to team
members, track dependencies, organize work, and more. Because the most important work appears at the top of
the list, your team always knows what to work on next.

NOTE
Your product backlog is one of three classes of backlogs available to you. For an overview of the features supported on each
backlog and the two types of boards, see Backlogs, boards, and plans.

Prerequisites
You must connect to a project. If you don't have a project yet, create one.
If you haven't been added to a project or team, get added now.
You must be a member of the Contributors group and granted Basic access or be granted Stakeholder access
to add or modify work items. Or, you must have your View work items in this node, and your Edit work
items in this node permissions set to Allow.

NOTE
Users with Stakeholder access for a public project have full access to backlog and board features the same as those granted
to users with Basic access. To learn more, see [About access levels

You must connect to a project. If you don't have a project yet, create one.
If you haven't been added to a project or team, get added now.
You must be a member of the Contributors group or be granted Stakeholder access to add or modify work
items. Or, you must have your View work items in this node, and your Edit work items in this node
permissions set to Allow.
To learn more, see Set permissions and access for work tracking.

Open your backlog from the web portal

From your web browser, open your product backlog.
 NOTE
Choose Previous navigation when you see a top-level blue bar. Choose New navigation if you see a vertical sidebar or if
you enabled the New Navigation preview feature. The vertical sidebar, along with other navigational features, is enabled
when the New Navigation preview feature has been enabled for the signed-in user or the organization. To learn how to
use the web portal effectively, see Web portal navigation.
For on-premises TFS, choose Previous Navigation for guidance.

New navigation
Previous 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 sprints
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. (Optional) To choose which columns should display and in what order, choose the actions icon and
select Column options. To learn more, see Change column options.

New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.

Determine if bugs should appear on your backlog

You have a choice as to how you want to manage bugs. Some teams like to track bugs along with requirements on
the backlog. Other teams like to track bugs as tasks performed in support of a requirement, and have them appear
on their taskboard.
If you're using the Scrum process, your default setup is to track bugs along with PBIs. However, if you're working
in a project based on the Agile or CMMI processes, bugs don't automatically appear on your backlog.
Talk with your team to determine how they want to manage bugs and then change your team settings accordingly.

NOTE
Because this setting affects all team members' view of the team backlogs and boards, you must be a team administrator to
change the setting. Changing the setting is disabled if you're not a team administrator. Go here to get added as a team
administrator.

New navigation
Previous navigation

1. From your team's backlog page, choose the gear icon to open the common configuration team settings.

2. Choose the Working with bugs tab and select from the three options available.
 Choose the first option when your team wants to manage bugs similar to requirements. Bugs can be
estimated and tracked against team velocity and cumulative flow. Bugs will be associated with the
Requirements category.
Choose the second option when your team wants to manage bugs similar to tasks. Remaining work
can be tracked for bugs and tracked against the sprint capacity and burndown. Bugs will be
associated with the Task category.
Choose the last option if your team manages bugs separate from requirements or tasks. Bugs will be
associated with the Bugs category.
3. To see the changes, refresh your backlog.
New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.

TIP
If, after refreshing a backlog or board, you don't see bugs where you expect them, review How backlogs and boards display
hierarchical (nested) items. Only leaf nodes of nested items will appear on the Kanban or taskboards.

Convert ideas into backlog items or stories

Your backlog shows work that you are planning to do or have started working on. As soon as the State of a work
item is set to Done or Completed, the work item no longer shows up on your backlog. You can use the backlog
controls to filter or change your view.

TIP
If you've already defined a long list of items, you don't have to reenter them one at a time. Instead, use Microsoft Excel to
quickly import them to your backlog.

New navigation
Previous navigation

1. Before you start adding work items, choose the view options icon and turn the slider for Parents and
Forecasting to Off. Optionally turn In Progress items on or off.
2. To add a work item, choose the New Work Item, enter a title and then press the Enter key or choose
Add to top.

3. Repeat this step to capture all your ideas as work items.

New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.

NOTE
Depending on the process chosen to create your project—Agile, Scrum, or CMMI— the items in your backlog may be called
user stories, product backlog items (PBIs), or requirements. All three are similar: they describe the customer value to be
delivered and the work to be performed.
By default, user stories on Agile backlogs, PBIs and bugs appear on Scrum backlogs, and requirements on CMMI backlogs.

Move items into priority order

After you've got some items on your backlog, you can reorder them to create a prioritized list of work. Frequently
reviewing and prioritizing your backlog can help your team know what's most important to deliver next.
Reorder your backlog by simply dragging work items. Or, if you prefer the keyboard, hold the Alt key and use the
up and down arrows.
 TIP
You can't sort your backlog on a column. If you want to view a sorted listed, click Create query, save and open the query,
and then sort the query results. To learn more about queries, see Use the query editor to list and manage queries.

Add details and estimates

Getting your backlog built and prioritized provides the high level roadmap. However, before your team can
actually start work on any item, they'll need more details. You capture these details within the work item form.

TIP
To plan a sprint, at a minimum you should estimate the effort involved to implement each backlog item. You capture effort
in the following fields within the work item form: Effort (Scrum), Story Points (Agile), or Size (CMMI) fields.

Open each item (double-click, or press Enter to open the selected item) and add all the info you want to track.
Enter as much detail as the team needs to understand the scope, estimate the work required, develop tests, and
ensure that the end product meets acceptance criteria.
FIELD USAGE

Effort Provide a relative estimate of the amount of work required to complete a PBI. For user stories and
Story Points requirements, you capture estimates in the Story Points and Size fields.
Size
Most Agile methods recommend setting estimates for backlog items based on relative size of
work. Such methods include powers of 2 (1, 2, 4, 8) and the Fibonacci sequence (1, 2, 3, 5, 8, etc.).
Use any numeric unit of measurement your team prefers.
The estimates you set for Effort, Size, or Story Points are used in calculating velocity and
forecasting sprints.

Business Value Specify a priority that captures the relative value of a PBI compared to other PBIs. The higher the
number, the greater the business value.
Use this field when you want to capture a priority separate from the changeable backlog stack
ranking.

Description Provide enough detail to create shared understanding of scope and to support estimation efforts.
Focus on the user, what they want to accomplish, and why. Don't describe how to develop the
product. Do provide sufficient details so that your team can write tasks and test cases to implement
the item.
 Acceptance Criteria Define what "Done" means by describing the criteria that the team should use to verify whether
the PBI or the bug fix has been fully implemented.
Before work begins on a PBI or bug, describe the criteria for customer acceptance as clearly as
possible. Conversations between the team and customers to determine the acceptance criteria
help ensure a common understanding within the team to meet customers' expectations. Also, this
info provides the basis for acceptance testing.

Try this next

Now that you've got a working backlog in place, your team can begin work on the top priority items. From here,
it's time to make the decision on how you want to work as a team: Scrum or Kanban? You can use these methods
independently or together.
Scrum: Schedule sprints or Kanban
Teams that want the least overhead in terms of tracking and estimating may prefer Kanban. Teams that like to
work at a steady cadence and plot the details of their sprint plan may prefer Scrum and sprint planning.

Related articles
Refine your backlog
Product backlog controls
Filter product and portfolio backlogs
Backlog priority or stack rank order
Backlog keyboard shortcuts
 Start using your Kanban board
9/22/2018 • 5 minutes to read • Edit Online

Azure Boards | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
Your Kanban board turns your backlog into an interactive signboard, providing a visual flow of work. As work
progresses from idea to completion, you update the items on the board. Each column represents a work stage,
and each card represents a backlog item, user story, or bug at that stage of work.

User stories and bugs correspond to types of work items. You use work items to share information, assign work to
team members, update status, track dependencies, and more.

Prerequisites
You must connect to a project. If you don't have a project yet, create one.
If you haven't been added to a project or team, get added now.
You must be a member of the Contributors group and granted Basic access or be granted Stakeholder access
to add or modify work items. Or, you must have your View work items in this node, and your Edit work
items in this node permissions set to Allow.

NOTE
Users with Stakeholder access for a public project have full access to backlog and board features the same as those granted
to users with Basic access. To learn more, see [About access levels

You must connect to a project. If you don't have a project yet, create one.
If you haven't been added to a project or team, get added now.
You must be a member of the Contributors group or be granted Stakeholder access to add or modify work
items. Or, you must have your View work items in this node, and your Edit work items in this node
permissions set to Allow.
To learn more, see Set permissions and access for work tracking.

Add a Kanban board

Each Kanban board is associated with a team and a work item type. For the Agile process, the three boards are
Stories, Features, and Epics.
When you add a team, you add a number of team assets which a team admin can configure to support the way
the team works. To add a set of Kanban boards to support a new team, add a team.
To add a board to support an additional portfolio backlog, see Customize your backlogs or boards.
To add a board to support an additional portfolio backlog, see Add a portfolio backlog level.

Open your Kanban board from the web portal

Your Kanban board is one of two types of boards available to you. For an overview of the features supported on
each backlog and board, see Backlogs, boards, and plans. To switch to the product backlog, choose Stories
backlog. And, to switch to the taskboard, choose Sprints and then choose Taskboard.

NOTE
Choose Previous navigation when you see a top-level blue bar. Choose New navigation if you see a vertical sidebar or if
you enabled the New Navigation preview feature. The vertical sidebar, along with other navigational features, is enabled
when the New Navigation preview feature has been enabled for the signed-in user or the organization. To learn how to
use the web portal effectively, see Web portal navigation.
For on-premises TFS, choose Previous Navigation for guidance.

New navigation
Previous navigation
1. (1) Check that you have selected the right project, (2) choose Boards>Boards, and then (3) select the
correct team from the team selector menu.

To choose another team's board, open the selector and select a different team or choose the
Browse all team boards 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 board. 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.

New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.

Add work items

1. To add a work item, simply choose the plus sign, enter a title, and then press Enter on your keyboard.
New navigation
Previous navigation
To add a work item, simply choose the plus sign, enter a title, and then press Enter on your keyboard.

The system automatically saves the work item with the title you entered. You can add as many work items you
want using this method.
New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.
To add details to any work item, choose the title. Or, you can directly modify any field that displays. For example,
you can reassign a work item by choosing the Assigned To field. For a description of each field, see Create your
backlog, Add details and estimates.
To customize the set of fields displayed on the card, see Customize cards.

Update status via drag-and-drop

As work completes in one stage, update the status of an item by dragging and dropping it to a downstream stage.

Update fields from the card

You can quickly update a field or reassign ownership directly from the board. If the field you want to update isn't
showing, then customize the card to show it.
Invite others to work on your Kanban board
All members of a project will be able to view and contribute to your Kanban board. To invite users to start
contributing, copy the URL of your Kanban board and email it to those you want to invite to your project.

To add users to your project, see Add users to a project

Try this next

To get the full power of the Kanban board working for you, you'll want to configure it to map the flow of work and
set WIP limits for your team. To configure the Kanban board, you must be added as a team administrator or be a
member of the Project Administrators group. If you're the organization owner or creator of the project, then you'll
have these permissions.
Kanban basics
 Permissions and access for Azure Boards
9/22/2018 • 3 minutes to read • Edit Online

Azure Boards | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
As a member of an Azure Boards project, you can use the majority of work tracking functions and features. All
project members are added to the Contributors group. The most common built-in groups include Readers,
Contributors, and Project Administrators. These groups are assigned the default permissions for tracking work as
listed below.

Default permissions and access to work tracking tools

NOTE
For public projects, Stakeholder access gives users greater access to work tracking features and full access to Azure Pipelines.
To learn more, see About access levels, Stakeholder access.

TASK STAKEHOLD READERS CONTRIBUT TEAM ORGANIZATION

ERS ORS ADMINS OWNER/
PROJECT ADMINS

View work items, including bugs,

requirements, and tasks

Create and edit work items, follow a work

item

Change work item type

Move or delete work items 1

Search and query work items, save work item Can't save
queries queries

View backlogs, boards, and plans

Provide feedback

Request feedback

Agile tools (Kanban boards, backlogs, sprint limited view only

planning, portfolio management) 2 interaction
s

Configure Agile tools, set team defaults 2

Create new work item tags 3 Can assign

existing
tags
 View, add, and configure Delivery Plans 4 view only

Customize project information (area paths,

iteration paths, and work tracking processes)

Powerful semantic work tracking search

Notes:
1. Public project Stakeholders have full access.
2. Public project Stakeholders have full access to all features.
3. Public project Stakeholders can create new tags.
4. Public project Stakeholders can configure Delivery plans.

TASK STAKEHOLD READERS CONTRIBUT TEAM PROJECT ADMINS

ERS ORS ADMINS

View work items, including bugs,

requirements, and tasks

Create and edit work items, follow a work

item

Change work item type

Move or delete work items

Search and query work items, save work item Can't save
queries queries

View backlogs, boards, and plans

Provide feedback

Request feedback

Agile tools (Kanban boards, backlogs, sprint limited view only

planning, portfolio management) interaction
s

Configure Agile tools, set team defaults

Create new work item tags Can assign

existing
tags

View, add, and configure Delivery Plans view only

Customize project information (area paths,

iteration paths, and work tracking processes)

Powerful semantic work tracking search

Resources defined for the team project
You set project-level information permissions from Project Settings for a project. You set permissions for area
and iteration paths from Project Settings>Work>Project configuration.

TASK STAKEHOLD READERS CONTRIBUT TEAM ACCOUNT OWNER/

ERS ORS ADMINS PROJECT ADMINS

View project-level information

Area node: Edit work items under the node

Area nodes and Iteration nodes: Create,

delete, edit child nodes

Edit project-level information

The Edit project-level information permission includes the ability to perform these tasks for the team project:
Create and modify areas and iterations
Edit check-in policies
Edit shared work item queries
Edit team project level permission ACLs
Create and modify global lists
Edit event subscriptions (email or SOAP ) on team project level events.

Team administrator role and permissions

The team administrator role supports configuration of team settings. To be added as a team administrator, see Add
team administrators. Project administrators con configure settings at the team and project level. See Add
administrators, set permissions at the project-level or project collection-level.
The following table summarizes a subset of the default permissions assigned to the team project Readers,
Contributors and Project Administrators groups and the Team Administrator role. Team admin permissions extend
only to the team for which they're an administrator. Project administrator permissions extend across all teams
defined for the team project.

PERMISSION READERS CONTRIBUTORS TEAM PROJECT

ADMINISTRATORS ADMINISTRATORS

Add a team administrator

Add team members

View shared work item queries

Manage shared query and query folder

permissions
(Contribute, Delete, Manage Permissions)
 Add and edit dashboards

Stakeholder access
Stakeholder access supports business owners and analysts and other team members who don't contribute to code,
build, and test activities. They contribute by adding ideas to the backlog, adding context and information to work
items, and reviewing status and progress. All members of an organization who don't use Visual Studio but want to
contribute to work item tracking and monitor progress can be assigned as a stakeholder. To learn more about
stakeholder access, see Work as a stakeholder.
For a comparison chart of stakeholder versus basic access, see the Feature Matrix.
For information about each access levels, see About access levels. To assign access levels, see Add users and assign
licenses.

Related articles
Grant or restrict access to select features and functions
Set permissions and access for work tracking
Get started as a Stakeholder
Add another team
Add a team administrator
Manage teams and configure team tools
 Key concepts
9/22/2018 • 7 minutes to read • Edit Online

Azure Boards | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
Here you'll find definitions of key concepts and artifacts used in Azure Boards. See also:
Work item field index
Project management and navigation glossary

Agile methods
A family of engineering best processes with a goal of enabling rapid delivery of high-quality software and a
business approach that aligns development with customer needs and company goals. In this paradigm, frequent
inspection and adaptation is necessary, with teamwork, self-organization, and accountability all critical to project
success.

Agile tools
A suite of web-based tools used to track work and support Agile methodologies. Agile tools support the core Agile
methods—Scrum and Kanban—used by software development teams today. Learn more: What is Azure Boards?.

Area paths
Area paths allow you to group work items by team, product, or feature area. Whereas, iteration paths allow you to
group work into sprints, milestones, or other event-specific or time-related period. The area path allows you to
define a hierarchy of paths. Learn more: About area and iteration paths.

Bug
A type of work item that records a potential source of dissatisfaction with the product. The common name of a
work item type for tracking code defects.

Dashboards
User-configurable interactive signboards that provide real-time information. Dashboards are associated with a
team and display configurable widgets to display information. Learn more: Add and manage dashboards.

Favorites
A method for tagging an object to support quick navigation by yourself or other team members. You can tag work
item queries and build definitions as personal and team favorites. Other objects you can favorite for yourself only
include code branches, delivery plans, test plans, and teams or projects. Learn more: Set personal or team favorites.

Fields
Supports tracking a piece of information about the work to perform. Values you assign to a field are stored in the
work tracking data store which you can query and generate charts to view status and trends. Your project contains
100 or more data fields. You update data by modifying the data field within a work item. Each work item is
associated with a work item type (WIT), and the data you can track corresponds to the fields assigned to the WIT.
For a definition of each predefined field, see Work item field index.
Follow
A tool for tagging specific work items or pull requests for which you want to receive email updates when changes
are made to them. Learn more: Follow a work item or pull request.

Inheritance process model

The Inheritance process model provides support for customizing work tracking objects and Agile tools for a project
through the user interface. This process model is only available for accounts hosted on the Azure DevOps Services
cloud platform. Projects inherit the customizations made to a process. To learn more, see Inheritance process
model.

Iteration paths (aka sprints)

A time period, usually two to three weeks, used to group work items to be completed during that time period.
Sprints are used in Scrum methods to support sprint planning, sprint burndown, and other Scrum processes.
Iteration paths allow you to group work into sprints, milestones, or other event-specific or time-related period.
Learn more: About area and iteration paths.

Kanban board
An interactive, electronic sign board that supports visualization of the flow of work from concept to completion and
lean methods. Learn more: Kanban basics.

Link type
Specifies an object used to form link relationships between different WITs. Learn more: Link work items to support
traceability and manage dependencies and LinkTypes elements reference.

Pick lists
Specifies an enumerated set of values that appear within a drop-down menu in a work item form and the Value
column within the query editor. The method you use to customize a pick list varies depending on the field and the
process model. Learn more: Customize work.

Plans (aka delivery plans)

A configurable view that displays work from multiple teams and projects laid out within a calendar based on each
team's iterations. Each row in the view represents the work from a team's product or portfolio backlog, with each
card corresponding to a work item—user story, feature, or epic. Learn more: Review team delivery plans.

Portfolio backlog
An interactive list of work items, similar to the product backlog, that supports organizing or grouping work under
features, epics, or scenarios. Portfolio backlogs work similarly to product backlogs in that you can prioritize work
and view the tree hierarchy of work. Learn more: Define features and epics.

Process
Defines the building blocks of the work tracking system. To customize a process, you first create an inherited
process from one of the default system processes—Agile, Scrum, or CMMI. Changes you make to a process are
seen by all projects that use it. Learn more: About process customization and inherited processes.
Product backlog
An interactive list of work items that corresponds to a team's project plan or roadmap for what the team plans to
deliver. The product backlog supports prioritizing work, forecasting work by sprints, and quickly linking work to
portfolio backlog items. You can define your backlog items and then manage their status using the Kanban board.
Each product backlog can be customized by a team. Learn more: Create your backlog.

Product backlog item

A type of work item that defines the applications, requirements, and elements that teams plan to create. Product
owners typically define and stack rank product backlog items which are defined with the Scrum process. Learn
more: Scrum process work item types and workflow.

Projects
A project (previously referred to as a team project) provides a repository for source code and a place for a group of
people to plan, track progress, and collaborate on building software solutions. A project is defined for an Azure
DevOps Services organization or within a TFS project collection. It provides support for focusing on those objects
defined within the project. Learn more: About projects and scaling your organization.

Queries
A query supports finding and listing work items. Queries are used to support managed searches which you can
use to triage work versus adhoc searches used to find a specific work item. Learn more: About managed queries.

Sprints (aka Iterations)

A time period, usually two to three weeks, used to group work items to be completed during that time period.
Sprints are used in Scrum methods to support sprint planning, sprint burndown, and other Scrum processes.
Sprints are defined via Iteration Paths. Learn more: About area and iteration paths (aka sprints).

Sprint backlog
An interactive list of work items that have been assigned to the same sprint or iteration path for a team. The sprint
backlog supports teams that use Scrum methodologies. Learn more: Sprint planning.

Taskboard
An interactive board of work items that support reviewing and updating tasks defined for the sprint backlog. The
task board supports teams that use Scrum methodologies. Learn more: Update and monitor your Taskboard.

Teams
A team corresponds to a selected set of project members. With teams, organizations can sub-categorize work to
better focus on all the work they're tracking within a project. Each team gets access to a suite of Agile tools. These
tools provide teams the ability to work autonomously and collaborate with other teams across the enterprise. Each
team can configure and customize each tool to meet their work requirements. Learn more: About teams and Agile
tools.

User story
A type of work item that defines the applications, requirements, and elements that teams plan to create. Product
owners typically define and stack rank user stories. User story is defined with the Agile process. Learn more: Agile
process work item types and workflow.

Widgets
Widgets display information and charts on dashboards. Many of them are configurable and display information
available from one or more data stores or charts created by the system. Learn more: Widget catalog.

Work item types (WITs)

A WIT specifies the fields, workflow, and form used to track an item of work. Each WIT is associated with 30+
system fields and several more type-specific fields. You use work items to plan and track the work required to
develop your project. For an overview of predefined WITs provided with the default processes, see Choose a
process.

Workflow
Workflow is an integral aspect of a work item and is defined by it's corresponding work item type. The workflow
determines the logical progression and regression of work items, tracking the status of work as it progresses from
a New or Active state to Closed or Completed state. It also specifies the values that appear in the drop-down
menus for the State and Reason fields. Learn more: Workflow states and state categories.
 Web portal navigation
9/20/2018 • 6 minutes to read • Edit Online

Azure DevOps Services | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
The web portal for Azure DevOps Services and Team Foundation Server (TFS ) is organized around a set of
services, as well as administrative pages and several task-specific features such as the search box. The service
labels differ depending on the navigation selected:
New navigation: Overview, Boards, Repos, Pipelines, Test Plans, and Artifacts
Previous navigation: Dashboards, Code, Work, Build and Release, Test, Wiki, and Analytics views
Each service provides you with one or more pages which support a number of features and functional tasks.
Within a page, you may then have a choice of options to select a specific artifact or add an artifact.
The web portal for Team Foundation Server (TFS ) is organized around a set of applications—such as, Dashboards,
Code, Work, Build and Release—as well as administrative pages and several task-specific features such as the
search box. Each service provides you with one or more pages which support a number of features and functional
tasks. Within a page, you may then have a choice of options to select a specific artifact or add an artifact.

NOTE
Choose Previous navigation when you see a top-level blue bar. Choose New navigation if you see a vertical sidebar or if
you enabled the New Navigation preview feature. The vertical sidebar, along with other navigational features, is enabled
when the New Navigation preview feature has been enabled for the signed-in user or the organization. To learn how to use
the web portal effectively, see Web portal navigation.
For on-premises TFS, choose Previous Navigation for guidance.

Here's what you need to know to get up and running using the web portal.
New navigation
Previous navigation
Open a service, page, or settings: use to switch to a different service or functional area
Add an artifact or team: use to quickly add a work item, Git repo, build or release pipelines, or a new team
Open another project or repo: use to switch to a different project or access work items and pull requests
defined in different projects, or items you've favorited
Open team artifacts, use breadcrumbs & selectors: use to navigate within a service, to open other artifacts
or return to a root function
Work with favorites: favorite artifacts to support quick navigation
Search box: use to find code, work items, or wiki content
Your profile menu: use to set personal preferences, notifications, and enable preview features
Settings: use to add teams, manage security, and configure other project and organization-level resources.
New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.
 NOTE
Only those services that are enabled will appear in the user interface. For example, if Boards is disabled, then Boards or
Work and all pages associated with that service won't appear. To enable or disable a service, see Turn an Azure DevOps
service on or off.

New navigation
Previous navigation
In New navigation, you select services—such as Boards, Repos, and Pipelines—from the sidebar and pages
within those services.

New navigation isn't supported on TFS at this time. Choose Previous navigation for guidance.
Now that you have an understanding of how the user interface is structured, it's time to get started using it. As you
can see, there are a lot of features and functionality.
If all you need is a code repository and bug tracking solution, then start with the Get started with Git and Manage
bugs.
To start planning and tracking work, see About Agile tools.

Connect to the web portal, user accounts and licensing

You connect to the web portal through a supported web browser—such as the latest versions of Edge, Chrome,
Safari, or Firefox. Only users who have been added to a project can connect. This is typically done by the
organization owner.
Five account users are free as are Visual Studio subscribers and stakeholders. After that, you need to pay for more
users. Find out more about licensing from Azure DevOps pricing.
Limited access is available to an unlimited number of stakeholders for free. For details, see Work as a Stakeholder.
You connect to the web portal through a supported web browser—such as the latest versions of Edge, Chrome,
Safari, or Firefox. Only users who have been added to a project can connect. This is typically done by a member of
the Project Administrators group.
Limited access is available to an unlimited number of stakeholders for free. For details, see Work as a Stakeholder.
Most regular contributors must have a TFS client access license (CAL ). All Visual Studio subscriptions include a
TFS CAL. Find out more about licensing from TFS pricing.

Refresh the web portal

If data doesn't appear as expected, the first thing to try is to refresh your web browser. Refreshing your client
updates the local cache with changes that were made in another client or the server. To refresh the page or object
you're currently viewing, refresh the page or choose the Refresh icon if available.
To avoid potential errors, you should refresh your client application under the following circumstances:
Process changes are made
Work item type definitions are added, removed, renamed or updated
Area or iteration paths are added, removed, renamed or updated
Users are added to or removed from security groups or permissions are updated
A team member adds a new shared query or changes the name of a shared query
A build definition is added or deleted
A team or project is added or deleted.

Differences between the web portal and Visual Studio

Although you can access source code, work items, and builds from both clients, some task-specific tools are only
supported in the web browser or an IDE, but not in both.

WEB PORTAL VISUAL STUDIO

Product backlog, Portfolio backlogs, Sprint Task specific interfaces that integrate with Git and
backlogs, Task boards, Capacity planning TFVC, such as:
Kanban board Git: Changes | Branches | Pull Requests |
Sync | Work Items | Builds
Dashboards, Widgets, and Charts
TFVC: My Work | Pending Changes | Source
Team rooms Control Explorer | Work Items | Builds
Request feedback Greater integration with work items and Office-
Web-based Test Management integration clients. You can open a work item or
query result in an office supported client.
Administration pages to administer accounts, team
projects, and teams

Resources
Manage projects
Project & Organizational Settings
 Work items
9/10/2018 • 2 minutes to read • Edit Online

Azure Boards | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
Track the features and requirements you're developing, code defects or bugs, and other particulars using work
items.

5-Minute Quickstarts
View and add work items
Add work items
Drive Git development

5-Minute Quickstarts
Add work items
Drive Git development

5-Minute Quickstarts
Add work items

Step-by-Step Tutorials
Follow work
Manage bugs
Manage issues
Move, change, or delete items
Link work items
Bulk modify (web)

Step-by-Step Tutorials
Manage bugs
Manage issues
Remove or delete items
Link work items
Bulk modify (web)

Concepts
Choose a process
Agile process guidance
CMMI process guidance
Scrum process guidance
Agile glossary
How-to Guides
Use @mentions to further discussion
Use #ID to link to work items
Add tags to work items
Use work item templates

How-to Guides
Add tags to work items
Use work item templates
::: moniker range="vsts || >= tfs-2017 <= tfs-2018"

Reference
Permissions and access for work tracking
Work item form controls
Keyboard shortcuts for work item forms & the Work Items page
Work item field index

Reference
Permissions and access for work tracking
Work item field index

Resources
Backlogs
Kanban
Scrum
Queries
Customization
 About process customization and inherited processes
9/22/2018 • 12 minutes to read • Edit Online

Azure Boards
To customize the work tracking system, you customize an inherited process through the administrative user
interface for the organization. All projects that use an inherited process get the customizations made to that
process. On the other hand, you configure your Agile tools—Backlogs, Sprints, Kanban boards, and Taskboard—
for each team.

IMPORTANT
To customize an on-premises TFS project, see On-premises XML process model. This article applies to Azure DevOps Services
only.

There are a number of customizations you can make. The primary ones are adding custom work item types (WITs)
or modifying an existing WIT to add custom fields, modify the layout, or change the workflow.
Below you'll find an index to those tasks you can perform to customize an inherited process. Some options of
inherited elements are locked and can't be customized.

System versus inherited processes

You'll see two types of processes:
System processes —Scrum, Agile, and CMMI—which are locked from being changed.
Inherited processes, which you can customize and that inherit definitions from the system process from
which they were created. System processes are owned and updated periodically by Microsoft. Any updates
made to a system process will automatically update your inherited process.
In addition, all processes are shared. That is, one or more projects can use a single process. Instead of customizing
a single project, you customize a process. Changes made to the process automatically update all projects that use
that process.
Once you've created an inherited process, you can customize it, create projects based on it, make a copy of it, and
change existing projects to use it.
For example, as shown in the following image, you see a list of projects defined for the fabrikam organization. The
second column shows the process used by each project. To change the customizations of the Fabrikam Fiber
project, you need to modify the MyAgile process (which inherits from the Agile system process). Any changes you
make to the MyAgile process will also update the Test Agile project. You can't customize the Scrum Project, on the
other hand, until you change it to a process which inherits from Scrum.
Process name restrictions
Process names must be unique and 128 Unicode characters or less. Also, names can't contain the following
characters: .,;'`:~\/\*|?"&%$!+=()[]{}<> .
To rename a process, open the … context menu for the process and choose Edit.

Inherited objects versus custom objects

Each inherited process you create inherits the WITs defined in the system process—Agile, Scrum, or CMMI. For
example, the Agile process provides bug, task, user story, feature, epic, issue and test-related WITs.

You can add fields and modify the workflow and work item form for all inherited WITs that display on the Work
Item Types page. If you don't want users to create a WIT, you can disable it. In addition, you can add custom
WITs.

Field customizations
Fields defined in the system process appear with an inherited icon, indicating that you can make limited
modifications to it in your inherited process.
Fields are defined for all projects and processes in the organization. That means that any custom field you defined
for a WIT in one process can be added to any other WIT defined for another process.

FIELD TYPE CUSTOMIZATION SUPPORT

Inherited fields Change the field label

Show/Hide field on form
 Custom fields Add a custom field
Add picklist (drop-down menu)
Add person-name/Identity
Add a rich-text (HTML) field
Add a checkbox (Boolean) field
Add a custom control
Add custom rules to a field
Change the field label
Set Required/Default options
Move the field within the layout
Remove field from form
Delete field

When adding custom fields, note the following limits:

A maximum of 64 fields can be defined for each WIT
A maximum of 512 fields can be defined per process
In addition, you can add an existing field to another WIT within the process. For example, you can add Due Date to
the user story or bug WITs.
What you can't customize
You can't change the field name or data type once you've defined it
With regards to picklists, you currently can't perform these operations:
Change the picklist of an inherited field, such as the Activity or Discipline field
Change the picklist order, picklists display in alphabetic order
Import or define a global list as supported by the Hosted XML and On-premises XML process models. To learn
more, see Define global lists.

NOTE
With the inherited process, you can't modify the picklists of pre-defined fields—such as Activity, Automation Status,
Discipline, Priority, plus others.

Configurable picklists
The following picklists are configured for each project and not customizable through an inherited process.
Area paths
Iteration paths
Picklists associated with person-name fields, such as Assigned To and Changed By, are managed based on the
users you add to a project or team.
Can a field be renamed or its field type changed?
Renaming a field or changing the field type aren't supported actions.
However, you can change the label that appears for a field on the work item form from the Layout tab. When
selecting the field in a query you need to select the field name and not the field label.
What is a field? How are field names used?
Each work item type is associated with 31 system fields and several more type-specific fields. You use work items
to plan and track your project.
Each field supports tracking a piece of information about the work to perform. Values you assign to a field are
stored in the work tracking data store which you can create queries to determine status and trends.
For descriptions and usage of each field defined for the core system processes—Scrum, Agile, and CMMI system
processes—see Work item field index.
Field names
A work item field name uniquely identifies each work item field. Make sure your field names fall within these
guidelines:
Field names must be unique within the organization or project collection
Field names must be 128 or fewer Unicode characters
Field names can't contain any leading or trailing spaces, nor two or more consecutive spaces
Field names must contain at least one alphabetic character
Field names can't contain the following characters: .,;'`:~\/\*|?"&%$!+=()[]{}<> .
Because all fields are defined for the organization, you can't add a custom field with the same field name that
already exists in the organization or was added to a WIT in another inherited process.

NOTE
When you change a project to use an inherited process, you may find one or more Agile tools or work items appear in an
invalid state. For example:
If you make a field required, work items with that field undefined will show an error message. You'll need to resolve the
errors to make additional changes and save the work item.
If you add or remove/hide workflow states of a WIT that appears on the Kanban board, you'll need to update the Kanban
board column configurations for all teams defined in the project.

Custom rules and system rules

Each WIT—bug, task, user story, etc.—has several system rules already defined. Some are simple, like making the
Title field required or setting a default for the Value Area field. In addition, a number of system rules define actions
to take when a workflow state changes.
For example, several rules exist to copy the current user identity under the following conditions:
When a work item is modified, copy the user identity to the Changed By field
When the workflow state changes to Closed or Done, copy the user identity to the Closed By field.

IMPORTANT
Predefined system rules will take precedent over any custom rule that you define which would overwrite it.

Custom rules provide support for a number of business use cases, allowing you to go beyond setting a default
value for a field or make it required. Rules allow you to clear the value of a field, copy a value into a field, and apply
values based on dependencies between different fields' values.
With a custom rule, you can define a number of actions based on specific conditions. For example, you can apply a
rule to support these types of scenarios:
When a value is defined for Priority, then make Risk a required field
When a change is made to the value of Release, then clear the value of "Milestone"
When a change was made to the value of Remaining Work, then make Completed Work a required field
When the value of Approved is True, then make Approved By a required field
When a user story is created, make the following fields required: Priority, Risk, and Effort
 TIP
You can't define a formula using a rule. However, you may find a solution that fits your needs via the TFS Aggregrator (Web
Service) Marketplace extension. See also Rollup of work and other fields.

For details on defining custom rules, see Add a rule to a work item type.

WIT customizations
Here are your customization options for inherited and custom WITs.

WIT TYPE CUSTOMIZATION SUPPORT

Inherited WITs Add custom rules to a WIT

Add/remove custom fields
Add/remove custom groups
Add/remove custom pages
Add/remove a custom control
Enable/disable

Custom WITs Add custom WIT

Change color or description
Add/remove custom fields
Add/remove custom groups
Add/remove custom pages
Add/remove a custom control
Add custom rules to a wit
Add, edit, or remove a workflow state
Enable/disable
Delete

What you can't customize

- You can't add or remove an inherited WIT to or from a backlog
- You can't change the position of an inherited field within the form layout (however, you can hide the field in one area
of the form and add it elsewhere in the form) - You can't remove the inherited portfolio level from the product (but
you can rename them) - You can't change the name of a custom WIT. ### Work item form customizations You can
make the following customizations to a WIT form.

GROUP OR PAGE TYPE CUSTOMIZATION SUPPORT

Inherited groups Relabel

Add/remove custom fields
Show/hide fields

Custom groups Add, modify, re-sequence, delete

Add/remove custom fields
Add/Hide a group extension

Inherited pages Relabel

Add/remove custom fields
Add/remove a custom group
 Custom pages Add, modify, re-sequence, delete
Add/delete custom fields
Add/hide a page extension

Layout and resizing

The web form layout is organized into three columns as shown in the image below.

If you only add groups and fields to the first two columns, then the layout reflects a two column layout. Likewise, if
you only add groups and fields to the first column, then the layout reflects a one column layout.
The web form resizes depending on the width available and the number of columns in the layout. At maximum
width, in most web browsers, each column within a page will display within its own column. As the display width
decreases, each column resizes proportionally as follows:
For three columns: 50%, 25%, and 25%
For two columns: 66% and 33%
For one column: 100%.
When the display width won't accommodate all columns, columns appear stacked within the column to the left.

Workflow customizations
You can customize the workflow of any WIT by hiding inherited states or adding custom states. By default, each
WIT is defined with three or four workflow states. Inherited states differ based on the system process —Agile,
Scrum, or CMMI—you chose from which to create your custom process.

NOTE
Before adding a workflow state, review Workflow states and state categories to learn how workflow states are used to
support several Agile tools.

STATE TYPES CUSTOMIZATION SUPPORT

Inherited states View workflow states

Hide a state

Custom states Add a state

Edit a state (change color or category)
Remove a state

The workflow states must conform to the following rules:

At least one state must be defined for either the Proposed or In Progress state categories
At a minimum, there must be at least two workflow states defined
What you can't customize
 You can't modify an inherited state (you can't change its name, color, or category), but you can hide it
You can't modify the state assigned to the Completed state category for any WIT, custom or inherited
You can't change the name of a custom state
You can't change the order of states (states are listed in the order you add them within the States page, and
they're listed alphabetically within the drop down list of a work item form)
You can't specify a Reason for a state, instead, default reasons are defined such as Moved to state Triaged,
Moved out of state Triaged
You can't restrict transitions, all transitions are defined from any state to another state.

Backlog and board customizations

Backlogs and boards are essential Agile tools for creating and managing work for a team. The standard backlogs—
product, iteration, and portfolio—inherited from the system process are fully customizable. In addition, you can
add two custom portfolio backlogs.

BACKLOG TYPES CUSTOMIZATION SUPPORT

Standard backlogs Add a custom WIT

Change the default WIT
Rename the requirement backlog
Rename a portfolio backlog

Custom portfolio backlogs Add a portfolio backlog which displays custom WITs
Edit or rename a portfolio backlog
Delete the top-level custom portfolio backlog

When you change the default WIT for a backlog level, it causes that WIT to appear by default in the quick add
panel. For example, Customer Ticket appears by default in the following quick add panel for the product backlog.

What you can't customize

You can't add or remove an inherited WIT to or from a backlog, for example, you can't add the Issue WIT to the
product backlog
You can't remove an inherited portfolio level from the product (but you can rename them)
You can't insert a backlog level within the existing set of defined backlogs
You can't reorder the backlog levels
You can't create a custom task level, although you can add custom WITs to the iteration backlog
You can't add the Bug WIT to any backlog level. Instead, the system allows each team to decide how they want
to manage bugs. To learn more, see Show bugs on backlogs and boards.
Fields added to WITs associated with a backlog level
When you add a WIT to a backlog level, the following fields are added to the WIT definition as hidden fields (that
is, they don't appear on the work item form) to support select Agile tool features.
 BACKLOG LEVEL FIELDS ADDED

Portfolio backlog - Stack rank (Agile, CMMI)

- Backlog Priority (Scrum)

Requirement backlog - Stack Rank, Story Points (Agile)

- Stack Rank, Size (CMMI)
- Backlog Priority, Effort (Scrum)

Iteration backlog - Activity, Remaining Work, Stack Rank (Agile)

- Discipline, Remaining Work, Stack Rank (CMMI)
- Activity, Remaining Work, Backlog Priority (Scrum)

The Stack Rank and Backlog Priority fields capture the relative priority of work items as they are reordered on a
backlog or board. For details on it's usage, see Behind the scenes: the Backlog Priority or Stack Rank field.
The Story Points, Size, and Effort fields capture the relative work required to complete a WIT assigned to the
Requirement backlog. This value is used to compute velocity.
And, lastly, Remaining Work is used Sprint burndown and capacity charts.

Object limits
For a list of limits placed on the number of fields, WITs, backlog levels, and other objects you can customize, see
Work tracking object limits.
 Security & identity
9/22/2018 • 2 minutes to read • Edit Online

Azure DevOps Services | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
For anyone to access a project, you must add them to a security group. For a quick look at what permissions are
assigned to the default security groups, see Default permissions and access assignments.

5-Minute Quickstarts
View permissions
Look up the organization owner or a project administrator
Add users to a project or team
Set Git or TFVC repository permissions
Add administrators or set permissions at the project or collection level

Tutorials
Set up Active Directory or Azure Active Directory
Add AD/Azure AD security groups to built-in security groups
Change individual permissions, grant select access to specific functions
Grant or restrict permissions to select tasks
Remove user accounts

Concepts
About permissions and groups
About security roles
About access levels
Azure Active Directory groups (Azure DevOps)
Active Directory groups (TFS )
Security glossary

How-to Guides
Set Git branch permissions
Set build and release permissions
Set permissions and access for work tracking
Change access levels (TFS )

Reference
Default permission and access assignments
Permissions lookup guide
Permissions and groups reference

Resources
Account Management (Azure DevOps)
Server Administration (TFS )
Billing
Authentication guidance for REST APIs
Azure DevOps Data Protection Overview
Technical Articles