The PSI: Potentially Shippable Increment
For the second installment of our MVP, MMF, PSI Alphabet Soup series, we’re going to tackle the PSI (Potentially Shippable Increment) also known as PSPI (Potentially Shippable Product Increment).
Where I try to start with Product Owners when I’m coaching them is the idea of the PSI (Potentially Shippable Increment). At the end of every iteration, our Scrum team should have completed work on one or more Potentially Shippable Increments (of Customer Value, but we’ll get to that in a second) that their Product Owner can make a decision around—can I ship this to my customers?
What this means in practice is that, as a Product Owner, I end up focusing on small little features—things that I can take for granted as a given, as “table stakes” when building a product in my market. If my team is working on building the Next Great Word Processor (because actually updating WordPerfect™ from the grave would be more costly than starting over) then it’s easy to assume that everyone understands what you mean when you say that your customers want to “Save their Document.”
There are a surprising number of assumptions that go into “Save” though; the program I’m using to write this blog post, for example, doesn’t even have a Save command. Instead, everything is automatically saved—to iCloud using CloudSync, naturally—when I stop typing for a few moments. As a Product Owner, I don’t have to know about iCloud or CloudSync, but I do have to define those things that I would otherwise take for granted.
After our Product Owner defines our features at a high level, the critically important work of actually talking to her team takes place, and during that conversation, she realizes that providing her customers with the security of a document that’s always saved is an actual market differentiator when compared to other word processing programs.
So, our Product Owner rolls up her sleeves and talks to her team, and we write a User Story:
“As an author, I want to have my word processor automatically save my document while I work, so that I can work on writing without being concerned about losing my data.”
She’ll iterate with her team on some acceptance criteria (“Documents need to be saved when disconnected from the Internet”) and handle some edge cases that can turn into User Stories on their own (“Roll back to a previous version, because I actually didn’t want those most recent changes saved”). As they iterate, they’ll winnow down a feature into something our team can deliver in one Iteration—a Potentially Shippable Increment.
“Great! We got that User Story to Done-Done! What do our customers think?”
“Well, we haven’t released it yet…”
For the final installment of the series, we’ll discuss the MMF (Minimum Marketable Feature) and how it helps draw the distinction between PSI and actually shipping your product.
Leave a Reply