Sprint 0, Hardening Sprint, Release Sprint and Release Retrospective ?

None of these are Scrum events, and therefore they are not valid time-boxes. However they are common antipatterns, and attempts are often made to time-box them.

Sprint 0: The term Sprint 0 is often applied to project setup and initiation, during which the release of any value is deferred. As such it is not a sprint at all.

Hardening Sprint: If a team's definition of done is inadequate, or is not being met, technical debt can be expected to accumulate. A so-called Hardening Sprint is an attempt to pay off this debt rather than improve the team's process and thereby stop debt arising.

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. A so-called Release Sprint would therefore be a contra-indication to agile practice.

Release Retrospective: A similar antipattern, since each sprint must yield an increment that is potentially releasable. The outcome of any release should be inspected in the ensuing Sprint Retrospective.

However, if multiple teams are involved in making a release, they *may* choose to hold a Joint Retrospective in addition to their individual Sprint Retrospectives. Note that Joint Retrospectives are not a canonical event in Scrum, but they are generally considered to be an acceptable practice for enabling Scrum at scale.

I intepreted this differently by viewing sprint testing and release testing as part of activities that need to be completed by the development team before the sprint has completed. Theoretically the terms "Sprint testing" and "release testing" are not mentioned in the scrum guide. But testing as part of Done in a development sprint is necessary and if the sprint has a timebox, these two activities should also have a timebox.

Are these view incorrect or is this one of those questions that are ambiguous?

Michelle,
you are right that testing is a necessary part of work in a sprint. However it is not an event and not time boxed according to the Scrum rules. Instead it is up to the self organizing dev team how they want to make sure an increment fulfills the quality standards documented in the definition of done.
A less experienced team may decide to have a "test timebox" for the last 2 days of a sprint.
A more experienced team will know that this produces a lot of waste and will work test-driven, so the test will not be timeboxed.

It isn't ambiguous, because although testing might be a valid activity it is not a Scrum event. Also, it may happen in a continuum within a Sprint, and as such it does not have to be subject to discrete timeboxing.

Backlog refinement is an example of a valid activity which is referenced in the Scrum Guide. It is not an event and so it also does not necessarily have to be timeboxed.

Got it !! Thanks

> A more experienced team will know that this
> produces a lot of waste and will work test-
> driven, so the test will not be timeboxed.

This is a really important point, because it shows the revolution in thought that agile transformation can bring.

In traditional development, the purpose of testing is to find bugs. Generations of testers have been trained and hired on this premise. In lean and agile practice however, the purpose of testing is not to find defects but rather to prevent such waste from arising in the first place.

Hi
I am still not clear on Sprint 0? what are the expectations from Sprint 0 - do we do environment setup, Tech design, architecture, Product Backlog drilling to break into SB ?

I am still not clear on Sprint 0? what are the expectations from Sprint 0 - do we do environment setup, Tech design, architecture, Product Backlog drilling to break into SB ?

The Sprint 0 is not congruent with the definition of Sprint because you are not deliverying any value. A lot of companies uses this practices to elaborate a plan with cost, scope and time to make the sale.

In other way other people use anti-pattern Sprint 0 to setup architecture or define PB and this is contradictory with the principle of emergent architecture.

It is clear that Sprint 0 is not part of scrum; however, I use this term to manage basically the next topics:

• Refine user stories to develop in the first sprint.
• Prepare the sprint backlog and priorize it.
• Create test cases to be consider.
• Request project infrastructure.

According to scrum, what is the best option to include this topics based in the  scrum framework; these items are required for the project. The only idea that comes to me is create these elements in the backlog and attend them in the first sprint, but the story points for this sprint will be affected due to without them the SP will be limited.

The only idea that comes to me is create these elements in the backlog and attend them in the first sprint, but the story points for this sprint will be affected due to without them the SP will be limited.

So what? Most of the work in the first few Sprints could be setup work. As long as a usable and valuable Increment is being created each time, however minor the functionality, empiricism is being established. 

It is clear that Sprint 0 is not part of scrum; however, I use this term to manage basically the next topics:

• Refine user stories to develop in the first sprint.
• Prepare the sprint backlog and priorize it.
• Create test cases to be consider.
• Request project infrastructure.

In my opinion, everything you listed is part of backlog refinement and management.  Since that is an ongoing activity, why would you create a Sprint timebox for it?  Sprints are for delivering usable increments of value to the stakeholders.  

There is nothing stopping you from using the term "Sprint 0".  In fact, I had one team that insisted the very first Sprint was labeled as such because 0 is the first digit in binary math.  We used binary to name our Sprints for about 3 months but it got ridiculously long so it was switched to hexadecimal for the remainder of the year.  In reality, the name has no real meaning.  It is something that "Agile" consultants made up for marketing materials. But I won't get on that soapbox right now.

Please allow me to explain in one sentence

"Sprint 0, Hardening Sprint, Release Sprint and Release Retrospective ."

They not only DONT EXIST in Scrum, they are strongly discouraged.

All those amenities are part of ScrumStudy and SBOOK networks which are illegally parasitizing on Scrum, using existing trademark and copyright to promote own, unrelated methodology. 

A mature Scrum Team will execute at least one Release Sprint, as well as may release several. 

Cette phrase est Fausse. Pouvez-vous me dire pourquoi svp. 

Peut-être parce qu'à la fin de chaque Sprint on release un increment et pas un Sprint? 

Answering in English as it is the only language I speak.

A Scrum Team delivers at least one usable increment of product value in every Sprint. Each increment is to be inclusive of every increment previously delivered.  How/when that is released is entirely up to the Scrum Team to decide.  In this age of Continuous Integration/Continuous Delivery (CI/CD) that could mean releasing an increment multiple times a day.  

A "Release Sprint" is not something encouraged or documented as part of Scrum. Scrum values and encourages the ability to deliver to the stakeholders often in order to facilitate the stakeholders to provide feedback which can influence the future direction of the product work. Using the concept of a Release Sprint introduces an impediment to being able to deliver updates to the stakeholders. It limits the Scrum Team's ability to deliver incremental value to the stakeholders. 

Ce qui suit est fourni par Google Translate car je ne parle aucune langue autre que l'anglais.

Une équipe Scrum fournit au moins un incrément utilisable de valeur produit à chaque sprint. Chaque incrément doit inclure chaque incrément précédemment livré. C'est à l'équipe Scrum de décider comment et quand cela sera publié. À l’ère de l’intégration continue/livraison continue (CI/CD), cela pourrait signifier publier un incrément plusieurs fois par jour.

Un « Release Sprint » n'est pas quelque chose d'encouragement ou de documenté dans le cadre de Scrum. Scrum valorise et encourage la capacité de livrer souvent aux parties prenantes afin de permettre à celles-ci de fournir des commentaires qui peuvent influencer l'orientation future du travail sur le produit. L’utilisation du concept de Release Sprint introduit un obstacle à la capacité de fournir des mises à jour aux parties prenantes. Cela limite la capacité de l'équipe Scrum à fournir une valeur supplémentaire aux parties prenantes.