Scrum project management with IBM Rational Team Concert Version 2, Part 2

Plan and manage sprints

Jazz technology helps automate agile planning and management


Content series:

This content is part # of # in the series: Scrum project management with IBM Rational Team Concert Version 2, Part 2

Stay tuned for additional content in this series.

This content is part of the series:Scrum project management with IBM Rational Team Concert Version 2, Part 2

Stay tuned for additional content in this series.

For more than a year now, we've been using IBM® Rational Team Concert™ to support our scrum teams, delighting in many of its features, living with some of its shortcomings, and looking forward to the next version. With Version 2, the Jazz and Rational Team Concert teams have delivered dramatic improvements to their scrum and agile estimating and planning support (not to mention a much improved Web client and many other new features). This article series provides an up-to-date tutorial on getting started with Version 2 and the scrum process and highlights new features and capabilities important to scrum teams and their managers. It updates the article published in 2008 that covered Rational Team Concert Version 1 and scrum project management.

Sprint planning

As we discussed in the "Overview of the scrum process" section in Part 1 of this series, each sprint starts by pulling items from the Product Backlog into the iteration and then developing a Sprint Backlog of tasks that the team needs to complete. Although the result of sprint planning is a collection of estimated tasks, which are most likely assigned to various team members, it is important to remember that the purpose of sprint planning is for the team to commit to completing a collection of stories, adding new and deliverable functionality to the product. The planning and estimating helps the team decide how much work will fit into the sprint.

Create the Sprint Backlog

  1. Create a Sprint Backlog iteration plan (see Figure 1):
    1. Similar to the previous instructions for creating the Product Backlog iteration plan, right-click on Sprint 1 (1.0) in the Plans node of the Team Artifacts view, select New and then Plan.
    2. In the dialog window, enter Sprint Backlog for the name.
    3. For Plan Type, select Sprint Backlog and then associate it with the Havannah Team area.
Figure 1. Creating an iteration plan that holds the Sprint Backlog
Action and window to create a plan
Action and window to create a plan
  1. On the overview page of the Sprint Backlog, document the sprint goal (Figure 2)
Figure 2. Documenting the sprint goal
Sprint Backlog overview page
Sprint Backlog overview page
  1. Click Save.
  2. Assign stories to the sprint
    With the Product Backlog window open, select the relevant stories, and then right-click and select Plan For and then Sprint 1.0 (see Figure 3). As an alternative, you can change to the Iterations view and drag the stories from the release to an iteration (Figure 4).
Figure 3. Assigning stories to the iteration
Product backlog with action popup smenu
Product backlog with action popup smenu
Figure 4. Dragging stories to the iteration
Product backlog in Iterations view mode
Product backlog in Iterations view mode

This will assign the stories to the Sprint Backlog. Initially, small asterisks in the left margin indicate that a change is pending. (In Rational Team Concert V1, the stories actually moved from the Product Backlog to the Sprint Backlog, but in Rational Team Concert 2.0, they stay in the Product Backlog for easier tracking. In V2.0, you use the Iterations view to monitor which iterations the stories are assigned to.)

  1. Click Save to complete the move.
  2. Click the Sprint Backlog tab to bring it forward.

Figure 5 shows the results.

Figure 5. Stories assigned to an iteration
Sprint Backlog: 3 stories in work breakdown view
Sprint Backlog: 3 stories in work breakdown view

Add tasks to stories

The next step is to break down the stories that have been added to the sprint. This means that tasks are created for every step that needs to be performed to get the story to "done" (that special scrum definition of "done" which means that the feature is truly finished and can be fielded, if necessary).

  1. Before entering tasks, set up a shortcut to make this easier: Right-click on the first story to add a Work Item (much in the way that you added stories), but select the Set Default option from the drop-down menu, instead.
  2. Set the Default for new work items to Task so that whenever you press Ctrl+Enter, it will automatically add an item of this type (Task).
  3. Click OK.
Figure 6. Set the default type for new work items
Action and Work Item Type selection window
Action and Work Item Type selection window
  1. To start entering tasks, select the corresponding story and press Ctrl+Enter.
  2. Enter the summary for the task.

A task will be created beneath the selected story. However, notice that it is currently at the same indentation level as the story (Figure 7).

  1. Because this task "belongs" to the story, press Tab once to move it under the story.
