When PSPI does not apply
PSPI (Potentially Shippable Product Increment) is an important concept in Scrum framework. At the end of sprint, team is supposed to deliver a potentially shippable product increment. The focus of PSPI is on the readiness of the delivery.
MVP (Minimum Viable Product) is a term popularized in lean startup. It's defined as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort". The focus of MVP is on maximized learning with least effort.
Their focuses are different, and MVP is often not with production quality. So, the question is, are they compatible?
- PSPI is about transparency
First let us understand more about PSPI, and why Scrum demands that at the end of every sprint. Scrum is based on empirical process control, where transparency, inspection and adaptation are three legs of Scrum foundation. Transparency is absolutely necessary for effective inspection and adaption, while having PSPI at the end of every sprint provides a great deal of that.
There is a companion concept called the Definition of Done. Done defines the extent about how close we are towards being potentially shippable. Unfortunately, many teams are not able to create PSPI in every sprint, because they are not technically capable in doing so. Thus, based on the current technical capability, they define their definition of Done as a subset of what's required for being potential shippable. What's the impact on transparency when we have weak Done? The weaker the Done, the less transparency we have. We may not be able to elicit the full feedback with partially done product increment, and we may have hidden risks left later due to that.
Release burndown is one way to represent the transparency. It works by measuring velocity based on Done items and deriving the duration from the size and velocity. Notice that those are all defined, estimated and measured based on Done. If we have weak Done, the burndown point is far from the shipping date. Hardening sprints are necessary in those cases to make up for the undone work and get the product eventually shippable. Hardening sprints obscure the transparency.
In short, PSPI plays critical role for getting transparency and making effective inspection and adaptation accordingly.
- Isn't learning creating transparency
Nevertheless, the focus of MVP seems very different than PSPI. It focuses on learning, getting knowledge and reducing risks. Normally, we don't try to reach production quality in MVP, because it often doesn't yield more learning.
Jeff Patton has popularized the distinction between iterative and incremental. In his term, incremental implies "add functionality", while iterative implies "build something, then evaluate whether it'll work for us, then we make changes to it."
For incremental development, PSPI makes much sense, since that gives us the best transparency. While for iterative development, MVP makes more sense. PSPI doesn't help much in creating transparency during product discovery. The extra work to get into PSPI may be wasteful and slow down the iterating. In fact, the increase of transparency comes from the learning. The learning helps us make effective inspection and adaptation, which could be more learning needed or converting MVP to PSPI. As we'd like to capture all work into product backlog in Scrum, a separate item for this elevation is a natural choice. For most product development, the transition from product discovery by iterating to product delivery in increments is common.
Final note
Getting back to the Scrum foundation - transparency, inspection and adaptation. Transparency is the first key, while PSPI is one way to achieve that. Depending on your context, it may or may not be the most effective way. By understanding why Scrum demands PSPI (for transparency), and what other alternatives to achieve transparency are, we incorporate MVP and other techniques while doing the essence of Scrum.
