Work Allocation and Planning – The William and Kate OpenUP Story

Christophe Lucas, IBM
Last updated: September 01, 2011
Build basis: Rational Team Concert 3.0.1

This article describes how Work Allocation and the Agile Scheduler interact in Rational Team Concert 3.0.1.

Using an OpenUP-based Project Area with 8 Tasks and 2 Team Members (Kate and William), we will show how the Agile Scheduler behaves by going through the 6 following Use Cases:

UC1: Kate is allocated 100%, 1 Task of 1 day
UC2: Kate is allocated 100%, 8 Tasks of 1 day
UC3: Kate is allocated 50%, 8 Tasks of 1 day
UC4: Kate and William are allocated 100%, 4 Tasks of 1 day each
UC5: Kate and William are allocated 25%, 4 Tasks of 1 day each
UC6: Kate is allocated 5% and William 100%, 4 Tasks of 1 day each

By detailing each Use Case, we plan to show how changing Team Members Work Allocation:

directly impacts the way the Agile Scheduler calculates the Schedule.
directly impacts Plan Load bars, and implies changes in the planned End Dates of both the individual work items and of the overall Iteration – changes which can be captured using Planned Snapshot.

Setup

This article’s sample scenario uses a straightforward OpenUP-based Project Area and is very easy to setup:

Click File – New Project Area, select OpenUP Process template. Add yourself as Project Area member with Project Manager role. Note that 8 Tasks are automatically created on Project setup, and appear in the Work Items view.
In the Team Organization view, double-click the automatically created Team Area and create members Kate and William.
click Create New Plan, select Iteration Plan Plan type, select Inception Iteration I1 for the Iteration, and the Team Area as owner.

In this example, the current Inception Iteration 1 Start and End Dates were set to July 05 and August 04. The exercise was done on July 05.

Overview

Use Case 1: Kate is allocated 100%, 1 Task of 1 day

In the Eclipse Work Items view, select the ‘Define an Iteration Plan’ Task, and drag-drop it on the Plan under Kate’s section. Switch to the Web UI, and set the Task Effective Estimate to 1 day, using the Planned Time view.

Note that the Plan Load bar displays 8 hours of work as expected. Because Kate is assigned 100% to this Timeline, the Scheduler calculates that the Task should be finished tomorrow, i.e. on July 06.

UC1

Take a Regular Snapshot at this stage, so you will be able to compare it later on.

UC1_Snapshot

Use Case 2: Kate is allocated 100%, 8 Tasks of 1 day

In the Eclipse Work Items view, select the 7 remaining Tasks, and drag-drop them on the Plan under Kate’s section. Using the Web UI, set every Task’s Effective Estimate to 1 day. Observe how the Scheduler orders and schedules the 8 Tasks, one after the other, and how it calculated that the Iteration work should be finished on July 15.

Note: The Planned Time view is the place where you can change the sequencing of your Tasks, by just drag-dropping them – first on top is the first scheduled. Another place where you can change this sequencing is the Eclipse My Work view – and the change happening in My Work view will be reflected in the Planned Time Plan view, and vice-versa.

UC2

Now, take a Planned Snapshot, and compare it with the UC1 Regular Snapshot. Note that the Scheduler (1) has set the Planned End Date for the Iteration to July 15 (vs. July 06 in UC1 Snapshot), (2) has set a Planned End Date on every Task. Note that the Work Estimated and Progress have also changed.

UC2_UC1_SnapshotCompare

Use Case 3: Kate is allocated 50%, 8 Tasks of 1 day

Go to Kate’s Work Allocation, and change Kate’s allocation to this Project’s Timeline from 100% to 50%. Observe that as a result of this allocation change, all Tasks “time width” are changed (from 1 to 2 days long), and the Iteration Schedule ‘shifts right’ overall – the Scheduler now calculated that the Iteration work should be finished on July 27. The Plan Load bars also reflect this allocation change (e.g. 84 h vs. 168 h in UC2 available for Kate). Note that at this time, the Tasks Planned End Date did not change: they are still the ones set by the UC2 Planned Snapshot.

UC3

Use Case 4: Kate and William are allocated 100%, 4 Tasks of 1 day each

We are now going to set Kate’s Work Allocation back to 100%, then drag-drop the 4 last Tasks of Kate to William’s section on the Plan. You can observe that the Agile Scheduler re-scheduled the 4 last Tasks work. The Iteration work is now planned to be finished on July 11.

UC4

Use Case 5: Kate and William are allocated 25%, 4 Tasks of 1 day each

Both Kate and William’s Work Allocations have now been reduced to 25%, i.e. they are available less than 1 day per week for this Project. You can observe that each Task “time width” is considerably changed (1 day of work now expands to a 4 days duration) and that the Iteration work Planned End Date has now shifted to July 27. The Plan is still green, however, as can be seen in the Plan overall Load bar, there are now only 84 work hours available left before the end of the Iteration (vs. 336 hours in UC4).

UC5

Use Case 6: Kate is allocated 5% and William 100%, 4 Tasks of 1 day each

We degraded Kate’s allocation to as little as 5% (meaning she can only work a couple hours per week on this Project), while we set William’s allocation back to 100%. Now our Plan hits a problem!

William’s work schedule is the same as in UC4 when he was 100% – his work is still planned to be finished on July 11. Kate’s schedule has drastically changed: each Task’s duration is now almost 1 month, and her last scheduled Task is only planned to be completed on October 25! As Kate’s red Load bar shows, Kate is now lacking 23.75 hours of availibility to have a chance to complete the work before the Iteration deadline. Also, her 3 last Tasks are now marked with Plan warning messages indicating that, considering her very low work allocation, the work items will only be completed after the Iteration end date.

UC6

Complementary notes on Ranking, Sequencing, Scheduling and Agile vs. Traditional Scheduler

Ordering of work items on Plans can be done in 2 ways in RTC: through Ranking or through Sequencing.

Ranking is two-staged: the primary Rank value is the priority (but can be customized), the secondary Rank value is internally stored wihin the work item. The secondary Rank value is reset when the primary value changes. Ranking is available in Plans: Sorting –> Ranking.

Sequencing is only available in Agile processes. Sequencing defines the order in which developers work on certain tasks, and implements simple constraints and dependencies. Sequencing is available in Plans: Sorting –> Planned Time.

With RTC 3.0, a new Formal Project Management Process template was introduced, which uses the so-called Traditional Scheduler. All other Process Templates available out-of-the-box come with another scheduler called the Agile Scheduler.

Depending on which Scheduler is used, different orders take precedence and the Schedule displayed by the Plan views varies:

With the Agile Scheduler: first the sequence, if sequence not set the ranking, if ranking not set the work item number.
With the Traditional Scheduler: first Schedule Constraints and Dependencies, if not specified the ranking.

In OpenUP-based Project Areas, the Plans of type Iteration Plan come with several views, most of which are sorted by Ranking – only the Planned Time view is sorted by Planned Time.

PlansView

About the author

Christophe Lucas is an IBM Rational Client Technical Professional and loves Jazz in action – with a special preference for RTC 3.Next and Miles Davis. You can contact him at christophe_lucas@be.ibm.com.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Feedback

Was this information helpful?

Yes

No 24 people rated this as helpful.