Figure 7. Creating a new task
Part of Sprint Backlog with new task
Part of Sprint Backlog with new task

Subsequent tasks added to this story will automatically be considered "children," or substories.

Make sure that you use a view where items are displayed in a tree mode. In case you selected a view where items are shown in a flat manner, you will not be able to indent tasks. The Work Breakdown view that is opened by default when a sprint plan is created shows items in a tree view.

In a typical Sprint Planning meeting, team members call out tasks that need to be done. Just getting them all recorded will be sufficient for now. Time estimates and assignments can come later in the meeting.

  1. Continue adding tasks for this and the other stories.

Because of the iterative and interactive nature of sprint planning, it may work out best to do these steps for one story and then complete the steps below that to provide estimates and owners for the tasks. Then you can return to this section to plan the next story. There is no point in planning more work than there is time to do. Keep an eye on the Team Load indicators to know when to stop.

Estimate the tasks and assign owners

Now it's time to estimate the tasks that have been entered for your stories. However, some teams prefer to first assign an owner for each task to be able to estimate according to the team members' skills.

You can do the following steps in the order that fits your team's practices.

  1. To enter estimates for your tasks, open the Preview editor by clicking on the eyeglasses icon in the Sprint Backlog. Then enter the estimate for each task, one after the other.

    Alternative: Estimates can also be entered in the list by selecting from the drop-down menu. If your time estimate is not in the drop-down menu, choose More, and to get a small input screen where you can enter your estimate. Enter the estimates in terms of days and hours, for example: 10 h or 2 d.

Figure 8. Entering time estimates
Sprint Backlog showing task preview
Sprint Backlog showing task preview

When you have entered all estimates, you can see the total estimates for each story, as well as for the whole sprint.

Figure 9. Entering time estimates from the list
Sprint Backlog with tasks
Sprint Backlog with tasks

Typically, scrum team members sign up for tasks, and the assignments can be made at the same time. Because different team members may take different amounts of time to complete a task, you may prefer to finalize a time estimate after an assignment has been made.

  1. In the Sprint Backlog, from the list, drag tasks to the members assigned to the Havannah team.
Figure 10. Assign owner
Sprint Backlog with tasks assigned to owners
Sprint Backlog with tasks assigned to owners

The arrows at the left of an item indicate that these items are assigned to someone or somewhere else. Typically, tasks are assigned to team members, but the stories remain unassigned, and the team or the Product Owner decide when a story is complete. One advantage to this approach is that the breakdown of a story into tasks is always visible from this (and other) views that display both stories (top-level work items) and tasks (often not considered top-level work items).

Also, the workload is shown for every team member. Team workload can be monitored as tasks are estimated. To balance the workload and monitor progress, all team members must have entered their work assignments as well as their scheduled absences.

Notice that Rose has only 54 available work hours because of her limited availability and vacation day. You would continue estimating tasks until team members no longer have time available. For scrum teams to be successful, remember to leave some slack in everyone's workload to adjust for estimates that are inadequate or for interruptions. The intent is that all of the work committed is completed, no matter what comes up, so choose a percentage of slack that fits your team. To help assure success, leave more slack in the early stages -- you can tighten it as you better understand the team's rhythm and capabilities.

Team Central view

Another way to show the team's work load is in the Team Load section in the Team Central view. You can keep this view open along with any other view even if the backlog is not opened. This can be a particularly convenient way to monitor the team workload when views other than the Sprint Backlog occupy the main editor window.

Figure 11. Team Central view
Team Central view with configuration window
Team Central view with configuration window

If the Team Load view is empty or indicates "Not Connected," you need to configure it: Click the downward white triangle icon to the right of the Team Load view to use its drop-down menu, and select Configure.

Assign and track work during an iteration

Rational Team Concert provides the My Work view to help each team member track their own work. If My Work is not visible in your workspace, select Window > Show View > My Work. It will typically open in the left pane, along with the Team Artifacts and Team Central views. Right after sprint planning, most users will have the new tasks in their inboxes, awaiting acceptance.

My Work view

In Figure 12, Prasad opens his My Work view and then uses the link to accept all of the work.

Figure 12. My Work view
My Work view shown in Eclipse and Web clients
My Work view shown in Eclipse and Web clients

