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

    1. 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.
    2. 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.”

    1. 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)

Tiêu Chí Definition of Done (DoD) Acceptance Criteria (AC)
Định Nghĩa Một mô tả chính thức về trạng thái của Increment khi nó đáp ứng các tiêu chuẩn chất lượng. Những điều kiện cụ thể mà một User Story phải đáp ứng để được Product Owner chấp nhận.
Phạm Vi Áp dụng cho toàn bộ đội và tất cả công việc liên quan đến Product Backlog Items & Product Increment (User Story, Sprint, hoặc toàn bộ dự án). Áp dụng cho mỗi User Story cụ thể.
Mục Đích Để đảm bảo chất lượng tổng thể và tính hoàn chỉnh của công việc. Để đảm bảo rằng User Story đáp ứng các yêu cầu cụ thể của khách hàng hoặc Product Owner.
Tính Chất Tổng quát, rộng, áp dụng cho tất cả User Stories trong một Sprint. Cụ thể, chi tiết, phụ thuộc vào mỗi User Story.
Ai Định Nghĩa/Tạo Ra? Toàn bộ Scrum team (bao gồm Developers, Product Owner, Scrum Master). Product Owner (với đóng góp từ development team).
Khi Nào Sử Dụng? Vào cuối mỗi Sprint hoặc khi hoàn thành một phần công việc để xác nhận chất lượng. Trong Sprint planning và quá trình phát triển User Story.
Tính Linh Hoạt Ổn định, hiếm khi thay đổi trừ khi đội quyết định điều chỉnh tiêu chuẩn chất lượng. Linh hoạt, thay đổi theo từng User Story hoặc yêu cầu của khách hàng.
Liên Quan Đến Chất Lượng Tập trung vào đảm bảo chất lượng tổng thể của sản phẩm. Tập trung vào việc đáp ứng các yêu cầu cụ thể của mỗi User Story.
Kết Quả Increment đáp ứng các tiêu chuẩn chất lượng và sẵn sàng để phát hành. User Story được Product Owner chấp nhận.

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.