Potentially releasable product?

Posted Jan 16, 2019

What is a “potentially releasable product increment”, really? Last year I worked as Scrum Master in a team that delivered software for multiple target platforms. One of the products was a mobile application. The mobile application was target for multiple markets and regions and needed multi-lingual support. One of the features in the application was to switch between different languages inside of the application (the app runs on a device available to a range of people with possibly different primary native language).

Some changes had been introduced to the texts in the application. We needed to send parts of the texts to the translation agency for retranslation. Unfortunately, the Chinese translations were not returned before the end of the sprint and didn’t make it to the sprint release. As a consequence, the missing texts disappeared when Chinese language was selected in the application. We were aware of this and told all our stakeholders about it during the sprint review. One of the stakeholders then asked: “Is this really a potentially releasable product increment?”

At that point it got me thinking; Maybe it isn’t?

Maybe we can find the answer to this in the core of Scrum? Scrum is built on empirical process control. The core of empirical process control is transparency, inspection and adaption. If we actively work on these things it will enable us to gain knowledge from experience and to make decisions on what is already known.

One of the purposes of Scrum is to foster short feedback loops and one of the main benefits of having a potentially releasable product increment each sprint is to enable inspection and adaption. Without it we can’t get proper feedback from our stakeholders.

In the Scrum Guide we can read that:

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”

and…

The increment must be in useable condition regardless of whether the Product Owner decides to release it.

The take away from this is that as long as the translated texts were not a part of the team’s Definition of Done the increment can be seen as potentially releasable. The increment enables inspection which will generate valuable feedback on the increment. The product owner may very well decide not to publicly release the increment, but what can possibly be better than fast feedback from people actually using and evaluating the product?

One way to meet the expectations of the stakeholders forward would be to alter the teams Definition of Done with a point stating that all texts should have a proper translation for all supported languages. This would result in an increment where no texts are changed before all translations are delivered from the translation agency.