Release sprint most crucial for Big projects
After end of every sprint there should be potentially releasable increment.
But for big projects release sprint might be crucial before final release .
More work and evolution is required for release sprint and it should include one more round of testing.
For Example,dream project of Airbus Dreamliner taken a hit due to battery issue .It might would have been possible each n every component was tested but adding one more round of testin can save issues and brand image later..
> for big projects release sprint might be crucial before final release
If a "release sprint" is crucial, then by definition any previous sprints cannot have yielded a potentially releasable increment, and the rules of Scrum are not being applied. The rationale you describe has a greater affinity with non-agile frameworks such as SAFe.
> adding one more round of testin can save issues and brand image later.
If that is true then technical debt has been incurred. It is likely that the Definition of Done was inadequate prior to that round of testing, and therefore it should be challenged and improved.
Are there any automated test? I would also be afraid to release a mission critical software continuously without any automated tests :-)
I can see Samridh's point: when developing independent new increments over several sprints, but only releasing them together at the end of a 'project', you would like to test the whole project, right?
Does anyone have experience with 'saving' increments for a bigger release? Or would this strategy be contrary to Scrum and therefore not be used at any time?
> Does anyone have experience with 'saving'
> increments for a bigger release?
This is quite typical of "waterscrumfall" and it is regrettably very common. There will be very few releases...perhaps just one at the end of a project. This is often a symptom of trying to apply Scrum within a stage-gated organizational culture, where Scrum is applied to software development but not to integration testing or delivery.
> Or would this strategy be contrary to Scrum
> and therefore not be used at any time?
It's contrary to Scrum because Sprints would not result in increments that are potentially shippable. The Definition of Done is correspondingly far too constrained, and fails to address the full journey into production. Inspection and adaptation is compromised, both at the product level (wthich is not released in a timely enough manner to provide incremental feedback) and also at the process level, in that Scrum Teams are constrained by the rules of a dysfunctional organization, and cannot change its non-incremental approach to delivery.
>>Does anyone have experience with 'saving' increments for a bigger release? Or would this strategy be contrary to Scrum and therefore not be used at any time?
It is very common and often required by marketing teams to roll up many increments into a larger public release. This is perfectly acceptable in Scrum as long as your increment is available for your Stakeholders to access to provide you with feedback. You need to be able to inspect and adapt every cycle and Scrum does require, although not explicitly stated, that your software be released.
Released however means many things to many companies. Worst case only your Product Owner has access to the new increment. I would then recommend that your PO takes that increment and actively solicits feedback from as many people as possible to make sure that you are building the right thing. That means all you stakeholders: Managers, Coders, Testers, Sales, Marketing, Users and anyone else that interacts with that software.
It is not contrary to Scrum to do what is best for your business. Just be careful and mindful that it would be contrary to Scrum if only the Scrum Team (Development Team + Product Owner + Scrum Master) saw the increment Sprint on Sprint.
In Scrum each Sprint should result in a potentially releasable increment. However the target consumers of that release may indeed vary.
For example it's fair and reasonable to limit a given release to a certain market segment. This might be done in order to sandbox a new Minimum Viable Product before general release is sanctioned.