Iteration naming conventions in Rally

[Anon Anon]

What's your preferred iteration naming convention in Rally?

We've been doing "Sprint 1", "Sprint 2", "Sprint 3" and then resetting each release back to 1, but this breaks down when we start working on two releases at once, with the last few sprints of one release overlapping the first few of the next release.

I'm treating the iteration as a calendar-based itmebox, not really tied to a release. Maybe just call it "Sprint ending Aug-19-2015"?

[SeshVeeraraghavan1363555]

Different teams use slightly different conventions. The easiest one is <Release Name><Iteration #>.
One of our teams uses country capitals as release names, so their iteration names are, for example, Athens 1, Athens 2 and so on. Other teams use release id for releases, followed by iteration number (e.g. 2015_R1 1, 2015_R1 2 and so on).

It really depends on your project structure, too; for proper data roll up it's best to name releases and iterations the same from the parent project on to child projects and such so that the child projects are inheriting the names from the common parent.

[Anon Anon]

So how would your sprint look when it covers two releases? Would you use two separate sprints, under two separate projects? (eg a new project per release?)  Or is it possible to have two iterations using the same calendar timebox (the same two week period), one for each release?

[SeshVeeraraghavan1363555]

All releases for a project always come under that specific project because projects typically represent teams. We don't disturb our teams, so that means our projects are almost always static in nature.

The iterations and releases are created under the project and as you know there is no direct relationship between iteration and release objects, but they are bridged by work items like stories, defects etc.

Depending on how the stories are delivered you want to ensure the releases and iterations ideally remain independent and non-overlapping. That means creating a new set of iterations corresponding to the timebox of the new release and letting the old set of iterations exist with the old release. Rally won't let you have iterations that have the exact same start and stop dates under a project but they can overlap. Releases, of course, can have the same start and end dates under a project.

In your situation, though, you want to have the same iteration at the overlapping period for both releases because they do match the start and end dates and then the iterations start "pulling away" towards the new release completely.

Essentially:
R1 I1
R1 I2
R1 I3
R1, R2, I4
R1, R2, I5
<release R1 ends>
R2, I6
R2, I7

where stories and defects etc. in iterations 4 and 5 have the same iteration value (i.e. they're in the same iteration) but with different release values.

Does that help?

[Anon Anon]

Yes, that "Essentially" is nearly exactly our situation, except out of habit (and to avoid Sprint 123 a few years down the road) we've reset the iteration number each release. We've tried this approach, but it doesn't work so well:

R1 I1 = "Sprint 1"
R1 I2 = "Sprint 2"
R1 I3 = "Sprint 3"
R1, R2, I4 = "Sprint 4" or instead "Sprint 1 (R2)" - neither is a good choice :-/
R1, R2, I5 = "Sprint 5" or instead "Sprint 2 (R2)" - neither is a good choice :-/
<release R1 ends>
R2, I6 = "Sprint 6" or instead "Sprint 3 (R2)"...

I think our first answer is to stop quoting the Release inside the Iteration name. Second answer may be to stop resetting iteration numbers every release, or alternatively just start including the relevant date (eg "Sprint 2015-08-18" for the sprint ending on Aug 18th).

[Anon Anon]

Hi James,

If you are dealing with several releases at a time then forget about Rs in sprint names. Actually it doesn't matter how would you call the timebox. The only "nice to have" point is to associate the sprint name with the sprint goal. On the planning meeting think of a general term that describes the planned scope. And then during the sprint you will look at this label and remind the goal to yourselves.

Regards,
Max