Tool: IBM Rational Team Concert
This tool is a collaborative software delivery environment that empowers project teams to simplify, automate and govern software delivery.
Relationships
Main Description

IBM® Rational® Team Concert is a collaborative software delivery environment that empowers project teams to simplify, automate, and govern software delivery. Automated data collection and reporting reduces administrative overhead and provides the real-time insight required to effectively govern software projects. Dynamic project provisioning enables day one productivity, while real-time collaboration helps significantly reduce scrap and rework. Rational Team Concert extends the capabilities of the Team with integrated work item, build, software configuration management (SCM) and the collaborative infrastructure of the Jazz Team Server.

Terminology mapping

Process descriptions in IBM® Rational® Method Composer use general purpose terminology for work products because they need to be understood across a variety of circumstances and tools. Specific tools often need to refine that terminology to increase clarity and usability. This page describes how artifacts defined in this process are defined IBM® Rational Team Concert™.

Common Artifacts

Rational Method Composer artifact Rational Team Concert artifact
[Project Work]  

The [Project Work] includes the Work Items List, which is a list of all work for the project or release. In Rational Team Concert, work items such as user stories are initially added to the release backlog and can be visualized in the release plan (Scrum Process template) or in the project plan (IBM Practices for Agile Delivery Process template). The work items (such as user stories) are later assigned to iterations and moved from the release backlog to the Sprint Backlog (scrum process) or Iteration Plan (IBM Practices for Agile Delivery). New work items such as tasks needed to develop and test user stories are added to the Sprint Backlog or Iteration Plan.

Project tasks in Rational Team Concert are maintained as Work Items. A description of the work that needs to be performed during a specific time period is defined in an Iteration Plan.

Risk List In Rational Team Concert, risks can be represented as work items of type risk, issue, or any custom work item type. The risks can be prioritized, assigned to owners, and further detailed with tasks that need to be performed to address them. A risk list in Rational Team Concert can be retrieved by a query that shows all work items of that particular type you are using to capture risks.
[Technical Specification] Change requests and stakeholder requests in Rational Team Concert are generally maintained as Work Items. Technical specifications also contain requirements, so there are probably other tools in your environment that maintain other parts of the Technical Specification.
Work Items List The Work Items List is the list of all work for the project or release. All work items in Rational Team Concert (such as requirements, defects, tasks, and so on) are added to the tool repository so that they can be tracked, assigned to or taken on by team members, resolved, closed, and so on. Work items can be assigned to plans (such as the Project Plan and Iteration Plan), retrieved by queries, and visualized in dashboards.


Practice: Setting Up a Performance Measurement System

Rational Method Composer artifact Rational Team Concert artifact
Measurement Infrastructure

The Jazz Team Server, normally running on a secured server-class machine and hosts a set of services and a repository. Remote clients communicate with the IBM® Jazz™ Team Server over the network by using HTTP.

The Jazz platform includes an extensible repository that provides a central location for tool-specific information. Data is stored in the repository according to top-level objects called items.

The project area is the system's representation of a software project. The project area defines the project deliverables, team structure, process, and schedule. A project area is stored as a top-level or root item in a repository. A project area references project artifacts and stores the relationships among these artifacts. Access to a project area and its artifacts is controlled by permissions.

The dashboard is a Web client user interface component that provides information about the project status at a glance. Users can view project summary information or more detailed information.

The Data Warehouse in the Jazz repository is an extensible storage mechanism for aggregated, historical data. The included Jazz reports component collects several data points related to work items, builds, and source control that you might want to show in a report.

The reports engine on the Jazz Team Server generates reports from the data in the data warehouse. This engine is based on the Eclipse BIRT (Business Intelligence and Reporting Tools) project. BIRT reads a report template, gathers the necessary data from the data warehouse, and generates a report that can be viewed in the Jazz Web UI and Eclipse client.

See the glossary for more terminology information.

Measurement Requirements Details of project tasks are documented in work item descriptions or attached to a work item as linked documents. A list of objectives for developing a performance management dashboard, as well as a list of reports that will be displayed on a dashboard along with the metrics those reports will gather, can be stored in a work item by using either of these approaches.
Measurement Specification

After parameters have been entered in a report template, the result can be saved as a report. A report consists of a reference to a particular template, together with this collection of user-supplied parameters. It is these saved reports that appear in the Reports page in the Web UI, as well as under My Reports and Shared Reports in the Team Artifacts view of the Rational Team Concert client. Because the parameter values are known, reports can typically be given useful and descriptive names.

BIRT generates a report with the associated pieces that integrate the viewer into the Jazz Web UI and Eclipse client. Reports are also displayed on the Web UI dashboard by using the Reports viewlets.


Practice: Iterative Development

Rational Method Composer Artifact Rational Team Concert Artifact
Iteration Plan (Project Level)

An Iteration Plan in Rational Team Concert displays the goals to be achieved in one iteration and organizes the planned work items for the iteration. The iteration assessment or Retrospective information can be captured in a tab of the Iteration Plan or, alternatively, in a Retrospective work item type assigned to the iteration. Note: If you follow the Scrum Process template, the plan for an iteration is called the Sprint Backlog, instead.

Practice: Risk Management

Rational Method  Composer  artifact                                 Rational Team Concert artifact

Risk List

[Project Risk]

Risks are captured as Risk work items in Rational Team Concert. There are Rational Team Concert process templates that provide Risk as one of the available work item types to be created, and a state machine for the Risk work item type is provided to help track the status of work associated with each risk.


Practice: User Story Driven Development

Rational Method  Composer  artifact                                 Rational Team Concert artifact
User Story

User Story artifacts are captured as User Story work items in Rational Team Concert. There are Rational Team Concert process templates (such as Scrum and IBM Practices for Agile Delivery) that provide the User Story as one of the available work item types to be created, and a state machine for the User Story work item type is provided to help track the status of work associated with developing and testing each user story.

The user story work item contains the user story description and details that help the team implement and validate the user story implementation: 

  • In the work item Summary field, add a short name for the user story. A suggested representation for the summary field is: Develop User Story: <story name>. This helps clarify that the user story work item represents the work that needs to be performed to develop the user story.
  • In the Description field, the recommendation is to add the user story statement in this format: As a [user role] I want to [goal] so I can [reason].

User story confirmations are captured in different sections of the respective work item:

  • In the Overview tab, use the Description field to add detailed information, such as data exchanged by users with the system. In the Discussion section, add a comment to capture the decisions and the rationale for those decisions so that stakeholders and all team members have a history of all discussions related to a user story.
  • In the Acceptance Test tab, use the Acceptance field to add acceptance conditions that will be used to generate test cases for the user story (for example: exceptions, error conditions, alternative behaviors, system-wide requirements, and so on).
  • Within the Links tab, in the Subscribers section, add team members and other stakeholders who are interested in receiving notification when the user story is updated.  

More Information