How do you name Sprints in Scrum?

Question

I was wondering if it's a good idea to name Sprints with user-friendly names instead of using numerals like Sprint 1, Sprint 2, etc. Are there best practices or standards for naming the Sprint after themes or major milestones for the project?

Answer 1

TL;DR

I was wondering if it's a good idea to name Sprints with user-friendly names instead of using numerals like Sprint 1, Sprint 2, etc.

No, it's not a good idea.

A sprint is a container where Product Backlog items are temporarily stored for a brief duration. A sprint may produce some project artifacts, but the sprint itself has value only as a time-box. Even if you can find a use case for tracking sprints by name, giving sprints non-ordinal labels reduces ease of communication and the amount of information conveyed by the name.

Sprints Are Ephemeral

A sprint is the name the Scrum framework gives to a time-boxed iteration. While each sprint has a defined Sprint Goal, the sprint itself is not a project artifact that needs to be kept for historical records or process improvement.

Sprints often result in various outputs that are relevant to the project such as velocity measurements, finished features, new user stories for the Product Backlog, or process improvements, but the time-box itself has no lasting value once it has expired. Regardless of whether the Sprint Goal was met or not, the old time-box is gone forever and a new time-box for the next sprint replaces it.

Giving code names or handles to a sprint therefore makes little sense, since any given sprint should have no utility as an historical referent. Trying to map ephemeral time-boxes onto named events is usually a project smell that the development model is not truly iterative.

Sprints Aren't Milestones

While each sprint has a Sprint Goal and a set of items peeled off the Product Backlog, neither of these things is necessarily a project milestone. Goals are not always unique items, and stories are sometimes placed back onto the Product Backlog (modified or unmodified) for future sprints. Therefore, there is no guarantee that a sprint is actually unique.

For example, if your current sprint does not meet its Sprint Goal and the Product Owner decides to have another sprint with the same goal, would you name the sprints the same? If not, would "Sprint Fuschia" following "Sprint Aquamarine" really tell anyone anything useful about the sprint, the project, or the team?

In the database world, the problem of (potentially) non-unique rows is generally solved by assigning auto-incrementing primary keys to each row. This is one reason that Scrum generally uses incremented integers rather than code names or handles for labeling sprints.

Projects Evolve; Sprint Labels Shouldn't

In Scrum, the guiding principle is "inspect and adapt." While a project may have a schedule with defined shipping dates, the contents of any given sprint is expected to change over the course of the project. Given that the output of one Sprint impacts the contents of subsequent sprints, it would make no sense to assign meaningful code names to each sprint in the project schedule ahead of time since the goal or stories for the 23rd sprint may change by the time the team gets the first 22 sprints out of the way.

Alternatively, if you use colorful but meaningless names, what value have you added? At least sequential names give you sequence information; if you name your sprints after trees, endangered mammals, or exoplanets, what useful information does that actually convey to anyone?

Since we've already established that sprints are ephemeral and carry no historical significance (other than perhaps as velocity data points), what is it that you might want to communicate about Sprint Koala (which was three sprints ago) to someone else during Sprint Wallaby? Other than as an abstract referent, how will its name add value to the communication?

Unless you are mapping sprint names onto a sequence anyway, and know that Sprint Koala was the 23rd Sprint and that Sprint Wallaby is really the 26th, you can't even convey ordinal or time information without additional cognitive load. That seems like the opposite of "user-friendly" to me.

The Value of Ordinal Information

While the name of the sprint is rarely useful, the number of sprints in the current project plan or the team's current progress along the plan's ordinal axis do provide some utility. For example, a plan with 25 two-week sprints can be estimated to take 50 weeks. Likewise, a project that has less than 30% of the remaining Product Backlog completed after consuming 50% of the planned iterations is quite likely to be out of tolerance.

