Scrum asks for a releasable Increment of product to be available ultimately by the end of every Sprint. A Sprint takes no more than 30 days, and is often shorter. A releasable Increment might be available sooner than by the end of a Sprint, not later.
The purpose of this rule is to provide the Product Owner with the opportunity of bringing an updated, improved software product to market every 1-4 weeks, or more frequent. It is how Scrum implements the first principle of Agile software development:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (source: Principles of Agile Software Development)
Replacing the past wording of ‚shippable‘ by ‚releasable‘ reduced the room to avoid the rigor of releasing frequently, the avoidance that abates the benefits and agility needed. The Scrum Guide adds the prefix ‚potentially’, to clarify that Scrum does not say every Increment must be released. I prefer to leave this prefix out, because ‚releasable‘ in itself is clear enough. Otherwise “Released” would be required as the Increment’s state by the end of the Sprint.
Scrum lays the actual release decision with the Product Owner, as the representative of all (i.e. internal and external) stakeholders. The Product Owner’s decision is not limited by technical or engineering aspects. The product Increment is useable. If released it does not break. This is the accountability of the Development Team. The Product Owner is accountable for assessing whether the Increment is functionally useful.
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. (…) This Increment is useable, so a Product Owner may choose to immediately release it. (Source: The Scrum Guide)
A Product Owner, being an entrepreneur, understands that no release means no feedback from the market place, no feedback from actual product usage. It means no validation of the assumptions built into the product, reduced learning, postponement of much anticipated improvements. In a way, it blindfolds development.
If a Product Owner decides to release an Increment, it is released. Preferably instantly. No additional work remains to do so. All work that mirrors ‘releasable’ is captured in a definition of Done. Defining “Done” creates transparency:
- Transparency when forecasting work deemed feasible for a Sprint
- Transparency when inspecting an Increment
- Transparency over development progress
- Transparency regarding the daily work required to have the software in a state of Done
Scrum, as a framework, can wrap various development strategies that increase the capability of creating releasable (“Done”) software in a Sprint; pair programming, test-driven development, ATDD, BDD, Continuous Integration, DevOps, Continuous Delivery, Continuous Deployment. (note: Scrum promoting the Product Owner as the gatekeeper to release might influence how Continuous Deployment is organised.) Feature toggling is certainly an architectural choice that enables higher Product Owner dynamism.
Software being releasable, no later than by the end of a Sprint, is Scrum’s gateway to agility. By the end of every Sprint, or sooner, an updated, improved software product can be made available to its users and consumers. Feedback can then be gathered to be incorporated into the Product Backlog, and ordered against all other product ambitions.