RegisterLog In to dW

An Overview of Project Fundamentals in Rational Team Concert


Various discussions with customers and questions in the forums indicate that new projects starting to use Rational Team Concert often struggle to understand how Work Items, Planning, Build and SCM integrate. These fundamentals of RTC however are needed to boostrap and customize a project. This article provides a basic introduction of the underlying fundamental concepts of Rational Team Concert. The basic concepts described in this article apply also to newer versions of RTC.

A good overview about the features with links to more details can be found here:

Process Configuration Fundamentals

One basic task when setting up a project is to configure the basic process. This section introduces the basic concepts to consider.

Project Areas

In Rational Team Concert, project areas define the process used by everything they include. The initial process definition and description are provided by a process template. RTC ships with several predefined process templates that are a good starting point for various different project types.

The project area's Process Configuration editor is the main area for defining the basic process. It allows you to define roles, the permissions and process behavior for artifacts owned by the project area and it's enclosed teams.

Team Areas

A project area can contain team areas that inherit the project area's process, roles, permissions and operational behavior. Users are defined as members of project and team areas and along with their roles.  This combination of membership and role provides them with permissions and defines the behavior when working with artifacts owned by a project or team. Team areas may modify the permissions and the operational behavior they inherit from their parent.


The project area defines one or more timelines which define how a given planned period of time is partitioned into iterations such as releases, milestones, sprints etc. A project area can be assigned to exactly one project timeline to work against at any instance in time. Team areas contained in a project can also each be assigned to exactly one timeline to work against at any instance in time.  


Iterations typically a start and end date. Iterations can be planned to deliver a result by marking them with "A release is planned for this iteration".  The dates and the delivery information is used by the planning component to calculate availability of time and which iterations to consider to have plans.

Iterations can have an iteration type. Iterations with no delivey planned and with no dates configured can be used to control the process behavior within a parent iteration.  Each timeline has a current iteration that controls the process behavior.

Work Item Types

The project area's process configuration is also used to define which types of work items are available in this project area, which workflow they follow, which attributes they provide, and how they are displayed. It also provides a user interface to configure the planning component.

The project area configuration allows you to define a work item type to be a top level work item type. This controls how the planning component uses the work items of these types for work breakdown and effort tracking. Work items that don't belong to a top level work item type are called execution items.

Work Items

Work items represent work that needs to be done, such as tasks or defects. A work item has a work item type which defines the attributes and the workflow of the work item. Special attributes provided by default are used to provide mechanisms required to organize many work items across teams. 

The most basic data required for planning is which team area is the responsible owner of the work item and in which iteration is the work item planned to be completed as described below.


To allow users to assign a work item to a team, the project area provides categories. A category is basically a human readable text. Each category is associated to a project or team area.  

It is possible to have multiple categories assigned to a team area. This can help with planning, work balance and reporting. For example it is possible to create a category "MyProduct" with subcategories "Core", "User Interface" assigned to one team. These are also typical categories.


It is a common need to know for which release or version a work item has been created.  To support this, the project area provides a central place to maintain releases.  Releases such as "1.0", "2.0", "2.0 M3" can be created and maintained manually. It is also possible to create a release from a build result. 


The process of a project area provides available Plan Types to create a new plan. The plan type determines what the plan will show. Which plan types are available depends on the Process Template that was used when creating the project.

Work Item Fundamentals

Required Work Item Attributes

When creating work items it is necessary to provide some basic information. Work items require to at least have a type and a summary. It is possible to define which information is needed to be present when saving a work item in the process configuration.

The work item type is selected when creating a work item. The type can be changed later. Only the types available in the project the work item is created for are available. The work item summary needs to be provided in the Summary attribute.

Common Work Item Attributes

In an environment with multiple teams and multiple releases it is necessary to provide ways to make the amount of work items more manageable. The following work item attributes are used to do just that.
The work item's attribute Filed against allows to select and set the work item's category. Setting the category also sets the team area associated with it the owner of the work item.

The work item's attribute Found In allows to select and set the release the work item was created for.

The work item also has a workflow state which is driven by selecting actions in the workflow.

A work item can have exactly one responsible person, the Owner.

Planning a Work item for an Iteration

A work item can be planned for an iteration by setting the Planned for attribute. The work item can only be planned for an iteration belonging to the timeline the owning team is working against. To be selectable an iteration must also have the A release is planned for this iteration checkbox selected. 

Work items provide attributes to map to the basic process concepts
The image above shows the most important attributes used with work items and how they relate to the findamental concepts above.

Planning Fundamentals

The process configuration provides the available plan types to choose from when creating a plan. Plans are configurable queris on life data provided by work items selected by the plan.  

Each plan type provides some Plan Views, also referred to as Plan Modes. The Plan views configure how the data will be presented on the planned items tab. Each plan can have multiple plan views. New plan views can be created to present the data in a convenient way. Plan views are global. Changing a plan view of a plan changes it for all users.

Plan Details

Creating and configuring a plan defines the scope of the plan, which defines the data that is going to be presented in the plan. The plan's scope is defined by configuring the following Plan Details:

  • The owner of the plan specifies which team area contributes to the plan. Since the team area is also assigned to one time line this specifies which iterations can be selected.

  • The iteration of the plan specifies that only work items planned for this iteration are included into the plan.  The iteration selected can only be part of the timeline the plan owner is working against. Also it is only possible to select iterations that are planned to deliver something. The latter is specified by setting the A release is planned for this iteration property for the iteration.

  • The plan type that determines how the plan views, as well as which of the work items qualified by the above information, will be presented. The choice is to include only top level work items or all work item types.

Planned Items

Plans only show work items in their scope within the Planned Items tab. Plans will only consider work items in scope that have the Planned For attribute set to the iteration or nested iterations the plan is configured for.  Plans will also only consider work items that are filed against the team area or one of its child team areas the plan is configured for.

By default several plan types will also only show top level work items to reduce the amount of details presented.

Plans that show only work items of types defined as Top Level Work Item Type can be configured to also show execution items. This can be done for example in the Web UI. Edit the Plan Details and select the check box Include All Items to include execution items in the view. The impact of this is longer load times for the plans. The filter Execution Items can be used to filter these work items out for a better overview when the plan is configured to load execution items.

 Configure a plan to show execution items

Where is my work item?

If a work item disappears from a plan or one you expected is missing from your plan it is probably filtered out or out of the plan's scope. Check for the acticve filters and if execution items are includen in the plan. Carefully check the work items attributes, especially Planned For and Filed against.

Independent of its configuration, in RTC 3.x a plan will only show and consider work items that are planned for an iteration that belongs to the the plans owners timeline. Although you can create work items on a plan and plan them for a different timeline, the next time the plan is loaded these work items will not be presented on the plan. 

In work breakdown structures child work items planned for a different timeline will also not be presented and their estimation and effort values will not be calculated or rolled up by the plan.

For more information

About the author

Ralph Schoon is a member of the Jazz Jumpstart team.  The Jazz Jumpstart team is a worldwide group of development specialists who bring new and advanced Jazz-based technologies to customers. Please direct feedback and comments to .

Was this information helpful? Yes No 19 people rated this as helpful.