Regular Product Increment**

Alias: Product Increment; Potentially Shippable Increment

An ideal hen would lay one egg per day, and in fact their production rate is regular: once every 26 hours.

...the Product Owner is managing the Product Backlog and the Development Team is working toward the Sprint Goal in the current Production Episode.

✥ ✥ ✥

It is often very difficult to validate if the team has created value in every Sprint. However, the Product Owner wants to be sure that the product increases value, Sprint after Sprint.

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 the Product Owner’s 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 such measures are decoupled from properties of the product itself, thus 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 the goal to drive its 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—something of 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, due to lacking 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 strives to deliver a Product Increment that is Done (see Definition of Done), usable, and potentially releasable. The team uses the Product Increment to validate if it has 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.

✥ ✥ ✥

The Development Team will deliver a Product Increment of value on a regular, recurring basis, that supports the Vision, reflects the Product Owner’s roadmap (see Product Roadmap), and meets the team’s Definition of Done.

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 its 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 from 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:

• • Changes to the “triple constraint” or the “iron triangle.” Time is fixed because the Sprint length is fixed, so scope and cost must vary to support this change.

  • Though time is fixed, so is the delivery interval; there is no late delivery.

  • It becomes simpler to report on delivery: the increment is Done or it is not.

  • Internal silos that hinder Product Increment development will start to break down as teams work cross-functionally. This will change the roles for silo management from resource allocation to staff development (often a sidelined activity) and thought leadership.

After the end of the development time box for each Sprint, the team should convene a Sprint Review where, among other actions, it reviews 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.

At the end of the Sprint, the team should also hold a Sprint Retrospective to review the product development process.

The enterprise may consider splitting the product up if the products’ Value Streams become differentiated in their respective markets; see Value Stream Fork.

Picture credits: Image Provided by ShutterStock.