Customize Team Projects and Processes

Artikel
04/17/2013

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.

Note

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.

Objects that you can customize

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.

Object	Team project	Process template	Description
Agile pages and charts			Supports creating the backlog, sprint planning, and team progress. To define the initial configuration, see Customize the Backlog and Board Pages.
Alerts			Supports definition of personal and team email notifications when changes occur to the team project.
Areas			Define logical, physical, functional categories, or areas owned by a team. See Define the Initial Areas and Iterations.
Build process template			You can add default build process templates which you use when creating build definitions. You can later customize build process templates.
Categories			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.
Check-in and check-out policies			Configure rules that enforce specific actions when users check in or check out code. See Define the Initial Configuration of Team Foundation Version Control
Dashboards (Agile) Dashboards (CMMI)			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.
Documents			Supports sharing of team documents and files through a project portal. Requires SharePoint Products. See Define the Project Portal.
Excel reports			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.
Global lists			Supports definition and maintenance of pick lists to be used by many team projects.
Global workflow			Supports definition and maintenance of work item fields and global lists to be used by many team projects.
Iterations			Define sprints or product release milestones. See Define the Initial Areas and Iterations.
Link types			Supports customization of link relationships between work items. See Add Type Definitions for Work Item Links.
Microsoft Project Field Mapping			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
Process guidance			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			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			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.
Test variables			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.
TFS Groups and Permissions			Supports configuration of security groups and permissions. You can configure initial groups, teams, members, and permissions or create new groups or change permissions
Work item fields			Supports monitoring progress and tracking data. See Tracking data to support queries and reports .
Work item queries			Supports finding work items and generating reports. See add queries to a process template.
Work item types			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.

Determining your scope requirements

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.

Scope	Objects	Implementation notes
Apply changes to a process template	See Objects that you can customize.	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	See Objects that you can customize.	Choose this option when only your team requires the changes.
Apply changes to several team project	See Objects that you can customize.	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.

Customizing Agile pages and charts

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.

Process configuration dependencies

WIT object customization and team activities

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
Product backlog	The types of work items that you can add to the product backlog. The fields that appear for quickly adding items to the backlog using the “quick add” panel. The initial set of columns and column sequence. The field that is used to manage backlog priority or the sort order of backlog items. You change this by modifying the CommonConfiguration.xml file, Order type. As you add items or re-sequence items, a background process dynamically updates the value of the Stack Rank field (Agile and CMMI) or the Backlog Priority field ( Scrum). See Customize the Backlog Pages.	Set the default team area and iteration path. These values are automatically assigned to work items created on the backlog and board pages. The product backlog only shows work items assigned to areas under the team's default area path. Sequence items to reflect relative priority by dragging them within the list. The sort order assigned through the product backlog page defines the sequence of items that appear on the iteration backlog and board pages. Drag items to an iteration. See Create and organize the product backlog.
Kanban board	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.
Iteration backlog	The types of child work items that you can add (default is task). You change this by modifying the Task Category. These same work item types appear on the task board. The initial set of columns and column sequence. See Customize the Backlog Pages.	Add tasks to backlog items. Tip To understand which work items are selected for display on a backlog page, choose Create Backlog Query, choose OK, and then choose the Click here to view it link. On the work items page, choose Editor. Drag items to the product backlog or a different iteration. See Work in sprints.
Task board	The types of work items that appear on the task board. The columns that appear on the board. These columns are associated with the workflow states that have been mapped to process configuration metastates. You define these mappings in the CommonConfiguration.xml file. If you make changes to workflow states, you may need to make changes to the process configuration. Not all states must be mapped. The maximum number of work items that can appear on the task board (default is 500). See Customize the Task Board Page.	Create tasks. Drag tasks to a different column. Update remaining work and re-assign tasks to another team member. See Run an iteration.
Burndown chart	The field that is used to calculate burndown. You change this by modifying the CommonConfiguration.xml file, Remaining Work type. See Customize the Backlog Pages.	Update the Remaining Work field for tasks. Tip Agile charts do not use information entered for Original Estimate and Completed Work. This information is only used in out-of-box (OOB) Excel and Report Manager reports for Agile and CMMI team projects, as described in Required activities to monitor progress and generate useful reports.
Capacity	The field used to calculate capacity-by-activity. You change this by modifying the CommonConfiguration.xml file, Activity type. The days of the week that the team doesn't work (default is Saturday and Sunday). See Customize the Backlog Pages.	For each task, specify a value for Activity (Agile and Scrum) or Discipline (CMMI). For each iteration, set the capacity and time off for each team member.
Velocity and forecast	The field used to calculate velocity and support forecasting. You change this by modifying the CommonConfiguration.xml file, Effort type. See Customize the Backlog Pages.	For each backlog item, specify a value for Story Points (Agile), Effort (Scrum), or Size (CMMI).
Tags	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.

Implementation notes

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.

Field	Category	Usage
Activity (Agile and Scrum) or Discipline (CMMI)	Task Category	Supports generation of capacity by activity.
Remaining Work	Task Category	Supports generation of the burndown and capacity charts.
Story Points (Agile), Effort (Scrum), or Size (CMMI)	Requirements Category	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.

Tracking data to support queries and reports

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.

Fields for tracking work and data stores

Note

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.

Customizing work item fields

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	Can change?	Can localize?	Notes, restrictions, and dependencies
Data type (FIELD element)	No, with exceptions	N/A	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.
Friendly name (FIELD element)	Yes	Yes	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.
Form label (Control element)	Yes	Yes	On the work item form, you can specify any label that you want different from the friendly name.
Indexable (attribute)	Yes	N/A	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.
Help text/tool tip (FIELD child element)	Yes	Yes	You can define a custom text string of up to 255 characters for each field within each work item type.
Field rule (FIELD child element)	Yes	N/A	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: Make a field required or read-only. Set a default or copy a value into the field. Clear a field, or restrict further modifications of a field. Make sure that a field does not contain the same value as another field. Require the value of a string field to match a pattern. Restrict who can modify the field. Apply a rule to a field when the value of another field has changed or is assigned a specific value.
Field rule, applies to	Yes	N/A	For each field rule, you can specify the name of a user or group for whom the rule does or doesn't apply.
Field rule, conditional	Yes	N/A	For most field rules, you apply conditional rules based on the value assigned to another field. See
Pick list/global list	Yes	N/A	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.
Reporting attributes	Yes	Yes	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.
Synchronization (attribute)	Yes	N/A	You can enable or disable synchronization with Active Directory for fields that are associated with user accounts.

Customizing work item types

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.

Definition elements	Description
Name	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.
Description	You can define a custom text string of up to 255 characters that describes the purpose of the work item type.
Fields	You can add or modify the field elements and field rules defined for a work item type. See Customizing work item fields.
Form layout	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: Add text, hyperlinks, or web content. Define controls to restrict link relationships
Workflow states, transitions, and reasons	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.
Workflow, field assignments, and field rules	You can specify the rules and conditions that apply to a field during a state change or a workflow transition.
Workflow, automation, and integration	You can specify a custom action to automate select field assignments based on a change in state, reason, or transition.

Required activities to monitor progress and generate useful reports

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.

Reports, metrics, and data stores

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.

Methods used to customize WIT objects

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.

Process for customizing objects that track work

The objects that you can customize using this process include work item types, categories, link types, global lists, global workflow, and process configuration.

See witAdmin: Customize and Manage Objects for Tracking Work Items

Additional resources

You might find additional answers to questions you have or you can post a question in one of the following TFS forums:

Dela via