Potentially Releasable is a product increment meeting release criteria that might be strategically held by the Product Owner.
puh-TEN-shuh-lee ri-LEE-zuh-buhl
The Developers aimed to produce a potentially releasable product Increment at the end of each Sprint.
Agile practitioners should be familiar with the term “Potentially Releasable” because it is a key concept in Agile methodologies that emphasizes the importance of maintaining a product or feature increment in a state ready for release at any time. The idea is to ensure that, at the end of every Sprint, the product increment created meets all the quality standards and is fully functional, even if the Product Owner does not immediately deploy it to users. This approach encourages continuous integration, regular feedback, and the ability to adapt to changes quickly, allowing teams to respond effectively to customer needs or market changes. It also instills a discipline of completing work to a shippable standard, which is crucial for delivering value incrementally and frequently, a core principle of Agile practices.
Although there is some discussion about whether “potentially releasable” and “potentially shippable” have distinct meanings, in the 2011 Scrum Guide, they appeared to be synonymous. This is evidenced by the fact that during the second update of the guide in the same year, the term “potentially shippable” was substituted with “potentially releasable” in its sole instance, indicating that the authors regarded them as equivalent concepts.
We should have a potentially releasable product at the end of each Srpint. Tough you can relaese more often than one a Sprint, releasing at least once per Sprint ensurges constant progress. But the depth of ‘potentially’ spans beyond development into the realms of market strategy.
In Scrum, “Potentially Releasable” signifies that the product increment can be launched to users at the end of a Sprint, meeting all the criteria for release. Yet, when to pull the release trigger often involves more than just technical readiness.
I’ve heard this explained best in my CSM course with Mountain Goat Software. Imagine developing two features: Print Preview and Print. It’s possible that both can’t be completed in one Sprint. Releasing just the Print Preview might seem pointless without the ability to print, and printing without previewing could frustrate users. Thus, even if Print Preview is ready and tested, the Product Owner might hold its release until the Print function is available to ensure a seamless user experience.
Quick Links
Legal Stuff