Naming conventions for Sprints
Thought I'd take the opportunity to get a few thoughts on Sprint names. I'll start by saying that at the moment we have a system that we use department-wide and every single project has the same sprint names - e.g. Sprint 2020-04-27, Sprint 2020-05-11, etc.
I will say that I'm not a fan - it doesn't make sense to me to have a 2 sprint project that could span 3 sprints in our system because it doesn't start on a Monday.
I wondered what people name their sprints as (is it something similar to the above or Sprint 1, Sprint 2, etc or something else entirely?) or whether it even matters, as long as there's a clear structure to them?
I don't think the name of the Sprint matters. It's just a timebox that includes all of the Scrum events.
However, I don't understand what you mean by having "a 2 sprint project that could span 3 sprints" in your system. A Sprint could be viewed as a project with a fixed schedule and cost and a flexible scope.
In your department, how is the optimal sprint length determined for each product?
@thomas - Sorry that wasn't clear. If it was determined that there was a 4 week project, with sprints 2 weeks in length, then the name of the sprint wouldn't reflect the actual start date of the sprint.
So a project starting today, 1st May, would still be named with the 27th April as part of the naming convention. So in effect you'd have 27th April sprint, 11th May sprint and then another sprint because the 4 weeks would actually span 3 sprints based on the actual start date.
I think it's going to cause pain in all honesty because the dates in the system don't reflect the life of the project, and think it'll be easy for the last "sprint" to overrun because work hasn't been properly tracked due to this unnecessary complication.
@ian - The optimal sprint length isn't really determined at the moment. Someone's (and I couldn't even tell you who) picked out 2 weeks as a standard and the expectation is that everyone follows that. I don't like this approach, because projects aren't one size fits all, and the more I think about the department process the more I can see there being room for error.
It sounds like you're thinking about projects and not products.
In Scrum, the suggested thinking is that each Sprint would be thought of as its own project that produces a consumable product or service by the end of the Sprint.
Personally, I don't believe that there are problems with "projects" - bodies of cohesive work that are larger than a Sprint that represent something meaningful to stakeholders.
I think what you're experiencing is normal. The project and the Sprint are two separate concepts. You plan a Sprint that includes work associated with a project, but you may start that work at any point in the Sprint. You can also complete (and even deliver) the work associated with the project in some later Sprint, since there's nothing in Scrum that says that you must deliver only at the end of a Sprint. If you track when the work was started, completed, and delivered, the dates for the project may not align with the Sprints.
If you are tracking the notion of a project, I wouldn't expect it to align with a Sprint in all cases. It's definitely not required.
My recommendation: separate the notion of a project from a Sprint.
My recommendation: separate the notion of a project from a Sprint.
+1 for @Thomas Owens' suggestion.
I've worked with teams that have a used a lot of different naming conventions. Some would just use "Team A 1", "Team A 2", etc. Others would create funny names like "Antagonistic Anteater". Still others would use something related to the work that the Sprint Goal focused on like "Edit Budget Line Item Part 1". I had one team that used a random text generator to name all of their Sprints. The takeaway is that a Sprint Name really has very little use in a team being able to deliver incremental value.