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, ...?
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, ...?
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:
And also:
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:
That added a bit of fun to the process, especially when it came time to name the upcoming iteration.
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.
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,
etc.
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.
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.