What's in the Potentially Shippable Product Increment (PSPI)?

There are many references to the frequent release of running software in the agile universe – of which the agile manifesto certainly gets cited the most.

One term has become very prominent - the “potentially shippable product increment” from the agile sub-universe of scrum. [In this case from LeSS - the Large Scale Scrum Framework. ’Of course’ the scrum guide itself does not use this term. The scrum guide calls it “Increments of potentially shippable functionality”]

But since the notion of the potentially shippable product increments captures so much of the practices of good agile software craftsmanship I really fell for the term and use it more often than the official term from the scrum guide.

And it is a very handy way of illustrating what is behind the ideas of Integration, Shippable, Iteratively, Product(ion quality), w

Integrated

“All [created artifacts] have to be integrated” – the stuff really has to work together (as I outlined in more detail in what exactly is continuous integration).

Shippable

Something you could give the customer to play with on their own. An installer-file, an executable, a .ear-file with deployment description, a docker image etc. Something they could really “take away” with them.

Iteratively

We know we are going to change things - let’s build them in such a way, that it is (and stays) easy to do that. Even though we deliver increments of the product we do so iteratively – we do not try to paint a picture like the Mona Lisa from the top left to bottom right. We do it with sketches and refinements and edits until we are finally satisfied with the result.

Production quality

Production quality is perhaps the hardest one to explain without painting lots of pictures. One of the best explanations I've come across is that it "also has to work when the customer can use it without the developer being around" – which implies many little things.

Those things could include:

• a user friendly way to interact with test-data if there is something like that necessary for the relevant increment
• no buttons that don’t do anything
• no spinning wheels that are not connected to any of the inner workings
• etc.

Of course this is a bad definition, because it (almost) only defines a negative-list. It only says what production quality is not. I’m still working on a positive-list, and hope to release that soon.
One thing for that positive-list that springs to mind immediately is the requirement that the code adheres to the SOLID principles – so that it only has to be changed if a future requirement has an impact on the implemented capabilities – not because something has been left over “to be fixed when we work on this in the next iteration.”

How do you define your “Increments of potentially shippable functionality?”

till next time
  Michael Mahlberg