How to handle staggered sprints across teams in same release
I have a question on "best practice" for setting up the project timelines in my situation. Each release has several sub-teams. Unlike the RTC dev team where it seems all teams have the same sprint schedule, these sub-teams work in different sprint schedules and have staggered end dates. It is not ideal, but it is what it is.
I have created a team hierarchy as follows:
Product
> Release 2.0 Team
-> Team A
-> Team B
...
This seems straight forward, but I'm unsure if the way I am structuring the timeline is optimial, please advise.
Mainline Development
> Release 2.0
-> Team A
--> Team A Sprint 1
--> Team A Sprint 2
-> Team B
--> Team B Sprint 1
--> Team B Sprint 2
> General Product Backlog
...
It seems only one iteration can be marked "current" iteration within a timeline. This is not a show stopper, but a bit akward and makes me feel like I am not setting things up in the way RTC developers intended it to be.
Of course, we then create a plan for each team's "Release Backlog" and various "Sprint Backlog" plans associated with the applicable timelines for each team.
Is there a better way to allow each team within a release to have independent sprint schedules?
I have created a team hierarchy as follows:
Product
> Release 2.0 Team
-> Team A
-> Team B
...
This seems straight forward, but I'm unsure if the way I am structuring the timeline is optimial, please advise.
Mainline Development
> Release 2.0
-> Team A
--> Team A Sprint 1
--> Team A Sprint 2
-> Team B
--> Team B Sprint 1
--> Team B Sprint 2
> General Product Backlog
...
It seems only one iteration can be marked "current" iteration within a timeline. This is not a show stopper, but a bit akward and makes me feel like I am not setting things up in the way RTC developers intended it to be.
Of course, we then create a plan for each team's "Release Backlog" and various "Sprint Backlog" plans associated with the applicable timelines for each team.
Is there a better way to allow each team within a release to have independent sprint schedules?
3 answers
The natural way to do this is to create separate timelines for each
schedule. Then each schedule can have its own "current" iteration.
One downside is that currently, a given team area can only be associated
with at most one timeline ... so if a team works on multiple timelines,
you have to duplicate the team area for each timeline that team needs to
work on. Note: work item 99436 requests allowing a team area to be
associated with multiple timelines for planning purposes ... feel free
to add a comment to that work item if you are interested in this
enhancement.
Another downside is that the agile planning views can only be applied to
a single top level iteration. So you can't get an agile planning view
across two iterations if they are in different timelines. Work item
94056 requests that you be able to do so ... as above, feel free to add
a comment to indicate interest/support.
But if in your case, a given team usually just works on a single
schedule, and that you primarily do your planning in the context of a
single timeline, then having a separate timeline for each schedule is
probably the way to go.
Cheers,
Geoff
On 8/7/2010 11:23 AM, jleone wrote:
schedule. Then each schedule can have its own "current" iteration.
One downside is that currently, a given team area can only be associated
with at most one timeline ... so if a team works on multiple timelines,
you have to duplicate the team area for each timeline that team needs to
work on. Note: work item 99436 requests allowing a team area to be
associated with multiple timelines for planning purposes ... feel free
to add a comment to that work item if you are interested in this
enhancement.
Another downside is that the agile planning views can only be applied to
a single top level iteration. So you can't get an agile planning view
across two iterations if they are in different timelines. Work item
94056 requests that you be able to do so ... as above, feel free to add
a comment to indicate interest/support.
But if in your case, a given team usually just works on a single
schedule, and that you primarily do your planning in the context of a
single timeline, then having a separate timeline for each schedule is
probably the way to go.
Cheers,
Geoff
On 8/7/2010 11:23 AM, jleone wrote:
I have a question on "best practice" for setting up the
project timelines in my situation. Each release has several
sub-teams. Unlike the RTC dev team where it seems all teams have the
same sprint schedule, these sub-teams work in different sprint
schedules and have staggered end dates. It is not ideal, but it is
what it is.
I have created a team hierarchy as follows:
Product
Release 2.0 Team
-> Team A
-> Team B
..
This seems straight forward, but I'm unsure if the way I am
structuring the timeline is optimial, please advise.
Mainline Development
Release 2.0
-> Team A
--> Team A Sprint 1
--> Team A Sprint 2
-> Team B
--> Team B Sprint 1
--> Team B Sprint 2
General Product Backlog
..
It seems only one iteration can be marked "current"
iteration within a timeline. This is not a show stopper, but a bit
akward and makes me feel like I am not setting things up in the way
RTC developers intended it to be.
Of course, we then create a plan for each team's "Release
Backlog" and various "Sprint Backlog" plans associated
with the applicable timelines for each team.
Is there a better way to allow each team within a release to have
independent sprint schedules?
If I understand you correctly, you are proposing we create a timeline for each team and organize the sprints directly beneath the timeline.
Something like this, correct?
Team A Timeline
> Team A Sprint 1
> Team A Sprint 2
...
> Team A Backlog
Team B Timeline
> Team B Sprint 1
> Team B Sprint 2
> Team B Backlog
Is my understanding correct? If so, which timeline should be considered the "Project Timeline" since only one timeline can have that title.
PS. I looked around and could not find anything that clarified what a "Project Timeline" is it's significance in the big picture so if you know that, I would love to hear.
Something like this, correct?
Team A Timeline
> Team A Sprint 1
> Team A Sprint 2
...
> Team A Backlog
Team B Timeline
> Team B Sprint 1
> Team B Sprint 2
> Team B Backlog
Is my understanding correct? If so, which timeline should be considered the "Project Timeline" since only one timeline can have that title.
PS. I looked around and could not find anything that clarified what a "Project Timeline" is it's significance in the big picture so if you know that, I would love to hear.
Correct.
Cheers,
Geoff
On 8/12/2010 2:07 PM, jleone wrote:
Cheers,
Geoff
On 8/12/2010 2:07 PM, jleone wrote:
If I understand you correctly, you are proposing we create a timeline
for each team and organize the sprints directly beneath the
timeline.
Something like this, correct?
Team A Timeline
Team A Sprint 1
Team A Sprint 2
..
Team A Backlog
Team B Timeline
Team B Sprint 1
Team B Sprint 2
Team B Backlog
Is my understanding correct?