Functional Scrum Team in context of Release

Shouldn’t a team plan to release something at least once every Sprint?

Would you say they are properly function if they would incorporate Release Sprints?

Shouldn’t a team plan to release something at least once every Sprint?

Yes. But I am not sure what " incorporate Release Sprints", exactly mean. What is your though on this.

Would you say they are properly function if they would incorporate Release Sprints?

yes I would, what about you?

I would say that a team that is using "Release Sprints" isn't using Scrum - every Sprint results in a potentially releasable Increment. Even in scaled frameworks, such as Nexus and LeSS - each Sprint results in a potentially releasable Increment that is fully integrated across the teams.

However, there may be valid reasons to have something like a "Release Sprint" or a Sprint designed to support hardening and release. Other reasons for having one may be indicative of problems in the team or organization. If a team proposed having a "Release Sprint", I'd want to know exactly what the purpose of such a Sprint would be and why they feel it is necessary.

The thing I'm trying to make here is that at the end of every Sprint, there should be a potentially releaseable Increment. Now let's say you plan to wait for Release Sprint to actually release. This may impact the ability to have something releasable every Sprint.  

What is the impact on time to market of having a separate release sprint?

Would you make empirical decisions sooner if you can release within a shorter amount of time? If not, why not?

What do you think if properly functioning Scrum Team will have at least one Release Sprint and may well have several?

I would say that such a team is certainly not properly functioning in Scrum.

What organizational constraints exist that prevent a Scrum Team from being able to release at the end of every sprint, and thereby violate a basic tenet of Scrum?   

What can be done to remove or mitigate such constraints so that such a team can include release-related activities as part of their DoD?

there is no "Release Sprint" --> Release Sprint: Each sprint must result in a potentially releasable increment, regardless of the number of teams and deliverables involved in a release, so batch sizes of undelivered work can be minimized and controlled.

I don't think Release Sprints are necessary as rightly suggested above as it tends to delay the release of increments at the end of a Sprint. Based on Scrum Guide, there is really no Release Sprints.

Release sprints, if I understand this, is a sprint to prepare and enact a release.  That's like a sprint to remove technical debt.  The Scrum guide doesn't say you can't do this, but the Scrum guide doesn't say you have to do Scrum well either.  So from the stance of functioning Scrum team, you can claim to have one, but it's like having a bicycle with 2 flat tires that you ride to work and claiming to have a functional bike.

Smaller releases that don't need a sprint to prepare is the way to go.  

There's a whole section on that in the PSPO class!