1. “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”

   (Translation: “The Definition of Done (DoD) is a formal description of the state of the Increment when it meets the necessary quality measures for the product.”)

   Increment: This refers to the completed work in a Sprint that can be released and meets the quality criteria of the product.
   DoD is a tool to determine when an Increment is considered complete and ready for release.
   https://resources.scrumalliance.org/Article/product-increment

   2. The role of DoD in Scrum a. Creating transparency
      DoD helps create transparency by providing all stakeholders (development team, Product Owner, Scrum Master, and customers) with a common understanding of what is considered “done.”
      When a Product Backlog Item meets the DoD, it becomes part of the Increment and can be presented during the Sprint Review.

      b. Ensuring quality
      DoD ensures that all Increments meet the product’s quality standards.
      If a Product Backlog Item does not meet the DoD, it cannot be released or even presented at the Sprint Review. Instead, it will be returned to the Product Backlog for the Product Owner to review in the future.

      c. Supporting release decisions
      When an Increment meets the DoD, it can be released immediately (if necessary) without any additional work.
      This allows the development team and Product Owner flexibility in deciding when to release the product.

   3. How the Definition of Done is created and used
      If a business/organization already has a common DoD, all Scrum teams within that organization must adhere to this DoD at a minimum.
      This ensures consistency in product quality across the organization.
      If the organization does not have an existing DoD, the Scrum team will self-organize and create their own DoD.
      The team’s DoD must align with the product and meet the necessary quality criteria.
      Examples of criteria in a team’s DoD:
   • Code has been reviewed and approved.
   • Unit tests have been written and passed.
   • Documentation has been updated.
   • Work has been deployed to the staging environment.

   The Increment is the result of a Sprint, including all Product Backlog Items that have been completed and meet the DoD.
   When a Product Backlog Item meets the DoD, it becomes part of the Increment and can be released.
   The moment Product Backlog Items meet the DoD is when the Increment is created.
   When it comes to DoD, people often think of quality criteria because:
   DoD ensures that the product meets quality standards before being released.
   Criteria such as code review, unit tests, and integration testing aim to enhance product quality.
   DoD helps avoid situations of “half-completed” or “not ready for release.”

   4. Example of DoD
      Here is a specific example of DoD:
   • Code has been reviewed and approved: All new code must be reviewed by at least one team member.
   • Unit tests have been written and passed: Unit tests must cover at least 80% of the code.
   • Documentation has been updated: Technical documentation and user guides must be updated.
   • Work has been deployed to the staging environment: Features must be deployed and tested in the staging environment.

   II. What is Acceptance Criteria? Purpose and scope of AC?

   1. Definition of Acceptance Criteria (AC)
      Acceptance Criteria (AC) is a set of specific conditions that a Product Backlog Item (PBI) or User Story must meet to be considered complete and accepted by the Product Owner or customer.

   Purpose: AC helps clarify the requirements of each User Story, ensuring that the development team and Product Owner have a shared understanding of what needs to be accomplished.

   The Role of Acceptance Criteria in Scrum

   a. Clarifying Requirements
   Acceptance Criteria (AC) help clarify the requirements of each User Story by providing specific criteria that the feature must meet.
   For example, for the User Story “Users can log in,” the AC may include:

   • Users enter their email and password to log in.
   • The system displays an error message if the login information is incorrect.
   • Users can click “Forgot Password” to receive a password reset email.

   b. Ensuring Consensus
   AC helps ensure that the development team and the Product Owner have a common understanding of the requirements of the User Story.
   This helps avoid misunderstandings and ensures that the feature is built as expected.

   c. Supporting Testing
   AC serves as a basis for creating test cases for functional testing.
   For example, based on the AC of the User Story “Login,” the QA team can create test cases such as:

   • Testing successful login with a valid email and password.
   • Testing error messages when entering an incorrect password.
   • Testing the “Forgot Password” feature.

   3. How Acceptance Criteria Are Created and Used
   The Product Owner is primarily responsible for defining the AC, as they have the best understanding of customer requirements and business needs.
   However, the development team also participates in this process to ensure that the AC is technically feasible and aligns with the team’s capabilities.
   AC is used during the Sprint Planning process to help the team understand the requirements of each User Story.
   AC is also used during development to guide the team in building the feature according to the requirements.
   Finally, AC is used during testing to confirm that the feature has met the requirements.

   4. Specific Example of Acceptance Criteria
   Here is a specific example of AC for the User Story “Users can log in”:

   Successful Login:

   • Users enter a valid email and password.
   • The system redirects the user to the dashboard page.

   Failed Login:

   • Users enter an incorrect email or password.
   • The system displays the error message “Email or password is incorrect.”

   Forgot Password:

   • Users click the “Forgot Password” button.
   • The system sends an email containing a password reset link to the registered email address.

   5. The Difference Between Acceptance Criteria and Definition of Done
   Acceptance Criteria (AC):

   • Applies to each specific User Story.
   • Defines the specific conditions that a User Story must meet to be accepted.

   Definition of Done (DoD):

   • Applies to the entire team and all work.
   • Defines the general quality and completion standards.

   ⇒ A User Story is considered complete only when it meets both the Acceptance Criteria (specific requirements) and the Definition of Done (general quality standards).

   6. Why Are Acceptance Criteria Important?

   • Minimizing Risk: AC helps avoid building the wrong feature or missing important requirements.
   • Increasing Transparency: AC clarifies the requirements of each User Story, helping all stakeholders understand what needs to be done.
   • Supporting Testing: AC provides a basis for creating test cases, ensuring that the feature is thoroughly tested.

