> My team chooses the characteristics of the sprint. It’s not like they are randomly assigned. It’s a collaboration between leadership, team members and non-team stakeholders. It’s not like there’s anything mandatory, so we set our release schedule and what a release means based on what makes sense.
No dictation on length, but the length is supposed to be consistent. If you want to take a three week sprint or something instead because the feature makes sense, you mess up a whole lot of things, especially the metrics. And, let's be honest, the metrics are the biggest reason why management imposes Scrum. They want to be able to quantify everyones contribution down to hard numbers that they can then use to know how everyone is performing. If you screw up the metrics, it won't take long for someone to step in and "get your team back on track."
Metrics and software process are orthogonal. Now, you can argue that consistent processes across teams is used to enable metrics, but Taylorism is going to creep up any place that has management that has been infected by it.
"They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint." - scrumguides.org
You also need to understand that "release" might mean behind a feature flag. Further, while continuous integration is not within the Scrum guide, it is a common practice in Scrum teams. Yes, there is a concept of a sprint goal, but the sprint goal may be a subset of the product goal. You may choose to group increments across sprint boundaries to present to customers independently of the end of the sprint.
But then it's not Scrum. Scrum is weekly.