I don't know how to divide a gaggle of geese by two koalas and a lemur, so I'm pretty sure that these sorts of names provide no value in managing project metrics or even simple percentages. In contrast, assigning ordinal numbers as labels provides for some useful math functions to monitor and communicate about your project, even if the contents of past and future sprints are neither known nor tracked.

Answer 2

Name the Sprint after the Sprint Goal

If you want to name a Sprint, I agree with the accepted answer in the programmers.stackexchange.com thread that you should name it after the Sprint Goal. As the Scrum Master, I keep pushing the Product Owners to come up with a well articulated Sprint Goal. I always start my Sprint Planning sessions by inviting the Product Owner to state the Sprint Goal.

However, coming up with a Sprint Goal is the harder part. Here are some tips from Roman Pichler on how to go about identifying a Sprint Goal. Once you have the Sprint Goal identified you can try and extract a shorter version of it for the Sprint Name.

Answer 3

There are different conventions I've seen used. In my opinion, even having one is completely irrelevant, besides giving you something to refer to in discussions (which may or may not be a good thing!)

1. Use a «Sprint N» or «Iteration N» convention:
   Pro: Easily generated
   Con: Is anyone going to remember what you did in iteration 23? It's almost like not naming them since each sprint already has an ordinal number
   Notable Example: Brackets

2. Use a «Sprint of dd of mmm» template:
   Pro: Easily generated, for some people date anchoring helps them remember in which sprint something was done
   Con: It's almost like not naming them since each sprint already has a starting date
   Notable Example: Not that I can think of, but it seems quite used

3. Give sprints a name based on goal:
   Pro: Makes it trivial to remember when something was done
   Con: Hard to generate, hard to remember (name the first 20 sprints by heart)
   Notable Example: Not that I can think of

4. Any combination of the above

All in all, here's my best advice:

• Don't do it unless you need to: what is the value of doing so?
• If there is a concrete need, let the team discuss the need
• If the team wants to name sprints, let them propose and vote on a convention
• Victory

See also: https://softwareengineering.stackexchange.com/questions/82732/how-do-you-name-sprints-in-your-projects

Answer 4

Not sure how it came to be, but in my last two companies we used the following Sprint naming format: Year+StartWeekNumber+Teamname. Resulting in something like "2016W10 Team Blue" for our current sprint.

But in the last 7 years of doing Scrum I never felt the need to use the Sprint numbers after the sprint was done. Although sometimes it might be handy to see in which time period a feature was developed from in Jira.

Instead of naming a sprint I would define a clear sprint goal and keep the name of the sprint very simple: http://wall-skills.com/2015/sprint-goal-focus-for-the-scrum-team/

Answer 5

I have a slightly different take on this. Our team has evolved an approach (branching model, organisational structure, overall approach) which allows us to run multiple sprints in parallel - this is especially useful for ensuring high utilisation, so nobody is sat idle waiting for QA to finish their task.

The downside is, at any given point, we don't know which sprint will go out first, thus date-based, or ordinal naming is useless.

Thus we went for the 'colourful but meaningless' approach and named our sprints after moons in the solar system (there are quite a lot!). The names themselves don't convey anything, but its a very useful way to be able to talk about a collection of features, enhancements and fixes in a way that everyone involved can relate to. I take issue with the assertion that your sprint name HAS to mean something - in our case its simply a logical grouping.

We've ran with this system for over two years, over something like fifty point releases, and it works very, very well.

For example, we currently have sprints 'Phoebe' and 'Ceres' in development - the project plan calls for Phoebe to become the next point release (1.80.0) but there are no guarantees, and we remain agile enough to change the planned order of releases, with minimal impact on delivery. Thus we may find problems with Phoebe in the QA cycle that delays it, and Ceres will go out as 1.80.0, and Phoebe will (probably!) become 1.81.0.

Answer 6

To echo CodeGnome a little, I would also say that naming sprints is a bad idea. They are ephemeral. Once a sprint has completed you may wish to gather the completed stories into a record for later use in completing user documentation, but aside from that there is nothing to be gained from remembering any particular sprint, and naming them would give them too much significance.

