The phrase “potentially releasable” has a very simple meaning: the features built in a Sprint and all the related activities are done to such a degree that ONLY business considerations are involved in the decision to release or to not release at the end of the Sprint. Every Sprint should start with the intention of getting a small set of Product Backlog Items to this ideal state. Of course, teams make mistakes and have obstacles to doing their work to this level of doneness. The intention to make potentially shippable software is designed to help teams see and expose obstacles to actually shipping. These can be technical obstacles, dependencies, or bureaucratic obstacles.
Failing to have this intention removes this beneficial pressure from the team. This lack of pressure can in turn lead to acceptance of “the way things are” and a team that never reaches a high-performance state.
Below is an overview of an activity that can be facilitated by the Scrum Master called Definition of “Done” Gap Analysis.
- During the Sprint Retrospective work with the team to make a list of all the activities that currently need to be performed by people in the company in order to ship the product. The Product Owner should know what makes the product releasable and should be able to help the team with this. If the Product Owner doesn’t know, he or she needs to find out or bring someone in to help the team with this exercise.
- The resulting list is the releasable Definition of “Done” for the product. The team should then compare this list with their current Definition of “Done” for every Product Backlog Item. If the list is the same, then the team has realized this rule of Scrum.
- If the team’s current definition is less than the shippable definition, then clearly there is a gap between the team’s current capabilities and the desired level of doneness. Explain to the team that applying the releasable definition of “done” to every Product Backlog Item is how they will realize the intention of “potentially releasable” product increments every Sprint.
- The team should then discuss all the reasons why their current definition does not fulfill the releasable definition. All of these reasons should be identified as obstacles which should be systematically removed. The Scrum Master is responsible for removing these impediments. Some of these reasons may be resolved immediately. For example, if the team can implement more rigorous testing within a single Sprint along with some light documentation, this may allow the team to be well on its way.
This exercise is a way for the team to systematically explore how it can evolve its definition of “done” and improve. This is also a way to help the team and the organization see that a potentially releasable intention for each Sprint is possible. People will likely start finding ways to break out of the existing status quo and innovate. They will likely find that learning new skills is required, such as certain Agile engineering practices. Perhaps the team will find ways to automate certain aspects of the system such as building, testing, deploying, and perhaps the Scrum Master can work with groups outside of the team to give the team more authority and autonomy over all aspects of the system, including data sources and production systems. The point being that this conversation is a way to open up the team to possibilities that it may not have seen before and allow people to explore these possibilities through action.
Even if everyone does not realize that this intention is possible or even desirable, the Scrum Master must pursue the removal of these impediments. Over time, as they are removed, negative attitudes will most likely give way and people will see the business value in delivering “done” frequently and the technical agility afforded by incremental/emergent design. As the impediments are removed, and the team expands its definition of “done” it will move closer and closer to realizing this intention.
The heart of Scrum is a Sprint… during which a “Done”, useable, and potentially releasable product Increment is created.
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it. — The Scrum Guide
Check out our comprehensive article on the Definition of Done for more depth about this topic.
Certified ScrumMaster® – Guaranteed to Run! ✅
Certified Scrum Product Owner® – Guaranteed to Run! ✅
All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual. Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.
Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…
Berteig Consulting
Empower Your Entire Organization with BERTEIG Consulting in Agile, Scrum, Kanban, SAFe and LEAN.