Unlike Rational Team Concert Version 1, which put all accepted work into an "Imprecisely Planned" state, Rational Team Concert 2.0 adds the items to your Current Work and defaults them to the order in which they were added to the view. All users should review this ordering and drag the tasks into the order in which they actually plan to perform the work (it can always be rearranged later as needed).

An important reason to properly use the My Work view is to support the team's work tracking and planning.

Planned Time view

Tracking can also be done efficiently by using the Planned Time view for the Sprint Backlog (see Figure 13).

Figure 13. Planned Time view
Sprint backlog in Planned Time view
Sprint backlog in Planned Time view

The Planned Time view makes it easy to see what work is remaining and when the owner is planning on doing it. As teams browse this view, they might find ways to reorder their tasks to better support their teammates. The Planned Time view can also be used to support the Daily Scrum meeting, thus making it pretty easy to discuss what's done and what's next.

To support the views discussed so far, team members should start working on tasks, regularly report how much time they believe is remaining on them, and eventually resolve them. Given that the scrum method emphasizes work completed, not work started, it is preferable to start and complete a work item before moving on to the next item. This enables the team to complete stories more quickly and to reach "Set Implemented" for them sooner.

To help keep track of the amount of work still open until the story is completed, Time Remaining should be recorded for each task that people worked on each day.

Time Remaining is a simple text field; therefore, if a task is worked on for multiple days, each team member needs to update the Time Remaining field each day according to what is left at that time for the particular task.

To help team members track their histories and successes in estimating tasks, a correction for the estimate should be entered as soon as it is discovered that the original estimate was inadequate (see Figure 14).

Figure 14. Adjusting the estimate and remaining time
Task editor with hover prompt for time remaining
Task editor with hover prompt for time remaining

If you prefer to report the time that has been spent so far for a task, you can configure your Project Area accordingly.

  • Open your Project Area and, on the Process Configuration tab, expand Project Configuration and Configuration Data and Planning, and select Work Item Progress Mode.
  • There, you can switch to Time Spent.

Use the Discussion feature to record progress or to capture information learned about the task. Any team member can update information in this field, and it is an excellent way to capture the history of the work item.

Story progress should be tracked by starting work on it, as well. Often, no particular team member is made responsible for the story as a whole, thus, as the tasks under the story are completed, the scrum master can set the story as "Complete Development" (see Figure 15).

Figure 15. Preparing the story for the Sprint Review
Sprint Backlog with story editor overlaid
Sprint Backlog with story editor overlaid

Developer's Taskboard view

Another way to assign and monitor work is the Developer's Taskboard, which shows the tasks assigned to individuals in columns that indicate which tasks they have already started or completed. Also, it always shows the relationship of the tasks to their parent items (typically stories) in the left-most column. Scrum masters or team members can easily reassign items by dragging them to other team members. They can start working on items or set them to completed by simply dragging them to the appropriate column.

Figure 16. Developer's Taskboard
Sprint Backlog in Taskboard view
Sprint Backlog in Taskboard view

Tracking and reporting progress

Monitor work by using queries

A very flexible way for team members to track their work is by using queries. There are many predefined queries available, plus you can also easily create your own queries. Because using a query is as simple as double-clicking the query name, we'll show you how to build your own custom query. If an existing query almost matches your needs, you can use steps similar to these to customize it and then save it with a new name.

  1. In the Team Artifacts view (Figure 17), right-click My Queries and select New Query.
  2. In the Query editor window, click Start from scratch.
  3. Click the plus sign on the top-right side of the window to add a new condition.
  4. Complete these settings:
    • Type: Task
    • Planned for: [select]
    • Name: Sprint 1
    • Status: Unresolved
Figure 17. Create a new query
Query editor with window to add condition
Query editor with window to add condition
  1. Under the Result Layout tab, select these columns:
    • ID
    • Summary
    • Priority
    • Owned By
    • Estimate
    • Corrected Estimate
    • Time Spent
  2. Sort by Owned By and Priority (Figure 18).
Figure 18. Configure the layout of the query results
Result Layout tab of the Query editor
Result Layout tab of the Query editor
  1. Click Save.
  2. Click Run to run the query.

The query results are shown in the Work Items view.

From the Work Items view, the drop-down menu enables you to start working on an item. You can also open a task to change its state (Figure 19).

Figure 19. Start working on a task
Work Item view with action popup menu
Work Item view with action popup menu

The Recently Modified query

One way to easily prepare for the Daily Scrum meeting is to use the Recently Modified query (a predefined query) to identify tasks that have been updated in the last day or so (Figure 20). You can configure the number of hours that qualifies as "recently" by using a query argument. The default value is 12 hours.

This list will quickly show who has been doing what. It helps determine who has not reported any progress lately (notice that Rose's name does not appear in the list).

Figure 20. Running the recently modified query
Query action menu and Work Items view
Query action menu and Work Items view

Progress bars

To quickly see progress and status information, progress bars are available at many places in Rational Team Concert. These progress bars already provide a good view on the current status of the progress for an iteration, the progress of a particular story, the workload for a team member, and much more. For active members of the project team, these load bars may present all of the information that they really need to track progress within a sprint.

Burndown reports

The team can also use burndown reports to keep track of how work is progressing and to view the history of their progress. They can use a Product (Release) Burndown report to track overall project progress, and they can use a Sprint Burndown report to see how work is progressing for the sprint.

Product Burndown report

Reports are easy to access from the Team Artifacts view (Figure 21).

  1. Open the Release Burndown report (in scrum terms, this is called the Product Burndown report) by opening the Reports node in the Team Artifacts view and then opening the Shared Reports and Work Items folders.
  2. Double-click the Release Burndown report.

You might be asked to log in to the team server.

The report in Figure 21 displays the Story Points remaining at the beginning of each sprint, as well as the total amount of planned work. In this example, the planned work remained constant over the first three sprints. During the third sprint, additional work was added to the Product Backlog, which led to a smaller decrease of remaining work until the fourth sprint started.

Figure 21. Open a burndown report
Action menu and release burndown graph
Action menu and release burndown graph

For tracking trends and historical reporting, Rational Team Concert uses data warehouse technology to collect and somewhat compress what would be a large amount of data, even for a relatively small project. If you are trying to look at reports while working through this article and find that they have no data in them, you didn't do anything wrong. The report in Figure 21 was created after monitoring the project progress for five sprints. When you've just started, it's likely that the data warehousing "snapshot" collection hasn't run yet. This process typically runs at midnight in the Jazz server's time zone, so you need to have a server that's up all of the time for the process to run automatically. Snapshot collection can be forced from the Web UI, although this is not recommended in a production environment, because the process can be resource intensive and can affect user response during normal working hours.

Figure 22. Product Burndown report when no data is available
Section of Release Burndown view with a message
Section of Release Burndown view with a message

There are numerous reports provided by Rational Team Concert. You can also use the Business Intelligence and Reporting Tools (BIRT), an Eclipse-based reporting system, to create your own reports.

Figure 23. Examples for reports
Overlaid story point graphs
Overlaid story point graphs

You can add reports, such as a burndown report, and queries, such as "Open Assigned to Me" and "Recently Modified," to your Favorites folder. Right-click on the ones that you want to add and select the Add to Favorites drop-down menu item. This will make them much easier to access.

Sprint Burndown report

The Sprint Burndown chart provides an instant answer to the question "Are we on track to finish all of the work that we committed to do?" Assuming that all of your team members update their work items appropriately, the line trends closer to zero (work remaining) as work is completed. The burndown rate should be easily visible to all of the team all of the time.

The easiest way to display the Sprint Burndown report is to:

  1. Open the Sprint Backlog (iteration plan).
  2. Go to the Charts tab.

For the Sprint Burndown report to look similar to the one in Figure 24, you must have updated and logged work completed by various team members for several days.

The Select Report button gives you easy access to other reports that can also be interesting to monitor during a sprint.

Figure 24. Sprint Burndown report
Overlaid Sprint Burndown graphs
Overlaid Sprint Burndown graphs

If team members do not update their data by the end of each day, the status of their work items will not be properly reflected in the report. Although updating the status of their tasks will help the trend line to catch up at the next processing point, there is no way to update the history. The task will show as done (finished) on whatever day it is closed, not whenever the work was actually finished.

Jazz does not skip non-work days in its plotting, because it's hard to preset which days are non-work days for a globally distributed team. Therefore, flat lines often represent weekend times but could also be symptomatic of a lack of progress (or progress updates).

Schedule the Sprint Review and Retrospective meetings

An important part of the scrum process is the Sprint Review meeting. The first part of this is the demo to the stakeholders. Using Rational Team Concert may not be part of this, because the point is to show off working software, not the list of tasks. However, feedback and comments from the review meeting should be captured, either in the sprint's Overview page or as an attachment to that page.

The next part of the Sprint Review meeting is the Retrospective (sometimes called Reflection). This is a chance for the team to discuss what went well, what didn't, and what they plan to do about it. The Scrum Process template defines a Retrospective work item type (Figure 25) that can be used to make sure that the reflection meeting occurs and to track the team's comments and plans.

Figure 25. Work item for the Retrospective
Editor window for a Retrospective item
Editor window for a Retrospective item

Do it over again for the next sprint

The life of a healthy scrum team is one filled with a rhythm of success. Plan a while, work a while, deliver, and repeat.

You have now finished your first sprint, so it's time to start on the next one.

  1. Create a plan for Sprint 2. Proceed the same way that you did when you created the plan for Sprint 1.
  2. Document the sprint goal on the Overview page
  3. Then start adding items to this sprint, using the same approach as for Sprint 1.

If a story does not get completed in the current sprint, there are various practices to solve this problem. One option is to drag it to the new sprint. You must drag it to the new sprint for subordinate (child) tasks to move to the new sprint with it, or you can select all of the items at once. Merely reassigning the story by using the drop-down menu (right-clicking and selecting Plan for) will not move the children, or subtasks.

Instead, follow these steps:

  1. Click the tab for the Sprint 2 Backlog and drag it toward the bottom of the screen, so that you make both plans visible at once.
  2. Then drag the story from one to the other.
  3. When you are asked whether to reassign the children, select Yes.

The story and subtasks are now moved to the next sprint. When the tasks are assigned to owners, the work load for the team members is immediately adjusted.

Figure 26. Planning the next iteration
Sprint Backlogs for current and next sprint
Sprint Backlogs for current and next sprint

The asterisk to the left of the story indicates that the changes have not been saved yet. The gray arrow pointing to the left of the grayed copy in the Sprint 1 window indicates that movement of the item is pending.

  1. After you click Save, the move will be completed.

Select the next sprint as "current"

Even though you created dates for the sprints, Rational Team Concert does not automatically shift to make the next sprint the current one just because time has marched forward. You must manually adjust which sprint is considered current.

  1. Open the Havannah project, and, under the Overview tab on the right side, select Sprint 2, and then click the little blue tilted triangle icon (see Figure 27) to move the current designator to the new sprint.
Figure 27. Setting the current iteration
Timelines section of Project Area editor
Timelines section of Project Area editor

Add more iterations

When you need to add a new iteration for the project, open the project again.

  1. Under the Overview tab of the project, either click Create Iteration to add a new one or choose an existing iteration and then click Duplicate. To keep the identifiers and display names consistent, you can use the duplicate approach. In this example, create a third iteration for the product: click Sprint 2 and then select Duplicate. (Also see Figure 48.)
  2. Remove the "Copy_of_" text, and change the appropriate sections to name the new iteration.
  3. Adjust the dates and click OK.
  4. Save the Project Area changes.
Figure 28. Duplicating an iteration
Timelines section with two windows
Timelines section with two windows

Learn more, and consider these options

Even though you've covered a lot of ground in this exercise, there's so much more to Rational Team Concert and Jazz than scrum-based agile planning, and there's even more to agile planning than has been described here. For starters:

  • Consider using Jazz source control and the Jazz build engine to power your continuous integration efforts.
  • For team members who are not developers (or those who don't want to install the Eclipse client), introduce them to the Web UI for checking work items and project status. With Rational Team Concert 2.0, the Web UI is dramatically improved and pretty much on par with the Eclipse client. Even your Eclipse- or Microsoft® Visual Studio®-based developers might prefer the Web UI for some things, such as the dashboards (and your managers will become addicted to the Web dashboards). Try the various reports to see which ones fit how your team manages their process.


We'd like to thank Dirk Baeumer, Jazz Agile Planning Team Lead for his technical review and David L. Schmidt, Technical Lead, Tivoli Software Engineering, for his general review, comments and encouragement.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Scrum project management with IBM Rational Team Concert Version 2, Part 2: Plan and manage sprints