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, ...?

  • 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

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.


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

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.

  • :D This is great! – Anoop.P.A Jul 16 '18 at 8:04

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.

  • 2
    A release can have multiple sprints. I think the Foo Release convention is not very appropriate. – βξhrαng 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.


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


  • 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


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.


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)


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.

  • Since this got some recent attention. While at a job after I posted this we did name the sprint, the theme of the name went with the sprint number. I think it had something to do with our tracking software allowing for this. We dropped the naming when we moved to JIRA – Bill Leeper Jan 31 '18 at 21:55

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