What is a Product Increment?

In scrum, cross-functional teams deliver products and services in brief cycles by breaking large products and services into small pieces known as product increments that can be completed by a cross-functional team in a short timeframe. The output of every sprint is a working product increment. 

The 2020 Scrum Guide defines an increment as ”a concrete stepping stone toward the product goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. To provide value, the Increment must be usable…The entire scrum team is accountable for creating a valuable, useful Increment for every Sprint”. 

Many teams do not understand this concept and still approach product development in the traditional way of build, build, build, then integrate, test, and deploy. Teams build in sprints 1, 2, and 3, and so on and in a later “special” sprint, they integrate everything, test, package, and deliver.

In this traditional approach, teams might break up their work by features, components, services, or architecture building blocks like building the back-end first, then the middle-tier business logic, then the front-end user interface. In each scenario, they reach the end of the sprint with an incomplete increment that is not usable. Only after the much later “special” sprint does the team deliver an integrated and working increment. 

In scrum, a product increment is whatever you previously built, plus anything new you just finished in the latest sprint, all integrated, tested, and ready to be delivered or deployed.

In scrum, a product increment is whatever you previously built, plus anything new you just finished in the latest sprint, all integrated, tested, and ready to be delivered or deployed. Without a usable product increment, development teams are delaying delivery of value and are missing opportunities to get real user feedback and adapt the product to ensure customer satisfaction. On the other hand, incremental releases allow for fast feedback, quicker innovation, continuous improvement, rapid adaptation to change, and more delighted customers.

So, in scrum, you build and test an item in sprint 1, and then in the next sprint, you continue adding new integrated and fully tested functionality to that item. What the team releases after each sprint is often referred to as an iteration. When you build things in this manner, iteratively and incrementally, you always have a working version of your product ready. With iterative development, you can always learn from what you already have, improve on it, and add to it.

You can start with a very thin skeleton of basic integrated end-to-end functionality and then in time, make it more feature-rich based on the learning and feedback that you get from each sprint. 

Remember, if you are doing something only once, you are not iterating. If you are not adding to what you already have, you are not incrementing. 

When you first start with scrum this iterative approach of delivering working, tested, high quality, and potentially shippable product increment every sprint seems impossible. Just trying to finish coding within the sprint is hard enough. How are you supposed to manage also completing unit, integration, and regression testing within the same sprint as well?

Getting there takes time, you'll need to break up the work into small vertical slices and establish a strong agile engineering culture that focuses on building quality into each increment instead of checking for quality later.

Related article: How to Integrate Bug Fixes into your Product Backlog

For more on this, check out these 8 steps to guide your team to technical excellence. You can also strengthen your Definition of Done by using this Definition of Done Canvas by Rickard Jones and John Barratt or use this one in your retrospectives. The key is to continuously improve the quality of your product increment so that your teams can deliver a potentially shippable product increment at the end of each sprint. 

Get articles and videos from scrum and agile pros in your inbox, including our monthly Practical Agility email, subscribe.