Team Services | TFS 2017 | TFS 2015 | TFS 2013
As you plan and track your project, you'll find you may want to configure a feature or customize your experience to meet your team's tracking needs. You configure teams and team Agile tools through the web portal administration context. The method you use to customize team projects, which impacts all teams, depends on the process model you use.
Customizations you make occur at one of three levels:
- Team level: Add teams and configure Scrum and Kanban tools that are team specific, such as what appears on each team's backlogs and boards, adding work item templates, and more
- Team project level: Add or modify work item types, data fields, backlog levels, and other objects shared across teams
- Object level: Grant or restrict access to work tracking tools, which includes setting permissions for objects and the team project and assigning users or groups to specific access levels.
If you're new to tracking work in Team Services or TFS, see Get started with Agile tools to plan and track work.
Add teams and configure their Scrum and Kanban tools
Each team can configure the backlogs and boards they use to support their Scrum or Kanban methodology. You plan and track your project using the set of Agile tools you access from the web portal.
The following tools are team specific, that is, when you add another team, you create another variant of the tool that is configurable and customizable by the team through the web portal.
Other tools- Velocity & forecasting
- Team dashboards
- Team notifications (Team Services, TFS 2017.1)
- Team alerts (TFS 2013-TFS 2017)
- Team rooms
Teams are associated with one or more area paths and a backlog iteration path which determine what items will appear on their backlogs and boards. For details on adding and configuring teams, see the following topics.
Kanban boards- Add columns
- WIP limits
- Split columns
- Expedite work
- Definition of done
- Customize cards
- Card reordering
- Cumulative flow chart
Scrum tools- Add/remove sprint backlogs
- Set sprint dates
- Customize cards on task board
- Capacity planning
- Velocity and forecasting
Each team project provides a number of shared resources that support all teams added to the project. You configure these features through the user interface or the admin context of the web portal.
Area path pick lists
Change the pick list of area paths to support grouping work items by team, product, or feature area.
Sprint/iteration pick lists
Change the pick list of iteration paths to support grouping work into sprints, milestones, or other event-specific or time-related period. Activate sprints for each team.
Open shared queries or create your own query using the query editor to list work items or show hierarchical or dependent items.
Add tags to work items to filter backlogs and queries
Team projects and process customizations
Your team project determines the objects available to tracking work and the configuration of Agile tools. Specifically, the team project determines the work item types (WITs)—user stories, tasks, bugs— and the data fields used to capture information. Customized objects are shared across teams added to the team project.
The method you use to customize work tracking depends on the process model you subscribe to:
- Inheritance: Supports WSIWIG customization, available for Team Services only
- Hosted XML: Supports customization through import/export of process templates, available for Team Services only
- On-premises XML: Supports customization through import/export of XML definition files for work tracking objects
The following table summarizes the differences between the three supported process models. For definitions of the main work tracking objects, see Definitions.
|Feature||Inheritance||Hosted XML||On-premises XML|
|Create inherited custom processes|
|Create custom process templates (see note 1)|
|Inherit changes in system processes (Agile, Scrum, CMMI)|
|Updated process changes automatically apply to team projects|
|Basic customizations supported (fields, workflow, work item types, backlog levels)|
|Advanced customizations supported (custom link types, global lists, global workflow, team fields)||(see note 2)|
|Use the witadmin command-line tools to edit team projects|
|Use the witadmin command-line tools to list information about team projects|
|REST API (read)|
|REST API (write)|
- A process determines the building blocks used to track work. A process template specifies an interdependent-related set of XML definition files that provide the building blocks and initial configuration for tracking work and other functional areas.
- Hosted XML customization supports adding and updating global lists with a process update (subject to limits on maximum size of each list). To learn more, see Differences between Team Services and TFS process template customizations.
Inheritance process model
You can perform the following tasks with the Inheritance process model.
Work item types
Customization sequence for Inheritance process model
Use this sequence when you manage your Team Services customization through the Inherited process model. You belong to this phase when your Process user interface appears as shown under Manage processes.
Hosted XML process model
You can perform the following tasks with the Hosted XML process model.
Work item types
Backlogs and process configuration
Customization sequence for Hosted XML process model
Use the following sequences when you manage your Team Services through the Hosted XML process model. This sequence requires you to update your team project by updating the process template that it uses. We recommend that you maintain your process templates in a repository for version control.
On-premises XML process model
You can perform the following tasks when you work with the On-prem XML process model.
Work item types
Backlogs & Process configuration
Customization sequence for On-premises XML process model
When you manage an on-premises TFS, you perform most customizations using the following sequence. This sequence supports updating the XML definition for WIT, global lists, process configuration, and categories. This sequence supports individual updates through the import of their respective modified XML definition files. We recommend that you maintain your XML definition files in a repository for version control.
In addition, you can use the witadmin tool to list objects, rename WITs, permanently remove WITs, and more.
With witadmin, you can import and export definition files. Other tools you can use include the Process Editor (requires that you have installed a version of Visual Studio):
- For TFS 2017 and later versions, install the TFS Process Template editor from the Visual Studio Marketplace. You can use this version of the Process Editor to modify the old-style work item forms. You can't use it to edit forms associated with the new web forms.
- For TFS 2015 and earlier versions, install TFS Power Tools.
Or, you can use the TFS Team Project Manager, an open-source client available from github.
Grant or restrict access to work tracking tools
You can grant or restrict access to select features and functions through the web portal. When you add user accounts to your team, they're automatically added to the Contributor group. They then have access to most of the features they'll need to contribute to code, work tracking, builds, and test. However, the Contributor group doesn't allow users to create shared queries or to add area or iteration paths. You have to grant these permissions separately.
For a simplified view of the most common, default permissions and access assignments, see Permissions and access. If you're new to managing permissions, see Permissions and groups reference, Inheritance.
Otherwise, to grant or restrict access to select features or functions, review one of these topics:
Manage access- Add team members (Team Services)
- Add team members (TFS)
- Stakeholder access
- Advanced access level
Permissions- Area path permissions
- Iteration path permissions
- Process permissions
- Work item query and folder permissions
- Dashboard permissions
- Plan permissions (Team Services)
- Tagging permissions
- Test permissions
- Restrict access
Learn more about how to use work tracking to plan, manage, and monitor your projects:
- Configure team settings
- witadmin command-line tools
- Agile tools
- Agile project management, get started
- Scrum | Agile | CMMI processes and process templates
- Configure features after an upgrade (TFS only)
Do you want to customize your tools in a way that's not supported?
Here are a few options available to you:
- Check out Marketplace extensions to see if there's a tool available for your purposes
- Determine if a Service hook will satisfy your needs
- Create your own tool using REST APIs
- Add your feature request to our Team Services user voice page page.
Customize the test experience (TFS)
Several WITs support the test experience within the web portal Test hub and Test Manager client. You can customize these WITs as you would any other WIT. The following image illustrates the support link relationships.
See the following resources for additional usage and customization information:
- Test configurations and test variables
- Test resolution states (TFS)
- Failure types
- Define the initial test management configuration (process template)
- Query based on build and test integration fields
Change the pick list for a person-name field
To add values for fields associated with user accounts such as Assigned To add users to a TFS security group or by restricting access to a group or set of users. By default, the list for the Assigned To field contains the account names for all users and groups that have been added to TFS. These accounts are often synchronized with Active Directory. See Set up groups for use in TFS deployments. To limit the names of accounts in a list, see Limit the number of names that appear in the Assigned To field.
Less common customizations
You can only perform the following customizations when working with the Hosted XML or On-premises XML process models. The customizations made to process configuration apply to all teams added to the team project.
Backlog and board limits (Hosted XML, On-premises XML)
To limit the display load time to acceptable parameters, the task board is restricted to a maximum of 1000 work items. For details, see Process configuration XML element reference.
You can increase this value up to a maximum of 1500 by specifying a value for the
workItemCountLimit attribute of the TaskBacklog element. For details, see Process configuration XML element reference.
<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="800" > . . . </TaskBacklog>
Change field assignments (Hosted XML, On-premises XML)
You can change the work item fields that are used in calculating capacity, burndown charts, forecasting, and velocity. Any change you make to one of the default assignments should correspond to a change made to the WIT used to define and capture information for that value.
For example, if you change the
refname assigned to
type="Activity" then you should include the same field in the WIT definition assigned to the Task Category which captures the activity information. For details, see Process configuration XML element reference.
The fields you assign are used by the following tools:
|Task board, capacity tools, sprint burndown||Remaining work|
|Product and portfolio backlogs||Backlog priority|
|Velocity and forecast||Effort (maps to Story Points, Effort, or Size)|
|Task board, capacity tools||Remaining work|
|Capacity tools||Activity (Task Activity or Discipline)|
Use a team field (On-premises XML)
Do you want to organize your teams using a team field instead of the area path?
If your organization has several teams that work from a common backlog and across many product areas, you might want to customize the team project to support team fields. This configuration will still allow teams to work independently, but work can be assigned to teams instead of by product area path.
Maintenance and upgrade implications (TFS)
Before you customize, you should understand how your customizations may impact your team project when you upgrade your application-tier server.
Upgrades to an on-premises TFS can introduce new features that require updates to the objects used to track work. These objects include work item types, categories, and process configuration. Minimizing changes to the workflow for a WIT or the process configuration can help minimize the work you must do when you upgrade your TFS.
To minimize the amount of manual work you'll need to do after a TFS upgrade, understand which customizations support an easy update path and which do not.
Compatible for quick updating
With the following customizations, you can use the Configure Features Wizard to automatically apply any changes to your team project required for new features.
- Fields: Add custom fields, customize a pick list, add or modify area and iteration paths, add rules to a field
- WITs: Add custom WITs, change the form layout
- Categories: Add custom categories
- Agile tools: Customize the columns on the Kanban board, customize the quick add panel
- Office integration: Add or change how Project fields map to TFS fields
To learn more about the Configure Features Wizard, see Configure features after an upgrade.
Compatible, but may require manual updates
The Configure Features Wizard requires that specific work item types, workflow states, and fields exist in the team project. When you make the following customizations, you might need to modify your custom process for the wizard to run, or you might have to update your team project manually.
- Fields: Change attributes of an existing field, remove fields that are referenced in the process configuration
- WITs: Change the workflow
- Agile tools: Change the WITs defined for the Requirement Category, Task Category, or Feature Category.
- Agile tools: Change the metastate mapping defined in the process configuration.
- Agile tools: Change a field specified for a
TypeFieldin the process configuration.
In addition, changes you make to WITs or the workflow could require updates to other artifacts provided with your process, such as Excel or SQL Server Reporting Services reports.
Customizations to avoid
You should avoid making the following customizations because they can result in schema conflicts in the data warehouse or cause problems when updating team projects after a TFS upgrade.
- Change the friendly name of a field (a field specified within a WIT definition file)
- Change one or more reporting attributes, or the attribute to synchronize person names with Active Directory of a default field
- WITs: Rename or delete WITs
- Categories: Change the name of default categories, or change the WITs specified within default categories
To learn more about reporting attributes, see Add or modify work item fields to support reporting.
- Identify the best options for customizing WITs that support your tracking requirements. When you change objects that track work items, you should identify how these changes will affect existing and future team projects.
- Put processes and all XML definition files under version control. Do not deploy objects that you define but have not stored in a repository.
- Test your customized objects just as you would test your software.
- Minimize the number of custom fields that you introduce. Minimize the number of fields that you make reportable.
Definitions of key work tracking objects
Your work tracking experience is managed and customized primarily through the objects defined in the following table.
|Category||Defines groups that associate a type of work item with a category. Categories support the process configuration used by the web portal backlog and task board page. For example, you can add custom work item types to the Requirements category and manage them using the product backlog and Kanban boards. To learn more, see Use categories to group work item types.|
|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 query and generate charts to view status and trends. Your team 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.|
|Global list||Defines a list of menu items or pick list items that are shared across WITs and team projects within a team project collection. Global lists help to minimize the work that is required to update lists. You can define global lists within WITs that you upload with your process template. To learn more, see Manage global lists for work item types. (Only supported for Hosted XML and On-premises XML process models)|
|Global workflow||Specifies both work item fields and global lists that multiple team projects and types of work items can share. To learn more, see Manage global workflow (Only supported for On-premises XML process model).|
|Link type||Specifies an object used to form link relationships between different WITs. To learn more about link relationships and link types, see Link work items to support traceability and manage dependencies and LinkTypes elements reference.|
|Pick list||Specify 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.|
|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 team projects that use it. (Only supported for Inheritance process model)|
|Process configuration||Specifies the default configuration and functional capabilities that your teams can access using the Agile tools. These web portal tools include the product backlog, sprint backlogs, Kanban board, and task board. (Only supported for Hosted XML and On-premises XML process models)|
|Process template||Specifies an inter-related set of files that contain the XML definitions for tracking work and defining the initial configuration of other functional areas. The system provides three default process templates—Agile, Scrum, or CMMI. You can create a team project and then customize it, or customize a process template that you then use to create a team project. (Only supported for Hosted XML and On-premises XML process models)|
|Work item type (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.|
Feedback and support
We welcome your feedback.
Or, see our comprehensive feedback and support page.