bltjazz wrote:

I am using RTC 2.0. We have a Project Area using the Scrum template.

I have two timelines in this project area, one called Main ( the
'default' ) and created a second called 'GP'.

Main has a Release 1.0 Iteration and under it 3 iterations called I1,
I2, I3.

GP has a 'Prelim' iteration and under that a 'Prelim_1' iteration.

I would like to create an iteration plan for Prelim_1.

In TeamArtifacts, under Plans for my PA, I expand GP, Prelim,
Prelim_1, and create a New Plan for Prelim_1. Plan type is
'Iteration Plan', and it fills in PA and Timeline and Iteration
correctly if I choose "Team Members" as Project Area.

If, however, I choose "Team Members" as 'Team Area', it
fills in the PA okay, the browse allows me to choose a team
(PA/GP_rels/GP1.0) but the ONLY iterations it allows me to choose for
those set up for the "Main" line. --- The browse does
NOT allow me to choose the Iteration from which I did the
right-clicked->New Plan... that is, it only allows me to choose
from I1, I2, I3 but NOT Prelim_1

It is not clear to me what I might have done wrong in setting this
up.

Can you ensure that the Prelim_1 iteration is marked as producing a
deliverable. We allow to create plan for such iterations only.

--
Cheers, Johannes
Agile Planning Team

If you are using RTC-2.0 and using the Eclipse client, just open that
team area in the team area editor, and click on "Browse" in the Timeline
section(upper right). That will let you set the timeline of the team
area to any of the defined timelines.

Cheers,
Geoff

bltjazz wrote:

It is as though I've got my Team Area aligned with the wrong timeline.
(When I open the Team Area and look at the 'timeline' entry)

However, I don't see anyway to change the 'timeline' associated with a
Team Area.

OTOH in Process Area . Process Configuration I see something like

Timelines
GP
Prelim
Prelim_1
Main
Release 1.0
I1
I2
I3

so it looks like to me the timeline s/b correct.

Maybe I need to delete and re-create all the team areas from scratch
?


bltjazzwrote:
I am using RTC 2.0. We have a Project Area using the Scrum
template.
I have two timelines in this project area, one called Main ( the
'default' ) and created a second called 'GP'.
Main has a Release 1.0 Iteration and under it 3 iterations called
I1, I2, I3.
GP has a 'Prelim' iteration and under that a 'Prelim_1' iteration.

I would like to create an iteration plan for Prelim_1.

In TeamArtifacts, under Plans for my PA, I expand GP, Prelim,
Prelim_1, and create a New Plan for Prelim_1. Plan type is
'Iteration Plan', and it fills in PA and Timeline and Iteration
correctly if I choose "Team Members" as Project Area.
If, however, I choose "Team Members" as 'Team Area', it
fills in the PA okay, the browse allows me to choose a team
(PA/GP_rels/GP1.0) but the ONLY iterations it allows me to choose for
those set up for the "Main" line. --- The browse does
NOT allow me to choose the Iteration from which I did the
right-clicked->New Plan... that is, it only allows me to choose
from I1, I2, I3 but NOT Prelim_1
It is not clear to me what I might have done wrong in setting this
up.
Any help would be greatly appreciated.


Brian

I've submitted work item 90689 asking that a team area be allowed to
select its timeline, even if is the child of another team area (or have
the reason for the constraint explained :-).

Cheers,
Geoff

bltjazz wrote:

I'm using Version: 2.0 Build id: I20090618-1753 according to the
eclipse client.

Unless I'm missing something (I'm finally figuring out) the catch
seems to be that the "root" Team Area forces all offspring
to use the same timeline.

Thus my Project Area _cannot_ have a child called
"FortranReleases" and have its children (Fortran66,
Fortran77,Fortran90, etc. ) have different timelines. All of 'em,
66..90, must share the same timeline even tho they are decades apart.


Grumble.

Are there any good reasons why this (timelines need not be fixed at
the root Team Area) cannot be an enhancement ( or in my mind a fix
:-) ?

Many thanks.


gmclemmwrote:
If you are using RTC-2.0 and using the Eclipse client, just open that

team area in the team area editor, and click on "Browse"
in the Timeline
section(upper right). That will let you set the timeline of the
team
area to any of the defined timelines.

Cheers,
Geoff

bltjazz wrote:
It is as though I've got my Team Area aligned with the wrong
timeline.
(When I open the Team Area and look at the 'timeline' entry)

However, I don't see anyway to change the 'timeline' associated with
a
Team Area.

OTOH in Process Area . Process Configuration I see something like

Timelines
GP
Prelim
Prelim_1
Main
Release 1.0
I1
I2
I3

so it looks like to me the timeline s/b correct.

Maybe I need to delete and re-create all the team areas from
scratch
?


bltjazzwrote:
I am using RTC 2.0. We have a Project Area using the Scrum
template.
I have two timelines in this project area, one called Main ( the
'default' ) and created a second called 'GP'.
Main has a Release 1.0 Iteration and under it 3 iterations called
I1, I2, I3.
GP has a 'Prelim' iteration and under that a 'Prelim_1' iteration.

I would like to create an iteration plan for Prelim_1.

