Jul 21, 2013

A common source of frustration occurs when people, especially Product Owners (PO), realize that what they can expect from a single sprint is nothing like what they need to release. They want it all. Anything less is useless.

What the business wants in order to ship the product is called Minimal Viable Product (MVP). The sum total of features that the PO has determined is worth presenting to our customers.

At the end of each sprint the team should have a Potentially Shippable Product Increment (PSPI).

The relationship between PSPI and MVP is that MVP is the sum of several sprints worth of work.

MVP = ∑ PSPI

The “potentially shippable” part is really important because that allows the PO to change direction at any sprint boundaries, or to release earlier if they choose. That phrase also drives the organization to break down the waste of hand-offs between silos, driving testing into the sprint. Sutherland reported the effort to test, even one sprint later, was 24x the effort to test during the sprint. He also pointed out that breaking down this barrier is probably the single best thing you can do to improve your organization.

Q: My business users don’t see any value in intermediate deliverables and in their eyes MVP is equal to a fully delivered product. Why bother with PSPI?

A: This is a common situation before PO understands (and trusts) the tech teams. Their mind is still in the contract game and they want to push responsibility not only for development but also prioritization and conflict resolution into the tech teams.

Even for deeply technical stories with no UI we have found ways to demo the work. Always try to pick a slice that goes as near end-to-end as you can. To the extent the scrum teams can deliver PSPI every sprint that have got working code much earlier and the integration effort is amortized over a longer time (big bang integration often leads to lots of OT and pain, as you probably know). Scrum teams should absolutely drive for PSPI even when the PO doesn’t seem to care, because the effect of that construct is good for the product and exposes weaknesses in the processes & tools in place.

Every situation is different, but demonstrating working code that is incrementally better every few weeks is a compelling draw for many people, so even if your PO is intransigent now we should hold the line and be agile because we see the benefits.

See Also: “Why Longer Sprints Probably Won’t Help“.