III. The Difference Between Definition of Done (DoD) and Acceptance Criteria (AC)

| Criteria | Definition of Done (DoD) | Acceptance Criteria (AC) | |———-|—————————|—————————| | Definition | An official description of the state of an Increment when it meets quality standards. | Specific conditions that a User Story must meet to be accepted by the Product Owner. | | Scope | Applies to the entire team and all work related to Product Backlog Items & Product Increment (User Story, Sprint, or the entire project). | Applies to each specific User Story. | | Purpose | To ensure overall quality and completeness of the work. | To ensure that the User Story meets the specific requirements of the customer or Product Owner. | | Nature | General, broad, applicable to all User Stories in a Sprint. | Specific, detailed, dependent on each User Story. | | Who defines/creates? | The entire Scrum team (including Developers, Product Owner, Scrum Master). | Product Owner (with input from the development team). | | When to use? | At the end of each Sprint or when completing a piece of work to confirm quality. | During Sprint planning and User Story development. | | Flexibility | Stable, rarely changes unless the team decides to adjust quality standards. | Flexible, changes according to each User Story or customer requirements. | | Related to Quality | Focuses on ensuring the overall quality of the product. | Focuses on meeting the specific requirements of each User Story. | | Outcome | Increment meets quality standards and is ready for release. | User Story is accepted by the Product Owner. |

Example

DoD includes:

1. Code has been reviewed and approved:
   • All new code must be reviewed by at least one team member.
2. Unit tests have been written and passed:
   • Unit tests must cover at least 80% of the code.
   • All test cases must pass.
3. Documentation has been updated:
   • Technical documentation and user guides must be updated.
4. Integration testing:
   • The login feature must be integration tested with relevant systems (e.g., authentication system, email service).
5. Deployment to staging environment:
   • The feature must be deployed and tested in the staging environment.
6. No critical bugs.

General DoD for all User Stories in the Sprint.
User Story 1: As a user, I want to log into the system using my email and password to access my account.

AC includes:

1. Successful login:
   • User enters valid email and password.
   • The system redirects the user to the dashboard page.
2. Failed login:
   • User enters incorrect email or password.
   • The system displays the error message “Email or password is incorrect.”
3. Forgot password:
   • User clicks the “Forgot password” button.
   • The system sends an email containing a password reset link to the registered email address.
4. Security:
   • Passwords must be encrypted when stored in the database.
   • The system must block login after 5 consecutive failed attempts.

Each User Story requires different AC to be written.