Increment

The Scrum Guide – 2020

An Increment is 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. In order to provide value, the Increment must be usable.

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Work cannot be considered part of an Increment unless it meets the Definition of Done.

© 2020 Ken Schwaber and Jeff Sutherland

Commentary

The increment is ‘countable’, thus the result of a Sprint is potentially granular. This paves to way to release new features separately. It is also important that if an Increment is Done, can be released anytime. This was not clear (or was even implied otherwise) in previous versions of the Scrum Guide, thus we should pay attention to the novelty. These changes increase the flexibility of the framework. To be fair, in a real-life scenario, a Scrum rule would have never stopped anything from going live anytime.

Let’s take a closer look at this chapter!

Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.

A new increment is generally interwoven with the already existing solution. Let’s say a forgot password function adds value to the authentication module but would not stand on its own. Therefore a new Increment to an existing solution should be verified together with the already existing components that were built during the previous Sprints.

In order to provide value, the Increment must be usable.

The previous version of the Guide mentioned not only usable but “inspectable” increments. In a certain sense, inspectability is more generic since an Increment may not be literally usable. A usable Increment is an important requirement of an iteration-based framework. A half-baked solution is not (yet) an Increment. It cannot be released and cannot even be verified. In software development, a 99% ready codebase with 30% test coverage does not fulfil this requirement, such a body of work is not ‘Done’ and cannot function as an Increment. (Hence the agile advice: Stop Starting, Start Finishing.) When a Sprint ends, the item described with such metrics should be redirected to the Product Backlog, with an updated estimation. The Developers should plan their work in a way to complete Product Backlog Items. It is better to deliver 1 finished item than 2 almost-finished items.

Work cannot be considered part of an Increment unless it meets the Definition of Done.

Delivering Done increments is an important requirement for agility. If the Product Owner cannot be sure about the status of the delivery, if the Product Backlog cannot be freely changed, or if the next Sprint is seriously impacted by the work not done, our delivery process is not truly agile. On the other hand, “useable” may not necessarily make sense in certain environments.

Who decides about releasing the Increment(s)?

The Previous versions of the Guide specifically mentioned that the Product Owner is responsible for this decision. This is still applicable. The Product Owner may collaborate with the Developers and the stakeholders to make the best decision, but the Product Owner remains accountable. This rule of Scrum should not be applied in conflict with organizational standards. Accepting an Increment as feasible and releasing it are two different questions. In a DevOps environment with a well-established Definition of Done, the Increment may be immediately releasable. On the other hand, in a highly complex environment, any change to production systems is a challenging endeavour. Requests must comply with stringent requirements and not necessarily from a technical point of view.

One Increment per Sprint or One per Product Backlog Item?

Previous versions of the Scrum Guide did not clearly answer the question. However, it was never forbidden to create a dedicated releasable pack for every Product Backlog Item, which then together form the Increment of the Sprint. And it has not become compulsory either, we can still create a single Increment at the end of the Sprint. When every Product Backlog item receives its own Increment, it comes with certain benefits, for instance, fewer bottlenecks in our process. The same approach makes Kanban powerful, but it may not be applicable to all environments.

Ken Schwaber gives a detailed analysis of this situation on his blog: https://kenschwaber.wordpress.com/2016/10/20/multiple-increment-delivery-within-a-sprint/

Key Takeaways

• A Sprint can result in any number of Increments.
• Increments can be released regardless of the time of the Sprint Review or the end of the Sprint.
• Increments must meet the Definition of Done.
• The product is the sum of the Increments.

The 2020 version of the Scrum Guide brought an important clarification to releasing the value created during a Sprint. The increment became ‘countable’, thus the result of a Sprint is not ‘the increment’ but something more granular. Also, the new version clarifies that an Increment can be ready to release before the end of the Sprint and from Scrum’s point of view can be released if need be.