In TeamArtifacts, under Plans for my PA, I expand GP, Prelim,
Prelim_1, and create a New Plan for Prelim_1. Plan type is
'Iteration Plan', and it fills in PA and Timeline and Iteration
correctly if I choose "Team Members" as Project Area.
If, however, I choose "Team Members" as 'Team Area', it
fills in the PA okay, the browse allows me to choose a team
(PA/GP_rels/GP1.0) but the ONLY iterations it allows me to choose
for
those set up for the "Main" line. --- The browse
does
NOT allow me to choose the Iteration from which I did the
right-clicked->New Plan... that is, it only allows me to choose
from I1, I2, I3 but NOT Prelim_1
It is not clear to me what I might have done wrong in setting this
up.
Any help would be greatly appreciated.


Brian

On Wed, 19 Aug 2009 18:37:59 +0000, bltjazz wrote:

Unless I'm missing something (I'm finally figuring out) the catch seems
to be that the "root" Team Area forces all offspring to use the same
timeline.

Thus my Project Area _cannot_ have a child called "FortranReleases" and
have its children (Fortran66, Fortran77,Fortran90, etc. ) have different
timelines. All of 'em, 66..90, must share the same timeline even tho
they are decades apart.

Hi, Brian.

Our model is that you've got a project which can have one or more
timelines and each of those timelines can have a hierarchy of teams which
work in that timeline. The model as it stands today already causes a lot
of confusion for users; if we were to remove this structure and turn the
hierarchy into a free-floating soup of teams and timelines, the state of
system would be impossible to ever comprehend (much less manipulate).

It is not yet represented in the tools, but I now prefer to think of our
current model in terms of projects and sub-projects. If you'll indulge me
for a moment, here's the story that prefer now. In the end, I think it
makes it easier to understand our current model:

Forget the current implementation (in particular, forget timelines and
root team areas). Imagine that we have project areas with a start and end
date along with an optional iteration breakdown and a hierarchy of team
areas. Next, imagine that you can create sub-projects under the project
area. Each sub-project can have its own start and end date along with an
iteration breakdown and team area hierarchy. Sub-projects would inherit
the process of their parent including workitem configuration and
categories, but they'd be able to customize the permissions and
preconditions.

I think this story is much easier to grok than our current story with the
project timeline, "secondary timelines", and root team areas and I'm
hopeful that this is where we'll be by next year. In the meantime,
though, this story is a good way to understand our current model - you
just have to squint a little to see it. The simple project area in the
story is the same as our current project area plus the project timeline
and all team areas which belong to the project timeline. The sub-projects
in the story are the same as our current combination of root team areas
and the timelines they're assigned to.

For me, our current model makes more sense when I think about it in terms
of project and sub-projects. I hope it's not just confusing to everyone
else. :)

--
Jared Burns
Jazz Process Team

Hi Jared,

I haven't thought it through, but here what I ran into today:

https://jazz.net/forums/viewtopic.php?t=6385

The requirement would be to to sort of have the ability to run a team hierarchy against several timelines. There might be a way to construct virtual teams for each timiline automatically. However at least this customer would be better off having a complete view on all the teams work and be able to also have a seperate view on certain aspects.

Thanks,

Ralph

Hi Jared,

I believe the main problem is that currently both process inheritance
and timeline inheritance is tied to a single project/team hierarchy, and
so anything that forces you to put a team in a different hierarchy means
you cannot inherit the process. I believe that the simplification that
you describe below is good, but only if "process inheritance" is
separated from "timeline inheritance", i.e. if a team area can specify
its "timeline parent" separately from its "process parent".

I've submitted workitem 90830 for this thread. And if that's already
what the process team has in mind, I'm good with that (:-).

Cheers,
Geoff

Jared Burns wrote:

On Wed, 19 Aug 2009 18:37:59 +0000, bltjazz wrote:

Unless I'm missing something (I'm finally figuring out) the catch seems
to be that the "root" Team Area forces all offspring to use the same
timeline.

Thus my Project Area _cannot_ have a child called "FortranReleases" and
have its children (Fortran66, Fortran77,Fortran90, etc. ) have different
timelines. All of 'em, 66..90, must share the same timeline even tho
they are decades apart.

Hi, Brian.

Our model is that you've got a project which can have one or more
timelines and each of those timelines can have a hierarchy of teams which
work in that timeline. The model as it stands today already causes a lot
of confusion for users; if we were to remove this structure and turn the
hierarchy into a free-floating soup of teams and timelines, the state of
system would be impossible to ever comprehend (much less manipulate).

It is not yet represented in the tools, but I now prefer to think of our
current model in terms of projects and sub-projects. If you'll indulge me
for a moment, here's the story that prefer now. In the end, I think it
makes it easier to understand our current model:

Forget the current implementation (in particular, forget timelines and
root team areas). Imagine that we have project areas with a start and end
date along with an optional iteration breakdown and a hierarchy of team
areas. Next, imagine that you can create sub-projects under the project
area. Each sub-project can have its own start and end date along with an
iteration breakdown and team area hierarchy. Sub-projects would inherit
the process of their parent including workitem configuration and
categories, but they'd be able to customize the permissions and
preconditions.

I think this story is much easier to grok than our current story with the
project timeline, "secondary timelines", and root team areas and I'm
hopeful that this is where we'll be by next year. In the meantime,
though, this story is a good way to understand our current model - you
just have to squint a little to see it. The simple project area in the
story is the same as our current project area plus the project timeline
and all team areas which belong to the project timeline. The sub-projects
in the story are the same as our current combination of root team areas
and the timelines they're assigned to.

For me, our current model makes more sense when I think about it in terms
of project and sub-projects. I hope it's not just confusing to everyone
else. :)