{"id":5373,"date":"2024-05-15T12:49:44","date_gmt":"2024-05-15T11:49:44","guid":{"rendered":"https:\/\/thescrumacademy.com\/?p=5373"},"modified":"2024-05-23T15:19:29","modified_gmt":"2024-05-23T14:19:29","slug":"the-subtle-differences-between-definition-of-done-and-acceptance-criteria","status":"publish","type":"post","link":"https:\/\/thescrumacademy.com\/es\/2024\/05\/15\/the-subtle-differences-between-definition-of-done-and-acceptance-criteria\/","title":{"rendered":"The Subtle Differences Between Definition of Done and Acceptance Criteria"},"content":{"rendered":"

No topic causes more confusion for new, or experienced, Scrum practitioners than the Definition of Done (DoD).\u00a0 To help reduce this confusion, let\u2019s explore what it means to be \u201cusable,\u201d why \u201cin use\u201d is so important for change and how the DoD is different from acceptance criteria.<\/span><\/p>\n

Usable Defined<\/span><\/h3>\n

In Scrum, cross-functional teams commit to deliver a \u201cvaluable, useful Increment every Sprint\u201d.\u00a0 Within the context of a team using Scrum to build software, usable means that the product is \u201cin use\u201d in its intended environment by its intended audience.\u00a0\u00a0<\/span><\/p>\n

So what does \u201cin use\u201d mean?\u00a0 For teams that use Scrum to build software, \u201cin use\u201d means the software has been migrated to the customer\u2019s (or end user\u2019s) environment and people are receiving value from the software.\u00a0 \u201cIn use\u201d does not mean that the software has been handed-off to another team.\u00a0 \u201cIn use\u201d does not mean the software is waiting in some other queue for future integration.\u00a0\u00a0<\/span><\/p>\n

Why is \u201cIn Use\u201d Important?<\/span><\/h3>\n

The requirement to create usable software that is \u201cin use\u201d by the time the Sprint timebox expires is one of those subtle concepts in Scrum that is easy to overlook, but is <\/span>very<\/b> important.\u00a0 When the Scrum Team has \u201cin use\u201d as their objective, this fosters greater transparency regarding the state of the Increment.\u00a0 If the Increment has not been put \u201cin use\u201d by the time the timebox expires, it\u2019s not considered done.\u00a0\u00a0<\/span><\/p>\n

For teams and organizations that want to use Scrum to drive change, \u201cin use\u201d is a very powerful lever to create change.\u00a0 Why?\u00a0 Because it demonstrates to the stakeholders if the Scrum Team can deliver the software within the constraints they define.\u00a0 Anything which hinders the Scrum Team\u2019s ability to put the Increment \u201cin use\u201d must be documented as an <\/span>impediment<\/span><\/a>, <\/span>requiring resolution<\/span><\/a> by the Scrum Team or the broader organization.\u00a0 Without \u201cin use\u201d, organizations have little motivation to make the necessary investments to disrupt the status quo.\u00a0<\/span><\/p>\n

DoD Defined<\/span><\/h3>\n

The DOD is a commitment associated with the Increment.\u00a0 Specifically, it \u201cis a formal description of the state of the Increment when it meets the quality measures required for the product.\u201d\u00a0 The DoD documents the commitment the Developers have made to maintain and improve the intrinsic quality of the Increment.\u00a0<\/span><\/p>\n

For a team using Scrum to build software, the DoD is a concise checklist of the technical tasks, typically six to twelve items, that must be completed for each Product Backlog item.\u00a0 Generally, a DoD for a software team will include technical tasks such as design, analysis, coding, testing, review and some form of documentation.<\/span><\/p>\n

The DoD applies uniformly to all Product Backlog items and remains non-negotiable even when the team, or organization, is under pressure due to time constraints. The Scrum Guide enforces two restrictions related to the DoD:<\/span><\/p>\n

    \n
  1. Product Backlog items that fail to meet the DoD cannot be released to customers or end users.\u00a0 This ensures that the customers and end users always receive a high-quality, usable product.\u00a0 One way to visualize your product is to think of it as a meal and the DoD as the ingredients.\u00a0 Ideally, you would be proud and confident to serve the product to your family because the ingredients, i.e., the DoD, are of high-quality.\u00a0 However, if you would not feed the product to your dog, then it does not deserve to be served up to the customers and end users, i.e., no <\/span>Squirrel Burgers<\/span><\/a>.<\/span><\/li>\n
  2. Product Backlog items that fail to meet the DoD cannot be demonstrated at the Sprint Review.\u00a0 This prevents the Scrum Team from offering misleading indications of progress and discourages them from compromising on quality in order to meet a deadline.\u00a0 While these items may not be demonstrated at the Sprint Review, the Scrum Team must reveal why the DoD was not met.\u00a0 This is to ensure the impediments are revealed and addressed by the stakeholders.<\/span><\/li>\n<\/ol>\n

    The DoD is owned collectively by the Developers and they are \u201crequired to conform to the Definition of Done\u201d at all times.\u00a0 In scenarios when there are multiple Scrum Teams working together on a single product, \u201cthey must mutually define and comply with the same Definition of Done.\u201d\u00a0\u00a0<\/span><\/p>\n

    Acceptance Criteria Defined<\/span><\/h3>\n

    Acceptance criteria (AC) is the information provided to the Scrum Team, often by the Product Owner, to ensure that a Product Backlog item has been implemented correctly and fulfills the relevant function and non-functional requirements.\u00a0 Clear and unambiguous AC are very important for Scrum Teams to prevent misunderstandings and delays.<\/span><\/p>\n

    For example, suppose we are working to develop an ordering system.\u00a0 One AC to this system could be that when a customer submits an order, they receive a notification.\u00a0 However, there are many different ways to implement this AC – email, phone call, or text message.\u00a0 Therefore, in this example the AC would need to be clarified to include how the notification will be delivered.<\/span><\/p>\n

    Distinguishing DoD from Acceptance Criteria<\/span><\/h3>\n

    Now that we have defined DoD and AC, let\u2019s explore the difference between the two, because Scrum practitioners confuse these concepts.\u00a0 Here are three distinctions:<\/span><\/p>\n

      \n
    1. AC documents how the product was designed to meet the customer\u2019s and end user\u2019s needs, i.e., the extrinsic quality of the product.\u00a0 DoD documents what are the engineering tasks the Developers followed to build the product, i.e., the intrinsic quality of the product.<\/span><\/li>\n
    2. AC are specific to individual Product Backlog items and are owned by the Product Owner.\u00a0 DoD applies universally and is owned by the Developers.<\/span><\/li>\n
    3. AC describes how customers or end users would validate if the value contained in the Product Backlog items has been delivered to them.\u00a0 DoD describes how the business would verify if the product was built according to their quality standards.<\/span><\/li>\n<\/ol>\n

      Another error many Scrum practitioners often make is to include the AC as part of the DoD.\u00a0 In effect, requiring customer needs to be satisfied as a precursor to releasing the Increment.\u00a0 While this is a noble objective, it has some drawbacks:<\/span><\/p>\n