Pattern of the Month: Increment

If you were to observe an Agile or Lean team in action, one thing you might surely expect to witness is the incremental delivery of value. It wouldn’t make much difference whether that value is related to a product being developed or to a service of some kind being offered. You’d still expect to see deliverables being provided early and often, and without much work being batched-up and put in delay. There’d be a minimal leap-of-faith required of stakeholders before they got to see something from their investment.

There are, of course, many other qualities, behaviors, and aspirations which characterize these ways-of-working. Certain teams might optimize flow for example, while others might focus squarely on the mitigation of significant business risk. Most are likely to value collaborative techniques, and time-boxed activities, including iterations. All, one way or another, will surely find ways to inspect and adapt their development process in order to improve it.

These matters will be quite transparent to cross-functional teams — professionals who fully own their engineering method, and who are accountable for it. To stakeholders outside the team boundary, however, the only way in which progress can be empirically evidenced is by the ongoing release of value. The regular delivery of an increment, in other words, can be seen as the defining characteristic of Lean and Agile practice.

What really is an increment, though? In Scrum, each increment is considered to be a first-class artifact, and it is the one most essential to transparency. There is an incontrovertible truth which is revealed by the actual delivery of working product. An increment will evidence genuine progress, however marginal the added value might be. It can be seen as cumulative in so far as each increment will successively build upon its predecessors as the product evolves and emerges. A service increment may be viewed in a similar way given that it too will contribute to and enhance a value stream.

In Scrum, each Sprint must yield a feature-complete increment of release quality. Since each increment is by definition cumulative, there’s nothing to stop multiple increments from being released into a “live” environment throughout a Sprint. Each completed user story might be delivered as an increment, for example, assuming that its acceptance criteria were met and that the Definition of Done for incremental release was satisfied. This practice is encouraged, as it reduces batch sizes still further, and provides earlier opportunities to evaluate deliverables and to inspect and adapt.

An increment ought to be considered in relation to an MVP, or Minimal Viable Product. The term MVP can be found in two rather different contexts. On the one hand, it might refer to the smallest subset of feature-functionality which consumers of a product or service might be willing to use. This class of deliverable could also be described as a Minimal Marketable Feature or Minimum Usable Subset.

Recently, however, the term MVP has also been used to describe the smallest deliverable from which lessons about how a product adds value within its environment can be learned, and a “validated learning loop" closed. A hypothesis will typically be framed and tested. This type of MVP, which has been promoted through the Lean Startup movement, could perhaps be described instead as a Minimal Viable Experiment.

The difference between the two usages of the term MVP may appear to be substantial, given that the first could arguably take several months to develop, while the second might be evaluated in days or minutes. When seen through the lens of incremental delivery, however, the distinction seems rather less critical and we can perhaps discern a continuum between the two perspectives. In Lean and Agile practice, each increment ought to deliver something usable from which empirical evidence can be obtained, and which in turn enables feedback from which useful lessons can be drawn.

Increment is Pattern of the Month at agilepatterns.org

Increment

Intent: Deliver a potentially releasable piece of work at the end of each iteration

Proverbs:

• "Actions speak louder than words."
• "The proof of the pudding is in the eating."

Also Known As:

• Prototype (in the context of evolutionary prototyping)

Motivation: There is a risk that when a system is delivered it will not prove fit for purpose, or that certain features will be delivered too late for a maximum return on investment. This risk can be managed by the regular and timely delivery of system features that have been usefully grouped, and which are potentially releasable in themselves.

Structure: A development team plans a Sprint Backlog with a Product Owner. The Sprint Backlog chosen will be drawn from the Product Backlog, and in line with an agreed Sprint Goal. It will represent those items which the Product Owner considers most appropriate and timely for a return on investment on the project. The team must also be satisfied that they can in fact deliver an increment of corresponding value by the end of the Sprint (iteration) to the Product Owner. Once the Product Owner is in receipt of the increment, he or she may then choose to release it. The value delivered will be reviewed, and the process followed can be retrospectively inspected and adapted to improve value further.

Applicability: Incremental release is appropriate for project work where scope risk and delivery risk are high, and that work can be batched in terms of meaningful intermediate goals. It is less appropriate for Business As Usual work consisting of discrete and isolated changes.

Consequences: Incremental release implies that work will be batched, and that each constituent item may not be delivered prior to that release. Items that could have been delivered earlier than the end of the Sprint will, therefore, have their return on investment delayed.

Implementation: Incremental release is a core feature of Scrum, XP, and DSDM. It is less commonly found in Lean Kanban and DevOps approaches, where continuous integration and deployment techniques are rather more likely to be in use.

See Also:

• Iteration
• Backlog
• Incremental Development, Agile Alliance
• Iterative vs. Incremental Development, by Jeff Sutherland