It's all about the answers!

Ask a question

How does Rational plan?


Tony DeFarlo (1262314) | asked Dec 04 '10, 7:55 a.m.
I'd be interested in guidance from Rational around your experience using RTC as a planning tool. Of course work items are placed in releases and iterations, but often at the end of an iteration/release there will be work items that have been started but not yet completed. I am trying to determine what the best practice would be:

1) Simply move the work item to next iteration?
2) Close the work items and create new ones in the next iteration?

Option 2 may have a lot of overhead associated with it. But if option 1 is used then the progress indicators seem to be misleading. In other words say Iteration 1 had 200 hours of estimated work, but only 100 hours was done. The progress bar is half green and half red. Clearly we failed. Now I start moving work items. My progress bar for the former iteration now starts looking much better and ultimately goes completely green as it shows I did all the work expected, since the other work not completed has been moved out to the next iteration. Not only that, the next iteration shows that I am ahead of schedule, since work done in the previous iteration is considered work done in the current iteration so the progress bar on day one says I am ahead by 100 hours....

I would have a lot of resistance if I forced managers to undertake the overhead of option 2. So it seems as if we would explain option 1 this way:

- progress bars for a historical release/iteration cannot be used to understand how well the team performed. Reports from the data warehouse must be used for this purpose.

- progress bars for the current iteration, early in the iteration, will be misleading as they will overstate progress, but this should level out over time.

Or am I missing an alternative?

Any feedback will be appreciated....

3 answers



permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 04 '10, 9:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
We use a variant of option 1. In particular, if no work has been
started on a task, we just move it to backlog (usually not to the next
iteration ... that happens during the planning phase of the next
iteration). But note that this is not a common operation. We are
conservative WRT the number of tasks that we schedule for a given
iteration, so there is room in the schedule for expected "unexpected"
tasks. If a given task already has work done on it, we do not just
move it to the next iteration (that would be inaccurate for several
reasons) ... we use the "continue" operation to create a new work item
(which automatically links the new task it to the existing task, and
closes the existing task).

Note that this schedule adjustment should be an incremental operation,
and should be performed whenever your schedule goes red ... so at the
end of the iteration, there should not be no extra tasks that need to be
continued or placed into backlog ... that should have been done well
before you reached the end of the iteration.

Cheers,
Geoff

On 12/4/2010 8:08 AM, adefarlo wrote:
I'd be interested in guidance from Rational around your experience
using RTC as a planning tool. Of course work items are placed in
releases and iterations, but often at the end of an iteration/release
there will be work items that have been started but not yet completed.
I am trying to determine what the best practice would be:

1) Simply move the work item to next iteration?
2) Close the work items and create new ones in the next iteration?

Option 2 may have a lot of overhead associated with it. But if option
1 is used then the progress indicators seem to be misleading. In
other words say Iteration 1 had 200 hours of estimated work, but only
100 hours was done. The progress bar is half green and half red.
Clearly we failed. Now I start moving work items. My progress bar for
the former iteration now starts looking much better and ultimately
goes completely green as it shows I did all the work expected, since
the other work not completed has been moved out to the next
iteration. Not only that, the next iteration shows that I am ahead of
schedule, since work done in the previous iteration is considered work
done in the current iteration so the progress bar on day one says I am
ahead by 100 hours....

I would have a lot of resistance if I forced managers to undertake the
overhead of option 2. So it seems as if we would explain option 1 this
way:

- progress bars for a historical release/iteration cannot be used to
understand how well the team performed. Reports from the data
warehouse must be used for this purpose.

- progress bars for the current iteration, early in the iteration,
will be misleading as they will overstate progress, but this should
level out over time.

Or am I missing an alternative?

Any feedback will be appreciated....

permanent link
Tony DeFarlo (1262314) | answered Dec 04 '10, 10:31 a.m.
Thanks for the response. I was unaware of the continue operation. Is this available in 2.0? Web?

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 04 '10, 2:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I believe the continue operation is only available through the Eclipse
client (in the Plan editor). With the Web client, you probably have to
do it by hand, i.e. create a new work item, copy the summary over, add a
"related" link between the two work items.

But to emphasize the point made in the previous posting, being unable to
finish a task that you've already started should be an infrequent
operation, and requiring a few extra keystrokes when you encounter this
case should not be an issue. (Moving a non-started task to another
iteration, commonly the Backlog iteration, is a single gesture in the
WebUI).

Cheers,
Geoff

On 12/4/2010 10:38 AM, adefarlo wrote:
Thanks for the response. I was unaware of the continue operation. Is
this available in 2.0? Web?

Your answer


Register or to post your answer.