Customize Team Projects and Processes
You can customize your team project to support specific processes and practices that your team uses. For example, you can add a required field to the quick add panel on the product backlog page to streamline definition of new product requirements. Other common customization activities include adding fields to support reporting requirements and changing workflow definitions to match your team's processes.
For an overview of the top 10 areas that you might want to customize for your team project, see Customize Work Item Tracking and Your Team Project.
Before you begin any customization activity, you should become familiar with the types of objects and methods that you can customize, and how each type can be used to support your project tracking requirements.
Also, you should understand the interdependencies that exist among these objects, team project artifacts, team activities, and scope of changes. Customizations you make to a team project apply to all teams working in that team project. Some customizations apply to all team projects within a team project collection.
You can customize objects for a process template, a team project, or project collection. You create a team project from a process template. A process template defines the types of work item objects available for tracking as well as the default rules, policies, security groups, and queries for use by team members. Objects that you customize within the process template provide the initial configuration of the object. By customizing a process template, you increase compliance with processes across all team projects that are created with the process template. You also minimize the time to get projects up and running by defining the team queries, reports, source code control check-in notes, security groups, and more.
The following table describes the objects that you can customize for a process template or for a team project. For information about customizing an object after a team project has been created, choose the link under the Object column. For information about customizing an object as part of the process template, choose the link under the Description column.
Supports creating the backlog, sprint planning, and team progress. To define the initial configuration, see Customize the Backlog and Board Pages.
Supports definition of personal and team email notifications when changes occur to the team project.
Define logical, physical, functional categories, or areas owned by a team. See Define the Initial Areas and Iterations.
You can add default build process templates which you use when creating build definitions. You can later customize build process templates.
Group one or more work item types to support process configuration, queries, and other operations. See Add Type Definitions for Work Item Categories to a Process Template.
Configure rules that enforce specific actions when users check in or check out code. See Define the Initial Configuration of Team Foundation Version Control
Provide insight into team progress. Depending on the process template that you use to create your team project, you may have several dashboards already defined. You can customize these dashboards further or create new dashboards. Dashboards require integration with SharePoint Products.
Supports sharing of team documents and files through a project portal. Requires SharePoint Products. See Define the Project Portal.
Initial reports configured with a process template support dashboards and cannot be customized. After team project creation, you can customize and create additional Excel reports.
Supports definition and maintenance of pick lists to be used by many team projects.
Supports definition and maintenance of work item fields and global lists to be used by many team projects.
Define sprints or product release milestones. See Define the Initial Areas and Iterations.
Supports customization of link relationships between work items. See Add Type Definitions for Work Item Links.
Customize how data is published and refreshed when working in Microsoft Project and TFS. If you add new data fields to a work item type, you can map the field so that it appears in your plan. See Map Microsoft Project Fields to Team Foundation Fields
Supports providing guidance to team members on using team project artifacts. You can customize the hyperlinks that point to process guidance files and the location of process guidance. . See Define the Project Portal.
Reports (SQL Server Reporting Services (SSRS)
To add reports to a team project that currently has no SSRS reports, see Add reports to a team project.
To create or customize SSRS reports, see Create, Customize, and Manage Reports for Visual Studio ALM.
To customize the default set of reports you access through Report Manager, see Add Reports.
Test configurations specify a combination of hardware and software that represents a user's environment to test. You can configure the initial test configurations and define additional configurations using Test Manager.
Test resolution states
Specifies the reasons why a test failed. The default configuration includes: Needs investigation, Test issue, Product issue, and Configuration issue. See Define the Initial Configuration of Test Manager.
Test settings control the diagnostic data adapters that actually collect the data. You can configure the initial test settings or specify test settings using Test Manager.
Supports specification of elements that reflect the user environment in which the software will be deployed, such as the client device type, server operating system, network speed, or database edition. Test configurations are a combination of several test variables. You can configure the initial test variables or specify test variables using Test Manager.
Supports configuration of security groups and permissions. You can configure initial groups, teams, members, and permissions or create new groups or change permissions
Supports monitoring progress and tracking data. See Tracking data to support queries and reports .
Supports finding work items and generating reports. See add queries to a process template.
Provides the foundation for all tracking and reporting of the software development project. You can customize the fields tracked, the workflow, and form. Types of work items include bugs, user stories, and tasks. See Add Type Definitions for Work Items.
The four scope areas for you to consider are:
Assess how extensive you want to make your customizations. The following table summarizes the customization options from which to choose and their scope implications.
Apply changes to a process template
Choose this option when you plan to create several team projects and you want to minimize the time to get projects up and running and enforce compliance of team processes.
Apply changes to a team project
Choose this option when only your team requires the changes.
Apply changes to several team project
Choose this option when you want to enforce consistency of process across several existing team projects. You will need to import changes to object definition files to several team projects.
Apply changes to all team projects within a project collection
Work item fields, global lists, and link types
When you customize objects that are defined for a team project collection, they impact all team projects defined in the collection. Consider the implications when implementing changes at this level.
Assess your data integration requirements. A select set of fields integrate with Team Foundation Build, Test Manager, and Team Foundation version control. These applications automate the assignment of data to these fields. See Add Fields to Support Integration with Test, Build, and Version Control.
Assess your localization and globalization requirements. You can localize the names of work item types, fields, and many elements defined for a work item type. See Localization and Globalization of WITD Child Elements.
Assess category groups required to support cross-group efforts. When you have similar work items with different names, you can use categories to group them and generate reports more easily. Categories support flexible queries, reporting, process configuration, and integration across team projects. See Define Categories to Group Work Item Types.
The content and appearance of Agile pages is based on the definitions of WIT objects and the assignments made by the team. WIT objects include work item types, categories, and process configuration. Work item types define the fields, workflow, and the layout of the form that your team uses to capture data. This data is written to the WIT data store.
Team Web Access Agile pages and charts reference the WIT data store in real time. In the following illustration, work item fields are displayed in a blue box to emphasize that their definitions apply across all team projects within a team project collection. The orange-colored boxes indicate WIT objects that are defined for a team project. The Agile pages and charts, shown in purple, are defined for a team.
You can customize the appearance of the Agile pages by customizing the process configuration for a team project. You can customize the work item types that appear on the Agile pages by modifying the categories file for the team project. You can modify other elements, such as metastate mappings and work item field mappings, that support chart generation within the process configuration for the team project.
The following table describes the elements you can customize through a WIT object and those that you define through team activities and Team Web Access.
Agile page or chart
What you can customize through WIT objects
What you define through team activities
The configuration of the product backlog page determines the work item types and sequence of backlog items on the Kanban board.
To use the Kanban board, install Visual Studio 2012 Update 2 on the application-tier servers for Team Foundation Server (TFS).
Teams can customize the number and title of columns, and the number of items per column. See Manage your backlog with the Kanban board.
Velocity and forecast
To use tagging, install Visual Studio 2012 Update 2 on the application-tier servers for Team Foundation Server (TFS).
To add tags, see Add tags to work items to categorize and filter work.
If you add a work item type to a category, you should add the corresponding work item field listed in the following table to the definition for the work item type. If you change the work item field that you use to track data, you must change the field mapping defined in the process configuration file.
Activity (Agile and Scrum) or Discipline (CMMI)
Supports generation of capacity by activity.
Supports generation of the burndown and capacity charts.
Story Points (Agile), Effort (Scrum), or Size (CMMI)
Supports generation of the team velocity chart and forecasting.
Stack Rank (Agile and CMMI) or Backlog Priority (Scrum)
Requirements Category, Task Category
Supports tracking the sort order of backlog and task items.
You can't assign the same work item type to both the Requirement Category and the Task Category. The task board depends on distinct work item types being assigned to these two categories.
If you add a state from the workflow of a backlog item, task, or bug, and you want that state to be reflected on the Agile pages or the My Work feature, you must update the metastate mappings for the process configuration. See Workflow states, metastates, and process configuration.
All data captured for work items is written to the WIT data store, but only select data is written to the Analysis Services data warehouse. The reportable attribute assigned to each work item field determines whether data is written to only the relational warehouse database or to both the relational warehouse and the OLAP cube. Reportable fields have their reportable attribute set to detail, dimension, or measure. All reportable data from all team projects that are defined in all project collections for a deployment of Team Foundation Server is written to a single relational data warehouse. Data from that warehouse is then processed and written to the OLAP cube. Collecting data into a single data warehouse supports reporting across team project collections.
The following illustration emphasizes that work item fields, field attributes, and global lists, which are displayed in blue boxes, apply across all team projects within a team project collection. The orange-colored boxes indicate WIT objects that are defined for a team project.
The WIT data store is updated in real-time as team members create and modify work items. Incremental updates are then written to the relational warehouse database and the OLAP cube every two minutes and two hours, respectively.
You can add new fields or customize existing fields to support your tracking requirements. For a complete list of fields defined for the default work item types that TFS provides, see Work Item Field Reference for Visual Studio ALM.
The following table indicates the elements and attributes assigned to a field that you can customize or localize. To add a field or change the field child elements, you customize the work item type where the field is defined. See Methods used to customize WIT objects. To change a field attribute, see Manage Work Item Fields.
Field child element or attribute
Notes, restrictions, and dependencies
No, with exceptions
Specifies the type of data that the field accepts. In general, you cannot change the field data type once it is defined. You can switch the field data type only for fields of type HTML or PlainText.
The friendly name appears in the drop-down menus of work item queries and it must be unique across all fields that are defined within a team project collection. The friendly name may differ from the form label that appears on the work item form.
On the work item form, you can specify any label that you want different from the friendly name.
You can enable indexing for a field to improve query response times when filtering on the field. By default, the following fields are indexed: Assigned To, Created Date, Changed By, State, Reason, Area ID, Iteration ID, and Work Item Type.
You can define a custom text string of up to 255 characters for each field within each work item type.
You can add or modify rules associated with a field, and combine field rules. For example, you can specify a rule to perform one of the following actions:
For each field rule, you can specify the name of a user or group for whom the rule does or doesn't apply.
For most field rules, you apply conditional rules based on the value assigned to another field. See
Customize any of the pick lists defined for a work item type, or add pick lists to support new fields that you add. Also, you can replace a pick list with a global list. A global list minimizes the work that is required to update a list that multiple types of work items share. A global list also supports cross-group consistency.
You can change the name of the field as it appears in a report, the report reference name, and the reporting type. You can localize the reporting friendly name.
The reporting type determines whether the field's data is written to the relational warehouse database, to both the relational warehouse database and to the OLAP cube, or to generate a pre-calculated sum of values when processing the OLAP cube.
For a complete list of the default reportable fields, see Reportable Fields Reference for Visual Studio ALM. For more information about the OLAP cube, see Perspectives and Measure Groups Provided in the Analysis Services Cube for Team System.
You can enable or disable synchronization with Active Directory for fields that are associated with user accounts.
You can add new work item types or customize existing work item types. The following table indicates the areas within a work item type that you can customize. You can learn more by choosing the link under the Definition element. You make changes to work item types using the Process Editor or by importing the modified XML definition file. See Methods used to customize WIT objects.
The name of the work item type appears in the drop-down menus of work item queries and it must be unique within a team project. You can change the name using the witadmin command line tool.
You can define a custom text string of up to 255 characters that describes the purpose of the work item type.
You can add or modify the field elements and field rules defined for a work item type. See Customizing work item fields.
You can customize the layout of the form to add or change fields, field labels, tabs, and columns. Also, you can customize the following elements within a form:
Each workflow definition consists of a set of valid and localizable states, transitions, and reasons. Teams use the workflow to track progress made to work items. The pick list of States and Reasons on the work item form is derived from the workflow definition.
You can specify the rules and conditions that apply to a field during a state change or a workflow transition.
You can specify a custom action to automate select field assignments based on a change in state, reason, or transition.
While the Agile burndown charts and queries are built from the WIT data store, out-of-the-box (OOB) reports, customized reports, and dashboards are built from data written to the relational warehouse database and OLAP cube. In addition to work item data, the warehouse contains data about builds, source code, test results and code coverage. All data captured for all team projects is written to the data store for the team project collection. All data for all team project collections is written to the relational warehouse database and OLAP cube.
To create reports that contain useful data about the status, progress, and trends about work items, team members must perform a number of activities. See Review team activities to support useful SSRS reports.
Once a team project has been created, you can customize a WIT object in one of the following ways:
Use the Process Editor to modify a work item type.
You can modify work item types by using Process Editor, a power tool add-in for Visual Studio which you can download and install. Located under the Tools menu, Process Editor provides a graphical user interface. You can use this tool to import and export work item types, edit work item types, and modify the contents of a process template. For more information, see the following page on the Microsoft website: Team Foundation Server Power Tools.
Modify an attribute of a work item field: You can use the witadmin command line tool to change the attributes assigned to a field. See Managing Work Item Fields [witadmin].
Export, modify, and import a definition file for a WIT object: For each object that you want to customize, you must perform the following steps: identify the scope of changes, identify dependencies, export objects, update objects, import objects, and verify changes.
The objects that you can customize using this process include work item types, categories, link types, global lists, global workflow, and process configuration.