Releasable in Scrum, actually

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 to the market frequently, but just shipping an Increment within the organization, the avoidance that abates the benefits and agility needed. The Scrum Guide adds the prefix ‚potentially’, to clarify that Scrum does not say that 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 to be limited by technical or engineering aspects. The product Increment is useable. If released, it does not break. That 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 a releasable (“Done”) version of product 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 organized.) 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 (business) agility. By the end of every Sprint, or sooner, an updated, improved product can be released to its users and consumers. Feedback can then be gathered to be incorporated into the Product Backlog, and ordered against all other product ambitions.