Scrum Framework Fundamentals: Product Increment-EN

This article is part of a series in which we review the fundamentals of Scrum, complemented with infographics that explain them. Other articles: Sprint, Planning, Daily, Review, Retrospective, Product Owner,  Scrum Master, Developers and Backlogs.

Authors: Alonso Álvarez y Patricia Parreira

We can give it many twists and turns, but in the end Scrum is a framework that helps “to generate value through adaptable solutions to complex problems“. This definition, from the official guide, tells us that it is better not to use it for simple, repetitive, predictable problems: it would be an unnecessary complication. On the other hand, the solutions that Scrum helps us to obtain are “adaptable”, which is an advantage in the unstable and frenetic context in which we live. This definition also helps us to rule out many possible problems where Scrum would have no application.

So Scrum makes sense for finding solutions to certain problems, but always with an eye on generating value. Let’s see what that value is.

The Product Increment is the third of the three artifacts defined by Scrum, along with the product and Sprint backlogs. The Increment is the mechanism for delivering value through the Scrum process, and all that is asked of it is that it be “usable” (usable in the original version). But the increment does not arise spontaneously, it is born to fulfill the Product Objective.

The Product Objective

If we recall what we talked about Planning and Backlogs, the work with Scrum is guided by a Product Objective defined and communicated by the Product Owner. This Goal sets the direction of the team’s work, defines what is contained in its backlog, conditions the objective of each Sprint… It is the compass that guides all activity, and also the way to define the value to be obtained.

For this reason, the Product Increment, or rather the solution that makes up the sum of the different increments, must be aligned with this Objective. But let us not think that with each increment what we are doing is to carry out a sequential and purely incremental construction of the product. If we remember the definition at the beginning, it is about generating value with adaptable solutions, which means that as we progress in the discovery of what our customer wants and – above all – what he needs, we may have to change course, even retrace the path.

Scrum is particularly suitable for building products and services that have continuity over time, as opposed to projects with a finite scope and, above all, finite time and effort. In the life of a product many things can happen that lead to eliminate or modify aspects, features or functionalities due to a change in needs, tastes or context (e.g. regulation). The target is a destination that is normally stable but not necessarily static.

The Increment is a concrete step (not “cement” as it appears in the Spanish translation of the Scrum Guide) towards the Product Objective. Each step involves learning, so the Increment is also a vehicle for inspection and adaptation by allowing to get feedback from customers and users and with it to generate learning and introduce adjustments.

It is important to note that the Increment is not something that is delivered or released only at the end of the Sprint. Although it is true that the final review is done on all the work done, there is nothing to prevent a previous delivery of the value generated during the Sprint if necessary. If the stakeholders need it before and it is available, why not deliver it to them?

DoD

In Scrum there are three artifacts defined: Product Backlog, Sprint Backlog and Product Increment. Each of these artifacts has associated commitments: Product target and Sprint target are those of the two backlogs respectively.

The specific commitment to Incremental Product is the DoD (Definition of Done).

This is a series of criteria that, when applied to the completed work, allows deciding whether or not it is part of the Increment. That is, even if work has been done during the Sprint on some feature, need or functionality, it can only end up being part of the Increment that is delivered if it meets the criteria that have been set.

The DoD is “a formal description of the status of the Increment when it meets the required quality measures for the product. required quality measures for the product”. It is the way to determine whether or not a piece of work is part of the increment, not just the fact that it was performed during the Sprint.

This DoD should be known by everyone in the team, it is a way to promote transparency, one of the pillars of Scrum. It is also a way to understand why a work item ends up being part of the Increment or not. Strictly speaking, and according to the Guide, if a work item does not meet the DoD, it reverts to pending work status and is not even presented in the Review at the end of the Sprint.

There should always be a DoD known to everyone on the team. It may be that there is one defined in a standardized way by the organization. In that case the Scrum Team should follow it, like the rest of the teams. If there is not, the team should define its own. If several teams are working on the same product or service, they should apply a common DoD.

Although no details are provided in the Guide, the most common practice is to use a checklist to create the DoD. A checklist is a simple and explicit way to ensure that a set of criteria have been met or a set of steps have been performed. Even if they are well known, even obvious, making them explicit with a checklist avoids the impact of forgetting or overlooking an important step or fact.

DoD should focus primarily on quality and function as a general acceptance criteria for the work, although each work unit may have specific additional criteria.

While DoD is mentioned as part of Scrum, it is by no means a mechanism unique to this framework, and can be applied in all kinds of circumstances where it is necessary to ensure a minimum quality of the work performed.

And, as a bonus… the DoR

DoR, Definition of Ready, is the other side of the coin. It is not part of the Scrum definition but, as you will see, it is equally applicable.

This is a checklist that, in this case, tells us whether we are in a position to tackle a given task. It is a preliminary checklist. It is something similar to what you do before a flight: you check certain parameters of the aircraft before making sure that everything is in order for takeoff.

What use can a DoR have?

For example, it can be the checklist to ensure that we have everything ready before starting the meeting (material distributed in advance, people convened, objectives set, room or means reserved, …). It can also be the list of conditions that a work unit must meet in order to be addressed (traceability, sufficiently documented, aligned with the product target, estimated, …).

The DoR is used much less than the DoD and may have greater variability, but it can be helpful in certain circumstances: for example, if we observe that there is a systematic lack of preparation before carrying out some type of activity, or if there is waiting or blocking due to lack of information or some requirement to start a job.

This idea of DoR and DoD also has application beyond Scrum. Like other concepts of this framework (daily synchronization, the use of backlogs, retrospectives) they can be very useful tools in other circumstances.

Download complete infographic

¿Do you want to know more about Scrum practices?

We recommend the “Agile Fundamentals” training, a 24h course to start learning the knowledge and skills of Scrum and Kanban, accredited by ICAgile.

Go to agile fundamental course