Skip to main content

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

Last post 10:20 pm November 27, 2023 by Daniel Wilhite
14 replies
11:20 am May 15, 2014

Can anyone please explain these concepts ? Sprint 0, Hardening Sprint, Release Sprint and Release Retrospective .
Are all these part of scrum ? As Scrum guide don't tell anything about these.

And which of the following are not time boxed events ?
Release testing
Sprint 0
Release retrospective
Sprint testing


01:10 pm May 15, 2014

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.


06:59 am May 21, 2014

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?


07:10 am May 21, 2014

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.


07:21 am May 21, 2014

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.


08:41 am May 21, 2014

Got it !! Thanks


09:11 am May 21, 2014

> 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.


08:02 am April 28, 2015

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 ?


01:17 pm November 20, 2018

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.


10:09 pm August 15, 2023

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.

 


06:23 pm August 16, 2023

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. 


06:50 pm August 16, 2023

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.


10:01 pm August 16, 2023

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. 


06:59 pm November 27, 2023

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? 


10:20 pm November 27, 2023

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.