What may work more effectively and be a better focus for your team is to look at the goals of the release that the sprint is part of and keep those goals in mind. Having a release name is a time-honored tradition since before agile methods. It forgoes tying the stories of any one sprint to any significance, however it does emphasize that all the stories in the backlog for the release are necessary before declaring victory.

Answer 7

I use "Sprint N: Sprint Goal", restarting the count after every release.

In practice, we often use only the number, but the number+goal is helpful when reporting over a longer scale, or looking back over the past few months to see where we've put our effort when prioritizing for future sprints.

Answer 8

Though there is no right or wrong answer to this question, I have found it useful to use the last day of the sprint as the unique identifier for the sprint name.

As as example, if a sprint ends on 03/28/2016, I would name the sprint as: Sprint 20160328

I have found that this works very well for the purposes of: (1) giving the sprint a name that provides useful information about the sprint rather then some arbitrary number (2) using a date ensures uniqueness within the context of an individual project

Note: I never coach embedding elements of the program or project name in the sprint name itself. Topologically, it's cleaner to let the project and/or program exist at a level well above the work time box label.

Answer 9

If you have project divided into Milestones (1,2 ...5), you can name the Sprints inside each milestone to correspond to Milestone your are working on and the # of sprint in that Milestone.

For example if you are working on Milestone 1 - your sprints can be named Sprint 1.1 ; Sprint 1.2; for Milestone 2 - Sprint 2.1; Sprint 2.2

This way you have a reference point to a Milestone and functionality executed.

Answer 10

I advise not to fret over such small details. The idea of SCRUM is to reduce waste and be agile. Find a simpler way and stick to it. I use the following format so that I do not have to think about naming.

Sprint X - From to To

where

• X - Sprint number (e.g. 15)
• From - Short start date (e.g. 19 Mar)
• To - Short end date (e.g. 2 May)

Answer 11

The name of the Sprint doesn't have any impact on or make any difference to your process. But it is recommended to use numbers such as Sprint 1, Sprint 2, etc. for ease of tracking.

For a large project you may have 30 or 40 sprints. In that case it will be difficult to identify the sprints if you give them fancy names. So its better to name using numbers (Sprint 1, Sprint 2, etc.).

Answer 12

I work with diferent teams and we have parallel sprints for different apps. It turned really hard to differentiate several Sprints with differents numbers.

So we implemented the following structure to our Sprint names:

< Sprint > < Year > < Month > < (Version) >

The "(Version)" is optional because even if we do monthly sprints we do a Release every 3 Months. In this case 3 Sprints might belong to one Release.

If it would help, you could also use the Sprint Goal or product name. I don't use the goal or product name because my Sprints belong to a product and that's already mapped in the system.

Answer 13

We just started new sprint naming type that looks like 'YYYY-QX-X/6'.

2018-Q4-5/6.

We are setting quarterly team goals. This naming type makes feel a deadline.

Answer 14

I think a "common name" in parens behind whatever non-memorable number system you use is fine and beneficial, if not fun. They could even correlate to the number. before: 2021W31 after: 2021W31(Reggie)

Answer 15

Do not name the sprints in Scrum, it is pointless!

What's the value in doing so? NONE Is the Scrum guide recommending it or somewhat suggesting it? NO Is it part of any artifact? NO

Sprints have names because bloody Jira added that functionality, but certainly and to avoid confusion, the sprint name must be autogenerated, 1, 2, 3, etc...

The important information about the sprint is already part of it and once is finished, that information still persisted, like the goal, length, start date, end date, etc...

If I want to find a sprint I would do it either by starting date or goal. Ultimately, we can check a task of which, the sprint interest us and check the Sprints field (in Jira), and you can find it...

Neither the Product owner, the scrum master nor the developers, anyone cares about the name of the Sprint... ONLY JIRA DOES!