Potentially Shippable Product Increment (PSPI): Rosetta Stone of Software Development

In Scrum, the goal is to have a Potentially Shippable Product Increment (PSPI) at the end of every sprint. However, many teams fail to accomplish this on a regular basis. I believe achieving this is what unlocks much of the power of agile.

The Rosetta Stone is a granodiorite stele inscribed with a decree issued at Memphis, Egypt in 196 BC on behalf of King Ptolemy V. The decree appears in three scripts: the upper text is Ancient Egyptian hieroglyphs, the middle portion Demotic script, and the lowest Ancient Greek. Because it presents essentially the same text in all three scripts (with some minor differences among them), it provided the key to the modern understanding of Egyptian hieroglyphs. – Wikipedia

So what is a Potentially Shippable Product Increment?

“Potentially Shippable” means it is of release quality. Some teams will say, “We can’t do agile because we can’t release every two weeks.” That is not what it means. Instead, you may not have enough value completed to release at that time, but what you have is high quality, or “releasable”. Your release cadence and your sprint cadence can be different, but you should be completing an increment of functionality–built, tested and free of critical defects.

Example:

Let’s assume we are building an online product marketplace. We might have features like a product search, view products, a shopping cart, enter credit card and place an order. In the next Sprint, all we can complete is the shopping cart functionality. Could that be a Potentially Shippable Product Increment? What if we finished and tested all the shopping cart functionality? We can add items, remove items, change quantities, but not enter your credit card and pay for the item yet. It is an increment of functionality that could be released if it was deemed valuable enough. We probably wouldn’t, but we could. We could have a big launch, “Come add items to the shopping cart. In two weeks you can buy them!” 

Key Element to Enable PSPI:  Definition of Done

First, we have to agree on a Definition of Done, or define the finish line. This allows us to align expectations of “potentially shippable” and “working software.” (See Principle #7 in the Agile Manifesto).

At a minimum, it should include:

• Complete Design and Development
• Feature Tested and Defects addressed
• Meets Acceptance Criteria and Product Owner has signed off

Ideally, it would also include:

• Integration Tested and Defects addressed
• Regression Tested and Defects addressed

However, this typically requires an investment in Test Automation. Some organizations also expand further through user acceptance testing and production deployment.

Key Element to Enable PSPI:  Learn New Skills

Second, the team needs to learn new skills like breaking down work and swarming. Good agile teams figure out how to get features done early and throughout the Sprint instead of everyone working on their own in a mini-waterfall where QA is squeezed in at the end. Multiple developers collaborate on a feature together rather than each his own. This collaboration starts in Sprint Planning when the team breaks down tasks into items no bigger than a day and transferring enough knowledge to work together. The typical counter argument is that it’s more “efficient” for developers to work on their own in their areas of specialty. I agree collaboration is not “efficient” at an individual level, but would argue the goal isn’t to write the most lines of code possible. Instead, the goal is to deliver value to accelerating learning and pivot to maximize the outcome over the life of the project.

Key Element to Enable PSPI:  Break Down Requirements

Third, requirements need to be broken down to be testable and valuable. This is where User Stories meeting the INVEST criteria comes into play.

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Independent is critical in that we need something at the end of the Sprint that works without needing future stories.

Back to our shopping cart example–Let’s break that work down into 3 stories: UI, Middle Tier Code, and DB Back end. In one sprint, all we completed was the DB Back End story, how would we know we are done? Could we test it? We could test if it meets the spec. We could test it has the Numeric 9 field and a VarChar 20, but we won’t actually know if it is complete until we integrate it with the UI and test it from a user functionality perspective. This is why we need to break down work into slivers of functionality to achieve a testable valuable PSPI.

In summary, employ the key elements of “Definition of Done”, “Learn New Skills”, and “Break Down Requirements” to create a Potentially Shippable Product Increment.  Getting potentially shippable is a key Agile capability but getting there is complex and involves different parts of the organization. An Agile assessment is a good step towards understanding what’s standing in the way of shippable. Go here to learn about our 3 Agile assessment services.