What's an Increment?

In this blog post we give examples of Increments and explain why it's important to have Done Increments.

Summary

  • An Increment is the latest stable and usable version of a product
  • Professional Scrum Teams create a first Increment during the first Sprint
  • During a Sprint, a professional Scrum Team creates one or more Increments
  • Multiple Scrum Teams working on the same product create integrated Increments

Introduction

In one of our previous posts, we explained why Scrum Teams must create Done Increments in order to get a benefit from using Scrum. In this post, we'd like to dive a little deeper on what an Increment actually is.

What's an Increment

"An Increment is a concrete stepping stone towards the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable." – Scrum Guide1

The term Increment can be confusing, especially to people who are new to Scrum or agile product development. To make this easier to understand, let's borrow a concept from software that we're all familiar with: versions. An Increment is the latest stable version of a product.

"Latest" means that a product is being developed incrementally, with each Increment being an attempt to be more valuable than the previous one, for example through better functionality. "Stable" means that every Increment meets the Definition of Done and is usable by users.

An Increment is the latest stable version of their product that is usable by the users.

Let's look at some examples of Increments.

Examples of Increments

Here are some examples of Increments of various products:

 
As soon as these examples comply with the Definition of Done of their product and are usable by its users, a new Increment is created.

Now, let's come up with some examples that aren't Increments:

  • a project plan
  • a requirements specification
  • an architectural design

These things aren't usable by or valuable for users. And you can't manage the 3 key-risks of product development through these things. Hence they can't be Increments.

When is the first Increment created?

The first Increment should be created right within the first Sprint in order to manage product development key-risks, especially the feasibility risk of the Scrum Team.

This also prevents the Scrum Team from the fallacy of a "Sprint Zero" (to create the Product Backlog, the release plan, and the architecture) and the fallacy of "phased Sprints" (some Sprints to analyze, some Sprints to specify, some Sprints to build, ...). These two common misconceptions won't help use empiricism to create value and manage risks.

The first Increment should be created right within the first Sprint.

Some Scrum Teams and organizations that are not that experienced with Scrum say that a Scrum Team can't create an Increment during their first Sprint(s) as they will first have to create the product foundation or product architecture. While it's often necessary to spend a lot of time on creating a minimal foundation during early Sprints, a Scrum Team needs to create at least one feature every Sprint.

How many Increments can a Scrum Team create?

"Multiple Increments may be created within a Sprint. [...] Work cannot be considered part of an Increment unless it meets the Definition of Done." – Scrum Guide

In order to manage the 3 key-risks of product development, Developers on a Scrum Team create at least one Increment per Sprint. They can, however, create many Increments within a Sprint, each Increment being an update of the previous Increment. Here's what this looks like:

Does each Increment have to be delivered to users?

While Developers create Increments, it's the Product Owner who decides when to deliver an Increment to users. Being accountable for that decision is essential, so the Product Owner can maximize the value of the product. The Product Owner can decide to deliver a single or multiple Increments per Sprint or decide to wait several Sprints, depending on her strategy to maximize value and manage the 3 key-risks of product development.

When the Product Owner decides to deliver the Increment, it's important that it can be delivered to users without further effort. Everything else would cause a delay in time-to-market, potentially resulting in a lost opportunity to maximize product value.

Can Developers do work that doesn't add to the Increment?

"The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals." – Scrum Guide

The work of a Scrum Team and their Developers can be broadly divided into three areas:

  1. Discovering value
  2. Delivering value
  3. Improving their effectiveness

As part of discovering value, a Scrum Team and their Developers seek to learn more about the users, their needs and ways to create value. Their discovery work – for example, user research, competitor analysis, ideation, creating and validating hypotheses – might not become part of an Increment directly but helps the Scrum Team create and deliver valuable Increments as a result.

Regarding the delivery of value, the Developers create and deliver Increments. Their work in this area – for example, designing, building and testing a product feature or improving the product quality by removing technical debt – directly results in a new Increment.

To improve their effectiveness, a Scrum Team "identifies the most helpful changes" during a Sprint Retrospective. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint."1 These improvements might result in work for the Developers that doesn't add to an Increment directly but will help them become more effective in creating Increments.

So, a Scrum Team can do work that doesn't result in an Increment directly, however, all their work should focus on the Product Goal and Sprint Goal in order to maximize value.

What is an Increment in scaled Scrum?

When multiple Scrum Teams work together to create a product, they create integrated Increments. This means that the work of all individual Scrum Teams is combined into an integrated Increment. If the Scrum Teams use the Nexus framework to scale Scrum, the Nexus Integration Team (NIT) is accountable that the Scrum Teams create an integrated Increment at least once every Sprint. Here's an example of what this might look like with three Scrum Teams in a Nexus:

References:

  1. scrumguides.org (accessed: 14-Mar-2022)

Need help creating Increments?