Agile Product Management
A place for product managers to learn and share tips on working with agile development teams
Question
Parallel Iterations - good or bad?
2486 Views, 8 Comments
Title:
Parallel Iterations - good or bad?
Question:
1. How good or bad is it to implement parallel iterations using Agile?
Comments
Reply to this Comment
Its ok to talk to yourself, I do it all the time, but you only need to worry when you disagree with yourself or worse you answer, "huh?" ;-)
I was looking for the reason why Iterations cannot overlap and I understand that as in the community edition it is designed for one team, but even with one team I can see iterations overlapping as QA members of one team might still be working as the developers begin the next iteration.
Reply to this Comment
Are there any comments on this? I'd like to set up 4 parallel iterations as my teams are in Australia (2), Chile and USA. I find using one iteration to capture all tasks across the teams makes it hard to determine the progress by each team. Ideas are welcome.
Reply to this Comment
Darcy - creating 4 parallel iterations is a good approach to your situation.
In Rally Enterprise, first create your Project Hierarchy with a parent name (such as the product you are working on) and then 4 children (the teams). Here's an example with 3 teams:
The benefits of this approach are:
1. Manage your backlog at the parent level, and then move to the teams during Iteration planning.
2. Create your Release and Iteration time boxes at the Parent level, and check the Bulk Create box to automatically create matching Releases and Iterations for the teams.
3. Get visibility into team progress, as well as roll-up reporting over all 4 teams for your Iteration and Release commitments.
4. If dependencies exist, you can easily mark the predecessor/successor relationships, and regardless of which team owns the dependency, everyone can see it.
Let us know how this works out.
Reply to this Comment
In our situation, we have scrum teams that are working on the new release, but also have responsibilities for maintaining the previous release. Sustaning engineering can't always handle the load. So, how do we handle two parallel releases for the same scrum team?
Do you create both releases in the same project and then just have overlapping iterations within the project? Or is it easier to have to different projects set up for each release. The backlogs will be a little different as we handle both defect and enhancements in our maintenance releases. Same product but different content in each of the backlogs.
Reply to this Comment
Rally has the flexibility to do this many ways. Mark Ortega (dir of Technical Acct Mgmt) suggested this:
1 team works on 2 releases (new and maintenance). In Rally, setup the team as a project and define 1 iteration for the team. Also in Rally, define 2 releases (new and maintenance). Then for the stories for the team in the iteration set the release to the proper one. So Rally supports the stories from one iteration to be part of one to many releases. With this setup, the team has their view of their 1 iteration and 2 releases.
Does that help?
Reply to this Comment
That's how we've set it up. However, when you go to the Plan page to release plan, it get's a little complicated because the iterations overlap. We've had to add our release names in front of our iteration names to tell them apart. Iterations aren't tied to Releases in that view. If we could select the release at the top of the window and have it only show the iterations tied to that release it would be better. Another issues is resource leveling across parallel release that have different iteration schedules. I've started a dialog with Alex P. on this one.
Reply to this Comment
I've tried the method suggested by Dale (with a project for each team, and created iterations at the parent level). The issue seems to be with this approach is each team will see the same iteration backlog & burn down.
Is there any easy way to let each team to have their own sprint backlog & burn down?
Reply to this Comment