Regular Product Increment

Potentially Shippable Increment

Incrementally building on top of an existing product.

... 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 what the Product Owner might intend to do may not meet these needs. So the Product Owner must regularly verify that the developed PBIs have the intended value. Many practices, such as “Earned Value,” use abstractions of the product for this verification, but because the actual product is not used these practices 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 this is used to drive their work forward during the Sprint. At the end of the Sprint the intended value described in the Sprint Goal must be checked against reality.

The Development Team is expected to realize something concrete that has value for the market at the end of the Sprint. A Development Team made up of specialists from several organizational silos may believe they have a real product when these specialists complete their work but all that is made are components. The whole product is more valuable than the sum of these components, therefore real value requires these components be created into a cohesive whole.


Every Sprint the Scrum Team creates a Product Increment that is Done, usable and potentially releasable. The Product Increment is used to validate if the value has increased and helps to create understanding about the product, thus reducing potential risks.

The main value in using Scrum comes in producing a product for use by stakeholders, one assessable increment at a time, and in increasing the learning that comes from experience using and building the product. 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, 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 defined by the business as being owned and managed by a Product Owner, who is accountable for value from the product. 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 cross-functional. 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, every Product Increment should be released to some constituency that actually uses it. The approved Product Increment can be delivered 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 be the Greatest Value possible.

At the end of the Sprint, the team should also hold a Sprint Retrospective to review the process by which the increment was built.

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

Picture from: