Originally published at Knowledgehut website

By the end of each iteration, a Scrum team is expected to produce a Potentially Shippable Product. As we know Agile methodologies emphasize on “Working Software over Comprehensive Documentation”. When we talk about working software, it is both complete and potentially shippable.

Agile methodologies emphasize on working software which is both complete and potentially shippable due to following 3 reasons:

• It encourages feedback
• It helps a team gauge its progress
• It allows the product to ship early if desired

In order to ensure, we are delivering a Potentially Shippable product at the end of the sprint, we must understand what potentially shippable means.

Defining Potentially Shippable

As per Scrum Inc, a Potentially Shippable Product is the outcome of the Product Backlog Items delivered at each Sprint. Delivering Potentially Shippable Product at each Sprint is essential to the Scrum because when work is divided into simple pieces it can be finished in short iterations.

As per Mike Cohn, “potentially shippable” and “shippable” are not the same thing. Some large or complex projects will require the use of “release sprint” or “hardening sprint” at the end of a release cycle (say 6 two-week sprints then a 2-week release sprint). The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur.

Let’s have a look at some of the guidelines here:
Organizations define their own ‘definition of done’ for every product and project. However, there are some guidelines that are applicable to almost all the Scrum projects in most of the organizations.

Potentially Shippable means Tested!

There can be no situation where a product is delivered without being tested. By the end of the Sprint, the delivered product increment needs to be bug-free. If needed by the Product Owner, the feature should be a bug-free, it can be released to the beta users or the stakeholders to review.

Potentially shippable does not mean cohesive

Just because we know that the product is potentially shippable, this doesn’t mean that people want us to actually ship it. Many times it takes 2, 3 or more sprints for a feature set to come together to be useful. However, during the Sprints leading up to that point, the team should still strive for a product to be potentially shippable.

Potentially shippable means integrated

A potentially shippable product doesn’t exist as different collections of source code. On a project, where multiple teams are working, the teams should define the statement of done such that it includes integrating development steams. So, Integration should be done continuously throughout the sprint.

Does Potentially Shippable means Shippable?

Well, when we define the ‘definition of Done’, We want it to be a Potentially Shippable product. This doesn’t mean that it has to be shippable. Whether the product needs to be shipped or not, that’s a decision taken by the Product Owners or Business Owners.

Hence, Potentially shippable is a state of confidence, that the product delivered at the end of the Sprint, is so Done that it’s Potentially Shippable.