Tool Mentor: Developing with Rational Team Concert
Complete development of the stories.

Synopsis

Sprint stories are coded, tested, and delivered.

Value

In Scrum, progress is measured by delivering tested capabilities into the product. This ensures that real progress is taking place.

Pre-requisites

The following are pre-requisites to this tool mentor:

Steps

Perform the following stepsSteps

Perform the following steps.

Step Tool guidance

1. Review and update assigned work




1.1. Review assigned work

Review assigned work to determine what to work on next.

Before starting development work, review outstanding task details, the user story, and dependencies.

Request clarification from the Product Owner and other team members as required.

Launch the Rational Team Concert Eclipse client.

View your assigned work items in the Current Work section of your My Work view.  See Managing work items in My Work view

Triage work items from your inbox to the Current Work and Future Work sections.  See  Managing my new work.

Double-click on work items to open them.  Mouse-over or click on the parent link to review the parent Story for a task.  View the current release or Sprint plan by clicking the Open Current Work button.  View as ranked list to help decide what is most important to work on.  See Viewing work items in a plan in the Eclipse client.

You can also view your work items in your team dashboard (web or Eclipse client), or personal dashboard (web client only).

1.2. Update status and estimates

While reviewing and choosing what to work on, you should make updates to status and correct estimates.

User stories that

Use the Current Work section in My Work view to manage work items assigned to you in a current Sprint.

  • Modify work items and arrange them in order of planned completion.
  • The My Work Load indicator shows your remaining available hours in the iteration compared to the estimated hours for your unresolved work items.
  • Adjust the work item's estimated duration. Right-click a work item in this section and select Show Work Time to modify the corrected estimate and time spent on the work item.  See Managing my current work.

The Future Work section in My Work view contains all open work items that do not belong to a current iteration. Items are grouped by iteration. Work items that are not planned for an iteration are shown in the Unassigned group at the end the section. See Managing my future work.

You can use the Filter Box to find, filter, and colorize work items on the Planned Items page of a plan and in the My Work view.  See Find, filter, and colorize planned work items.

2. Develop

The following steps describe some typical activities performed while working on an assigned task.

See Developing for more extensive guidance on the steps outlined below.

2.1. Accept/merge changes

Before making changes, you may want to accept and merge changes made by others on the team.

To accept changes made by others, go to the Work Items perspective and the Pending Changes view.  Right click on the Incoming folder for each component to accept changes.  See Incoming change sets.  To merge changes that conflict with changes you have made in your workspace, see Finding and resolving conflicts.

2.2. Code and test

This may include some design work.  It always includes writing code and tests, and testing that code until it passes.

Use standard Eclipse features to code and test.

For an example tutorial, See Explore the Rational Team Concert JUnit example project.

2.5. Check in changes

After you save your changes, check them in. Checking in your changes copies them from your local sandbox to your repository workspace and ensures that your work will not be lost if your computer suffers a hardware failure. It is good practice to check in your changes frequently.

See Checking in changes in the client for Eclipse IDE.


3. Deliver changes

After completing one or more tasks, deliver (share) changes with the rest of the team, and perform additional testing as required.  


3.1. Understand delivery streams

Before delivering code to the rest of the team, you may want to understand the delivery stream (where code goes after it is delivered.

See Visualizing workspaces and streams

3.2. Verify new code will not break the build

While working on tasks, you may want to periodically update your workspace with changes delivered by other members of the team.  Before you deliver your changes, you often must merge code and re-test your changes to avoid breaking the build.


See Jazz Source Control - resolving conflicts.

3.3. Deliver changes to the development stream

Deliver your changes so that they can be picked up by the rest of the team.
See Delivering change sets

3.4. Update work item status

Review the definition of "Done" to ensure the task is complete. Then mark the task as complete.

See Managing my current work.