Configuring Project and Team Areas for Work Items

This section shows how to set up your Project Area for Work Items and how to configure Team Areas for team specific behavior.

For the project as a whole you can specify the set of categories available for the Filed Against attributes, and the set of releases available for the Found In attribute.

For individual Team Areas you can specify the required properties of work items and you can configure how certain attributes are set/reset when a work item is reassigned from one team to another.

If you want to customize Work Items even further to your project’s or team’s needs, learn how Work Items can be customized in Work Item Customization.

Configuring a Project Area for Work Items

Since Work Items are filed against Categories (functional Area) and Releases (of a product), you need to define value sets for both attributes in the Project Area.

Work Item Categories

You can define the categories used to organize work items with their Filed Against attribute on the Work Item Categories page of the project area editor. Categories can be created, archived/unarchived, renamed and moved to another parent category. A category is moved using drag&drop.

Each category can be associated to a team area and when no explicit association exists the parent category’s team area is used. A category’s team area determines the enacted process and the team responsible for all work items filed against that category. The root category determines the team area for work items not filed against any category.

Category subtrees can be hidden from members of other teams and outside contributors by unchecking the visibility check boxes in the category tree. This allows for fine-grained category hierarchies without exposing the complexity to the creators of work items not familiar with the internal team structure.

To get started using work items in a new project area, open the project area editor from the context menu of a project area in the Team Artifacts view, go to the Work Item Categories page and make sure the root category is associated to a team area.

Example configuration of categories.

When working with multiple timelines, each category can be associated with a different team area per timeline. In that case, the team area of a work item is determined by the Filed Against category and the timeline of its Planned For iteration. This allows for using different processes and representing different teams for each timeline. The editor shows a timeline switcher when multiple timelines exist. If only a single team is responsible for multiple timelines, the <any> entry can be used.

Example configuration of categories in a project with multiple timelines.

If a project area has no teams at all, the association of categories to teams is disabled and the process of the project area is used.

Example configuration of categories in a project without teams.

Releases

You can define the set of releases available for the Found In attribute of work items on the Releases page of the project area editor. Releases can be created, archived/unarchived, renamed and their order can be changed.

A release can be hidden from users not part of a project team. This allows for internal milestone or test releases without exposing these to the outside. A release also has an optional description and creation date.

If a release is created from the build result editor, the build result will be associated with the release and the Found In link in the work item editor will open the build result.

Example configuration of releases.

Configuring a Team Area for Work Items

Required Properties Precondition

You can specify the work item properties that must be set to a non-default value when saving in the Required Properties Precondition. The configuration is scoped to either a work item type or a type category. It is furthermore possible to configure required property for a specific workflow state.

Implied Properties Precondition

You can configure the Implied Properties Precondition to automatically unassign the owner of a work item when its team area changes and assign it to the current user when the state transitions to in-progress or resolved during a work item save.