Potentially Shippable Increment
✥ ✥ ✥
The Product Owner wants to build a valuable product in the right way. The market has real needs and there is always the chance for a mismatch between these needs and Product Owner intentions. So the Product Owner must regularly verify that the developed Product Backlog Items (PBIs) are on track to create the value that he or she envisioned. Many practices, such as “Earned Value,” use abstractions of the product for this verification, but because such measures are decoupled from properties of the product itself, they may not reflect the customer’s perspective on value.
To create a valuable product the Scrum Team created a Sprint Goal in Sprint Planning, and used it to drive their work forward during the Sprint. At the end of the Sprint the team should check the intended value described in the Sprint Goal against reality.
Stakeholders expect the Development Team to deliver something concrete at the end of the Sprint that has value to them. A Development Team of specialists from several organizational silos, or indeed multiple Development Teams working together, may believe they have a real product when these specialists complete their work, but because they lack a shared team perspective, they may have produced nothing beyond isolated components. The whole product is more valuable than the sum of these components, and real value comes from integrating these components into a cohesive whole. The market is unlikely to care about how the team partitioned the product for development convenience.Therefore:
Every Sprint the Scrum Team creates a Product Increment that is Done (see Definition of Done), usable and potentially releasable. The team uses the Product Increment to validate if they have increased the value of the product, and to understand how the product actually performs in the market. In the long term the end users will be happier, and current use can hone foresight that can help the team head off many future risks.
The main value of Scrum is to produce a product for use by stakeholders, one assessable increment at a time, and to increase the knowledge that comes from experience using and building the product. That knowledge can help the team learn to incrementally improve both the process and the product; see Kaizen and Kaikaku. The Sprint can be seen as a gate between the Scrum Team’s intentions for the product and reality.
✥ ✥ ✥
There is a close relationship between the increment and the Sprint Goal. The best Product Increments comprise cohesive PBIs that together at least achieve the Sprint Goal. One fundamental reason we use Sprints in Scrum is to deliver a cohesive increment of the product.
A Scrum product is an administrative unit that the Product Owner defines, owns, and manages. The Product Owner is accountable for product value (see Value and ROI). Scrum is silent on how cohesive a product is; we could define a bicycle and airplane as together constituting a product, or a browser and an operating system. A product supports one or more Value Streams: one for the end users, and one for the Scrum Team, who are themselves stakeholders in the success of the product. The best Scrum products enable good market focus by supporting a single market (end user) Value Stream. Any given Product Increment creates value along one or more of these Value Streams.
To deliver the Product Increment the Development Team should be a Cross-Functional Team. Supporting the delivery of the increment across their organizational or role silos during the Sprint(s). This is a challenge for organizations adopting Scrum. Individuals in the organization will demonstrate the actual values of the organization (in contrast with the espoused values) through their local work practices. Having individual performance measures that reinforce local silo based behaviors will fight against this cross functional work and stop the Development Team creating the Product Increment.
When a team or an organization is capable of delivering Product Increments there will be new forces on the organization, Including:
After the end of the development time box for each Sprint the team should convene a Sprint Review where, amongst other actions, they review the Product Increment. Yet additional feedback will inevitably come from the market after release; in the interest of eliciting this feedback as early as possible, the team should deploy (not just ship or release) every Product Increment to some constituency that actually uses it. The team can deliver the approved Product Increment to an ever wider market scope over time, perhaps starting with a beta release to reduce risk and then widening to close partners and eventually the entire market; see Release Staging Layers. During its lifetime, the product’s contribution to its users’ quality of life, to the community that builds it, and to as large a community as possible, should rise to the Greatest Value possible.
Picture credits: Image Provided by PresenterMedia.com.