Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Some Scrum software management tools give you this option to explicitly name your sprints.

Do you have a preferred way of naming your sprints or do you just use a simple scheme like 1, 2, 3, ...?

share|improve this question

closed as primarily opinion-based by gnat, MichaelT, Dynamic, Giorgio, amon Jan 2 at 8:08

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

6  
Does it matter? As long as you can identify them then that's all that's important. –  ChrisF Jun 9 '11 at 13:35
    
@ChrisF: it can matter, if the name relates to the sprint goal (see Pierre's answer), which is an important tool for promoting clarity and focus on the team. I disagree with closing. –  azheglov Jun 9 '11 at 16:01

9 Answers 9

up vote 16 down vote accepted

Ask the team.

If they think it's fun or useful to name the sprint, choose one together.

Since every sprint should have a goal, it shouldn't be a problem to find a suitable name.

Naming the sprint could actually help the team focusing on the main objective.

I would personally love that kind of thing.

share|improve this answer

At one company where I worked, we had monthly sprints/releases, and we named them alphabetically after internet memes. The releases I worked on recently were:

  • keyboardcat
  • lolcat
  • megashark
  • numanuma

That added a bit of fun to the process, especially when it came time to name the upcoming iteration.

share|improve this answer

If the whole thing is for a specific purpose ("add reporting", "bring in European locations") then there's your name. If it's a collection of things from the backlog, then a vague date ("the June release") works for us. This lets us say to a user "I don't think that wil fit in the June release, is it ok to put it in the next one?" or "if you want that in the June release, we'll need to settle [whatever] by June 5th". They are just labels, but they serve a purpose.

share|improve this answer
1  
A release can have multiple sprints. I think the Foo Release convention is not very appropriate. –  Behrang Jun 9 '11 at 14:53
    
If you need to talk about them on that level of granularity, my first choice would be functionality ("the French stuff") and my second would be 1,2,3 a,b,c or the like within release names. –  Kate Gregory Jun 9 '11 at 15:04

For us we enjoy putting funny names, internally anyway, to our numbered releases and larger projects to break up the monotony a little. We are always looking for funnier/more creative names for our larger projects and releases,however we also obviously use a traditional numbering (1.0, 1.1) or date based system to keep track from a code perspective our best to date is old school rappers. No one says scrum development can't be a bit funny

Ex. Beastie Boys, Coolio, DJ Jazzy Jeff, Eazy-E, Flavor Flav, Etc.

share|improve this answer

On my team, the sprints tend to be named after the production release version we are preparing. In the event of a production release that spans several sprints, we append the iteration number. So, for example,

  • 5.0.2 Iteration 1
  • 5.0.2 Iteration 2
  • 4.16.1

etc.

share|improve this answer
2  
I've run into issues with this before... PHBs who don't really understand are determined that they NEED a certain release such as 4.16.1 (because they heard about it once), even when that has since been superseded by others. I'm tempted to name each one after a species of beetle and leave it at that. Death to PHBs!! –  SHug Jun 9 '11 at 14:58

Dates!

Our process uses a release branch for each sprint we do, so the sprint and release branch names align. We use the planned release date as the name of the branch and sprint.

This makes understanding history a bit easier at the same time -- e.g. if you're looking at an old email about a bug that you thought was fixed, based on the date of the email, you can easily jump to the closest branch name(s) to get a better idea of the change. (Sure, you should hopefully have this tracked in your bug tracker as well / instead, but we all know that's not always the case.)

It's also really nice that our entire team always knows exactly what the name is, so we're always on the same page when referring to a sprint or branch. (There's never any confusion of "Is 'badger' this week's release or last week's?".)

In my opinion, using numbers for the name doesn't really provide any value. For that matter, while it may be fun to do, neither do abstract names. Using goal-oriented names might be a nice addition (e.g. "2012-04-03: Updated customer widgets"), but I wouldn't go back to just using abstract names.

share|improve this answer

I never really thought about naming them. We usually attached a build ID at the end so we could track issues, but naming really isn't part of the process. With releases every two weeks you would burn through 26 names a year.

I suppose this would make it a fun part of sprint planning though. I might have to try it for our next sprint.

share|improve this answer

For each release we choose a big city codename alphabetically (e.g. Atlanta, Boston, Chicago, Dallas ...)

And some college names in that city become our sprint names (Morehouse, Spelman, ..., Harvard, Cambridge etc)

share|improve this answer

After a while thinking about this, I came with the following convention:

<year> CW <starting calendar week> - <ending calendar week>: <goal> (<version>)

Version is optional.

So you end up with something like:

2013 CW 27-28: Improved reporting and dashboards (v1.5.1)
2013 CW 29-30: Redesigned gadgets (v1.5.2)
...

This syntax answers the questions:

  • When was it done?
  • Why was it done?
  • Under what version was it released?

And also:

  • It is sortable
  • It is predictable
  • Allows for flexibility without sacrificing information
share|improve this answer

protected by GlenH7 Dec 31 '13 at 12:50

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.