An Increment is a concrete stepping stone toward the Product Goal. - Scrum Guide
The result of a Sprint is a Product Increment that achieves the Sprint Goal. It represents a movement towards the achievement of the Product Objective, and it respects the Definition of Done.
An Increment does not make sense if it is considered in isolation from the Product Objective. The Increment of a Sprint is integrated into all previous Increments, forming a 100% finished and coherent functional product up to that moment. Nothing is pending; nothing has been half created, nothing will be completed in future Sprints.
This objective is so vital in Scrum that it is preferable not to deliver anything than to deliver an Increment that the customers cannot use. Due to the overwhelmingly detrimental effect and a false sense of progress on the Scrum Team and the stakeholders that a low-quality Increment would have, it would be preferable not to have built an Increment at all. So now you know, it is preferable not to deliver than to deliver things half-finished.
Definition of Done
The commitment that you assume concerning the delivery of an Increment at the end of a Sprint is to comply with the Definition of Done.
The Definition of Done represents the minimum level of quality that a Product Backlog Item or PBI must reach to be considered as part of the Increment. It can be a standard at the organizational level or an agreement at the product level, whether a single team works on it or several teams do.
Any construction that does not respect the Definition of Done will not be part of the Increment and will not be part of the Sprint Review.
You could imagine the Definition of Done as a checklist with all the aspects and characteristics to be evaluated for each of the PBIs of the Sprint Backlog to be considered as finished. This checklist assesses broad aspects of the PBIs; that is, it applies to all PBIs equally.
Acceptance Criteria
Although Scrum does not talk about the use of Acceptance Criteria in PBIs, there is a widespread practice that adopts them from Extreme Programming User Stories and considers them as criteria of each PBI to ensure that the Increment created does what is expected.
If your Scrum Team decides to take this approach and use Acceptance Criteria for PBIs, you must differentiate them from the Definition of Done. Acceptance Criteria are conditions that each particular PBI must meet, and these conditions vary from PBI to PBI. A PBI of a contact form where the acceptance criteria will refer to which fields it must contain, which are required and which are optional, and the texts and messages to be displayed, is not the same as another PBI that refers to the recovery logic password that describes readers of an email, steps of a process, etc.
In parallel to these acceptance criteria for each of these two PBIs, you will have a Definition of Done that would apply to both at the same time, as well as to any other PBI, such as:
- The design must respect the identity guidelines of the website
- It must be in both English and Spanish
- It should work in the three most used browsers
As you can see, the Acceptance Criteria apply only to the PBI to which they belong, while the Definition of Done applies to all the PBIs equally.