Sprints as a Number or a Named Instance ?

Do you call your sprints as sprint 1, 2, ... or do you assign names to your sprint ?

This post shares my experiences and thoughts based on the various views that I have encountered with my teams.

1. Numbered Sprints are a great motivator. When you start saying Sprint 5, 9, 15, it really gives you the pleasure to know that earlier sprints had a successful closure. This itself motivates the team to conclude sprints with an actionable product and refer to the finished product at each sprint as proof of their capabilities.

Named Sprints are referencible and give a direction during the current sprint. The practice of code names for products under production comes from product manufacturing industry. The code names for Sprints orients the team and when talking instead of an arbitrary number. The name tends to bring about cohesiveness in teams, particularly when you are establishing sprint teams.

2. Numbered sprints become quite flexible as there are no boundaries established in the minds of stakeholders. Hence there are chances to add/modify priorities and user stories in sprints although SCRUM disallows this practice. It is difficult when stakeholders are new to SCRUM and wish to have many features in a single Sprint.

Named Sprints has potential to live up to the name and can ward off intrusions. Once the name of Sprint is decided with stakeholders, it kind of acts as a barrier for inserting more features that do not live upto the principle and Sprint Vision in the overall product vision.

3. Numbered Sprints are difficult to run in parellel. Again since numbers hold a sequence, stating that Sprints 3,4,5 are running with parellel teams, becomes cumbersome to manage and remembering the priorities of each.

Named sprints are good to align parellel sprints. I normally have a sprint called "libs and interfaces" that run in parellel to initial few sprints. It then makes it easy for me to have other sprint leads ask/discuss the features that can be a global library rather than reinventing the wheel within individual sprint teams. Thus  for effective architecture and design, named sprints become ideal for user story transfers.

4. Numbered sprints do not lend themselves to reporting well. For example, when comparing velocities and individual sprint team performances with stakeholders regarding complexities and user story completions vs iterations in sprints, it is difficult to visualize the working of the team.

In Named sprints, it is automatic to gauge the performance against the metric numbers as the names of the sprint and the numbers seemingly make a sense. I realized this because I use EVM for reporting. I initially used to report performance week wise, then tried to report it as Sprint numbers, but when speaking of numbers with respect to a phase/name of sprint, it is good to debate and understand the variances.

This is a matter of cultural taste and the SCRUM implementation maturity within your organization. To date, either of the projects (numbered sprints or named sprints) have been successful for me in aligning business goals to project results. So far, I do not have emperical evidence to prove if a numbering or naming sprints is good. May be few more experiments might yield some direction and shape up my personal preferences.

Has this topic been a concern in your work sphere? Is there a standard SCRUM terminology that needs to be adhered ? Are there any related experiences that you can share ? Looking forward for best practice evolution with collective intelligence.