Definition of Done – “Thế nào là xong” trong Scrum (PMI-ACP)

Definition of Done – “vạch đích chung” của Scrum Team về chất lượng & mức độ hoàn thành công việc.

Ngôn ngữ • Language

VI

Definition of Done – “Thế nào là xong?”

💡 Bài này dành cho ai?

• Bạn đọc đến đoạn Definition of Done trong bài Scrum Artifacts và thấy hơi mơ hồ.
• Bạn từng rơi vào cảnh: “mình nghĩ là xong rồi mà sếp/bên khách bảo chưa xong”.
• Bạn chuẩn bị thi PMI-ACP và muốn phân biệt rõ Definition of Done vs Acceptance Criteria vs “xong theo cảm tính”.

TL;DR – Definition of Done trong 1 phút

• Definition of Done (DoD) = shared understanding của Scrum Team về việc “khi nào thì công việc thực sự được xem là xong”.
• DoD:
  • Gắn với Increment – Increment chỉ được tính là Done khi đáp ứng DoD.
  • Tạo transparency về chất lượng và mức độ hoàn thành.
  • Thường áp dụng cho mọi Product Backlog Item trong product / project.
• DoD khác với:
  • Acceptance Criteria: điều kiện cụ thể cho từng user story / PBI.
  • Definition of Ready (nếu team dùng): điều kiện trước khi kéo việc vào Sprint.
• Trong PMI-ACP, DoD là keyword quan trọng khi đề hỏi về: quality, “done”, Increment, transparency, exam traps về “đếm việc chưa Done là Done”.

Lối tắt:ECO 2025 · 4 domain

Cho người mới bắt đầu

Gợi ý cách học bài này:

1. Đọc phần ví dụ đời sống ở mục 1.
2. Xem kỹ phần DoD trong Scrum & DoD vs Acceptance Criteria.
3. Trước khi thi, quay lại đọc nhanh Exam patterns & traps.

🤔 Câu hỏi khởi động – Làm sao bạn biết mình “xong việc”?

• Làm cho sếp: “Khi nào thì em coi là đã xong báo cáo?”
• Làm cho mình: “Khi nào thì mình coi là dọn nhà xong?”
• Làm cho khách hàng: “Khi nào thì họ coi là xong website?”

Nếu mỗi người trả lời một kiểu, xung đột là chuyện sớm muộn.
Definition of Done sinh ra để cả team và stakeholder có chung một câu trả lời.

---

1. Câu chuyện đời thường: “Em nghĩ là xong rồi mà…”

Hãy thử vài ví dụ rất đời thường:

• Quay xong một video bài học
  • Khi nào thì “xong” ?
    → Khi bạn đã thu đủ tất cả slide cần nói, không còn đoạn bị lỗi, đã render ra file dùng được.
• Sơn phòng ngủ màu xanh
  • Khi nào thì “xong”?
    → Khi mọi góc tường đều đã lên màu đồng đều, không chỗ loang, không mảng trắng sót lại.
• Viết một tính năng báo cáo cho ứng dụng
  • Khi nào thì “xong” ?
    → Khi code chạy được, xuất đúng báo cáo, đã test các case quan trọng, không còn bug blocker, log & doc cơ bản đã cập nhật.

Điểm chung:

• Người làm công việc (developer, tester, BA, designer…) cần biết rõ tiêu chí để có thể tự tin nói:
  “Tụi em xong rồi” – và khách hàng / sếp cũng gật đầu: “Ừ, đúng là xong”.

Definition of Done chính là bộ tiêu chí đó, nhưng ở cấp team & product, không phải mỗi người một kiểu.

---

---

2. Định nghĩa “chính thống” – Definition of Done là gì?

Theo Scrum (Scrum Guide):

• Definition of Done là mô tả chính thức về trạng thái của Increment khi nó đáp ứng các thước đo chất lượng yêu cầu.
• Nói dễ hiểu hơn:
  • Đó là ngưỡng chất lượng tối thiểu mà Increment phải đạt được để được xem là “Done”.
  • Là shared understanding trong Scrum Team về “Done nghĩa là gì”.

Một vài điểm quan trọng:

• DoD:
  • Giúp team và stakeholder có cùng một định nghĩa về “xong”.
  • Làm rõ những việc luôn phải làm cho mỗi Product Backlog Item (PBI) / Increment, không được “quên cho qua”.
  • Tạo transparency – ai cũng nhìn được chất lượng thực sự.

🌱 Nên có DoD từ rất sớm (đầu product / project) và có thể tiến hoá dần khi team trưởng thành, chất lượng được nâng lên.

DoD và khái niệm “done-done”

Trong nhiều sách luyện thi, bạn sẽ gặp cụm “done” vs “done-done”.

• “Done” đôi khi chỉ là cảm giác chủ quan của người làm: chạy được trên máy mình, code đã merge…
• “Done-done” thường được hiểu là hoàn thành theo Definition of Done – đã qua đủ các bước kiểm tra, đạt chuẩn chất lượng chung và sẵn sàng trở thành một phần của Increment.

Khi thấy đề nhắc đến “done-done” hoặc “really done”, hãy nghĩ ngay đến Definition of Done.

---

3. DoD trong Scrum & PMI-ACP – thuộc về ai, dùng lúc nào?

3.1. Ai chịu trách nhiệm về Definition of Done?

Trong Scrum:

• Cả Scrum Team cùng chia sẻ Definition of Done.
• Developers:
  • Chịu trách nhiệm tuân thủ DoD trong từng Sprint.
  • Mỗi Increment họ tạo ra phải đáp ứng DoD.
• Product Owner:
  • Đảm bảo DoD phản ánh đúng mong đợi của khách hàng / tổ chức về chất lượng.
  • Thường mang các chuẩn của business, compliance, quy định ngành… vào DoD.
• Scrum Master:
  • Facilitate để team đạt shared understanding về DoD.
  • Giúp tổ chức hiểu DoD là gì & tại sao quan trọng.

Ngoài ra:

• Tổ chức có thể đưa ra những chuẩn chất lượng tối thiểu (ví dụ coding standard, security baseline…) – Scrum Team kế thừa vào DoD của mình.

3.2. DoD được dùng ở đâu trong Scrum Events?

• Sprint Planning:
  • Developers ước lượng lượng việc có thể hoàn thành, dựa trên việc biết rằng tất cả việc phải đáp ứng DoD.
• Daily Scrum:
  • Team nói chuyện về tiến độ tới Increment Done – “Done” ở đây chính là Done theo DoD.
• Sprint Review:
  • Những gì không đáp ứng DoD không được trình bày như Increment “hoàn thành”.
• Sprint Retrospective:
  • Team có thể nâng chuẩn DoD khi cảm thấy đã đủ sức giữ chất lượng cao hơn.

Trong PMI-ACP, câu hỏi về “làm sao team biết công việc đã thực sự hoàn thành” hoặc “làm sao tạo transparency về chất lượng” → thường test bạn về Definition of Done.

3.3. DoD ở cấp product vs cấp team

• Mỗi product nên có ít nhất một Definition of Done.
• Nếu có nhiều Scrum Team cùng làm một product, họ nên chia sẻ chung một DoD để Increment nào của team nào cũng ghép vào được, chất lượng đồng đều.
• Các team có thể bổ sung chi tiết cụ thể cho bối cảnh của mình, nhưng không được thấp hơn chuẩn chung của product / tổ chức.

---

4. Definition of Done vs Acceptance Criteria vs Definition of Ready

Đây là chỗ đề thi rất thích gài.

4.1. Definition of Done (DoD)

• Áp dụng ở cấp product / Increment.
• Là ngưỡng chất lượng chung cho tất cả PBI trong phạm vi áp dụng.
• Ví dụ:
  • Code đã được review theo coding standard.
  • Unit test & integration test pass, code coverage tối thiểu X%.
  • Không còn defect mức blocker/critical.
  • Document / API spec / migration script đã cập nhật (nếu chính sách yêu cầu).

4.2. Acceptance Criteria

• Áp dụng cho từng PBI / user story.
• Mô tả:
  “Trong trường hợp A/B/C, hệ thống phải làm X/Y/Z”.
• Ví dụ:
  • “Khi user nhập mật khẩu sai quá 5 lần, khóa tài khoản 30 phút.”
  • “Report phải xuất được file CSV & PDF với đúng các cột A/B/C.”

Tóm lại:

• Acceptance Criteria = “work đúng điều khoản chức năng”.
• DoD = “work đạt chuẩn chất lượng chung”

4.3. Definition of Ready (DoR – nếu có)

Không phải khái niệm chính thức của Scrum, nhưng nhiều team Agile dùng:

• Definition of Ready = tiêu chí để một PBI đủ chín trước khi kéo vào Sprint:
  • Đã có mô tả, acceptance criteria rõ ràng.
  • Dependencies chính đã được làm rõ.
  • Estimate đã được thảo luận.

PMI-ACP có thể nhắc tới Ready/Done, nhưng phần chính vẫn là DoD – hãy luôn nhớ DoD gắn với Increment, còn Acceptance Criteria gắn với từng PBI.

Tóm tắt 1 câu

• DoD – “Đạt chuẩn chất lượng chung chưa?”
• Acceptance Criteria – “Đúng yêu cầu riêng của story này chưa?”
• DoR – “Đủ chín để kéo vào Sprint chưa?”

---

5. Ví dụ Definition of Done & một vài anti-pattern

5.1. Ví dụ DoD cho một team phát triển web/app

Giả sử Scrum Team phát triển một ứng dụng web nội bộ. DoD của họ có thể:

• Code:
  • Code đã được review bởi ít nhất 1 developer khác.
  • Không vi phạm rule “critical” của static code analysis tool.
• Test:
  • Đã có unit test cho logic chính, pass 100% các test case quan trọng.
  • Regression test cơ bản pass, không bug blocker/critical.
• Security & infra:
  • Không để lộ secret trong code / log.
  • Đã deploy lên môi trường staging ổn định.
• Documentation:
  • API document / user guide đã được cập nhật.

Bất kỳ PBI nào không đáp ứng đầy đủ các gạch đầu dòng trên → chưa Done.

5.2. Một vài anti-pattern phổ biến

• Mỗi người trong team hiểu “Done” một kiểu

  • Dev: “Em xong rồi, chạy được trên máy em.”
  • Tester: “Chưa test, chưa log bug.”
  • Khách hàng: “Màn hình chưa đúng thiết kế, flow chưa như đã thống nhất.”
    → Không có DoD chung, mọi người tự suy diễn.

• DoD chỉ nằm trong đầu, không được viết ra & chia sẻ

  • Team “ngầm hiểu”, nhưng người mới join thì loay hoay.
  • Khi đi thi PMI-ACP, câu hỏi sẽ ám chỉ:
    DoD nên được documentation & widely shared trong team.

• Nới lỏng DoD tuỳ hứng để kịp deadline

  • “Thôi Sprint này ta bỏ qua phần test cho kịp giao nha.”
  • Đây là exam trap rất thường gặp:
    → Đáp án đúng thường là giữ DoD, nếu cần thì thương lượng lại scope / deadline, không “hạ chuẩn” cho đủ số lượng.

• Đếm việc chưa đạt DoD là “Done” để báo cáo đẹp

  • Làm vậy velocity sẽ “ảo”, kế hoạch Sprint sau lệch hết.
  • Đây là dấu hiệu thiếu transparency, ngược tinh thần Agile.

---

6. Exam patterns & traps – Definition of Done trong PMI-ACP

Bẫy đề hay gặp

• “Để kịp deadline, team quyết định bỏ qua một số bước trong Definition of Done.”
• “Cho phép đếm các hạng mục chưa test là Done để giữ velocity ổn định.”
• “Product Owner một mình thay đổi DoD giữa Sprint để hợp thức hóa công việc chưa hoàn thành.”
• “Không cần Definition of Done, chỉ cần acceptance criteria là đủ.”
  → Hầu hết những lựa chọn kiểu này đều anti-Agile.

Một số pattern cần nhớ:

• DoD = shared understanding về “Done”, không phải chỉ là checklist riêng của tester.
• Increment chỉ được coi là Done khi đáp ứng DoD – phần chưa đạt DoD vẫn là work-in-progress.
• DoD có thể tiến hoá giữa các Sprint, nhưng không nên sửa lung tung giữa Sprint chỉ để “hợp thức hóa”.
• Acceptance Criteria & DoD bổ trợ nhau, không thay thế nhau.

---

7. Checklist học & tự soi

1. Tự viết 2–3 câu định nghĩa lại Definition of Done theo cách hiểu của bạn.
2. Lấy một project thực tế, thử trả lời:
   • Team hiện tại có DoD rõ ràng chưa?
   • DoD đang được lưu ở đâu? Mọi người có biết không?
3. Lấy một user story, thử phân biệt:
   • Đâu là acceptance criteria của story?
   • Đâu là các bước thuộc DoD chung mà story nào cũng phải qua?

Checklist – Definition of Done (VI)

Tiến độ: 0/5 (0%)

• 01. Giải thích được Definition of Done theo cách đơn giản, dễ hiểu, không quá sách vở.
• 02. Mô tả được vai trò của DoD với Increment và chất lượng sản phẩm.
• 03. Phân biệt rõ DoD, Acceptance Criteria và (nếu có) Definition of Ready.
• 04. Nhận diện được các anti-pattern: nới lỏng DoD, đếm việc chưa đạt DoD là Done.
• 05. Kết nối DoD với transparency, inspect & adapt trong ECO / Blueprint PMI-ACP.

Mini-mock – Definition of Done

Loading questions…

Exam key takeaways – Definition of Done (VI)

• DoD luôn gắn với Increment và phản ánh ngưỡng chất lượng tối thiểu.
• DoD là shared understanding của Scrum Team, không phải checklist riêng của tester.
• Không “hạ chuẩn” DoD để kịp deadline hoặc làm đẹp velocity – đây là anti-pattern quen thuộc trong đề.
• Acceptance Criteria không thay thế DoD; chúng bổ trợ nhau (một cái cho story, một cái cho chất lượng chung).
• Nhiều Scrum Team cùng làm một product → nên dùng chung một DoD để giữ chất lượng đồng nhất.

---

8. Liên hệ ECO / Blueprint PMI-ACP

• Agile Principles & Mindset
  • DoD là công cụ để tạo transparency về chất lượng & mức độ hoàn thành.
• Product / Delivery
  • Increment “Done” theo DoD phản ánh khả năng giao hàng từng bước với chất lượng ổn định.
• Team Performance
  • Scrum Team cùng chia sẻ & tuân thủ DoD thể hiện ownership & self-organization.
• Continuous Improvement / Problem Detection & Resolution
  • Team có thể dùng retrospective để nâng chuẩn DoD dần, phát hiện & xử lý nợ kỹ thuật sớm.

---

Bài liên quan:

Scrum Artifacts

•

Scrum Activities

•

Scrum Roles and Responsibilities

EN

Definition of Done – “When is it really done?”

💡 Who this article is for

• You saw Definition of Done mentioned in the Scrum Artifacts article and want a deeper dive.
• You’ve experienced situations where “you thought it was done, but your boss/customer didn’t.”
• You’re preparing for PMI-ACP and want to clearly distinguish Definition of Done vs Acceptance Criteria vs “done by gut feeling”.

TL;DR – Definition of Done in 1 minute

• Definition of Done (DoD) is the Scrum Team’s shared understanding of “what it means for work to be complete.”
• DoD:
  • Is tied to the Increment – an Increment is Done only when it meets the DoD.
  • Creates transparency about quality and completeness.
  • Typically applies to all Product Backlog Items for a given product/project.
• DoD is different from:
  • Acceptance Criteria: specific conditions for one user story/PBI.
  • Definition of Ready (if used): conditions before pulling work into a Sprint.
• In PMI-ACP, DoD is a key keyword for questions about quality, “done”, Increment, transparency, and exam traps about counting unfinished work as “Done.”

Lối tắt:ECO 2025 · 4 domain

For beginners

Suggested reading path:

1. Start with the everyday examples in section 1.
2. Focus on DoD in Scrum and DoD vs Acceptance Criteria.
3. Before the exam, revisit the Exam patterns & traps section.

🤔 Warm-up question – How do you know you’re “done”?

• Working for your boss: “When can you say this report is done?”
• Doing something for yourself: “When is cleaning the apartment actually done?”
• Delivering to a customer: “When will they consider the website done?”

If everyone answers differently, conflicts are inevitable.
Definition of Done helps the team and stakeholders share the same answer.

---

1. Everyday story: “I thought it was done…”

Consider these simple situations:

• Recording a video lesson
  • When is it “done”?
    → When you’ve covered all planned slides, no broken parts, and you have a final usable file.
• Painting a bedroom blue
  • When is it “done”?
    → When every inch of every wall is evenly painted, with no white spots left.
• Building a reporting feature in an app
  • When is it “done”?
    → When the code runs, produces the correct report, key cases are tested, no blocking defects remain, and basic docs/logs are updated.

Common pattern:

• The people doing the work (developers, testers, BA, designers…) need clear criteria so they can confidently say:
  “We’re done.” – and the customer/boss also agrees: “Yes, this is done.”

Definition of Done is that set of criteria, but at the level of the team & product, not just individual preference.

---

---

2. Official view – What is the Definition of Done?

According to Scrum (Scrum Guide):

• The Definition of Done is a formal description of the state of the Increment when it meets the required quality measures.
• In simpler words:
  • It’s the minimum quality bar that each Increment must satisfy to be considered “Done.”
  • It is a shared understanding in the Scrum Team of what “Done” means.

Key points:

• DoD:
  • Helps the team and stakeholders share the same definition of “done.”
  • Clarifies what must always be done for each Product Backlog Item / Increment.
  • Creates transparency about the true state of quality.

🌱 It’s good to have a DoD early (at product/project start) and let it evolve as the team matures and raises its quality bar.

DoD and the idea of “done-done”

In many exam prep books you’ll see “done” vs “done-done”.

• “Done” sometimes just means someone feels it’s finished: it runs on their machine, the code is merged…
• “Done-done” is usually interpreted as completed according to the Definition of Done – all required checks passed, it meets the common quality bar, and it’s ready to be part of the Increment.

When an exam question mentions “done-done” or “really done”, think Definition of Done.

---

3. DoD in Scrum & PMI-ACP – who owns it, when is it used?

3.1. Who is responsible for the Definition of Done?

In Scrum:

• The whole Scrum Team shares the Definition of Done.
• Developers:
  • Are responsible for adhering to the DoD in each Sprint.
  • Every Increment they create must meet the DoD.
• Product Owner:
  • Ensures the DoD reflects the customer’s/organization’s expectations of quality.
  • Often brings in business, compliance, or regulatory requirements.
• Scrum Master:
  • Facilitates a shared understanding of DoD in the team.
  • Helps the wider organization understand what DoD is and why it matters.

Organizational standards:

• The wider organization may define minimum quality standards (coding, security, compliance…).
• The Scrum Team inherits those into its DoD.

3.2. Where does DoD show up in Scrum Events?

• Sprint Planning:
  • Developers forecast how much they can complete, knowing that all work must meet the DoD.
• Daily Scrum:
  • The team discusses progress toward a Done Increment – “Done” here is “Done according to the DoD.”
• Sprint Review:
  • Work that does not meet the DoD is not presented as a completed Increment.
• Sprint Retrospective:
  • The team may decide to raise the DoD as they grow in capability.

In PMI-ACP, when a question asks “How does the team know work is truly completed?” or “How to make quality transparent?” – the intended concept is usually Definition of Done.

3.3. Product-level vs team-level DoD

• Each product should have at least one Definition of Done.
• If there are multiple Scrum Teams working on the same product, they should share a common DoD so that any Increment from any team fits together and has consistent quality.
• Individual teams may add more specific details for their context, but they must not go below the common product/organizational standard.

---

4. Definition of Done vs Acceptance Criteria vs Definition of Ready

This is a favorite area for exam tricks.

4.1. Definition of Done (DoD)

• Applies at the product/Increment level.
• A common quality bar for all PBIs in scope.
• Example:
  • Code reviewed by at least one other developer.
  • No “critical” findings in static code analysis.
  • Unit and integration tests pass, with minimum coverage X%.
  • No blocker/critical defects open.
  • Docs/API specs/migration scripts updated as per team policy.

4.2. Acceptance Criteria

• Applies to one specific PBI/user story.
• Describes:
  “In scenarios A/B/C, the system must do X/Y/Z.”
• Examples:
  • “If a user enters the wrong password more than 5 times, lock the account for 30 minutes.”
  • “The report must export CSV and PDF with columns A/B/C.”

In short:

• Acceptance Criteria = “Does this item meet its functional expectations?”
• DoD = “Does this item meet the common quality bar?”

4.3. Definition of Ready (DoR – if used)

Not an official Scrum concept, but used by many Agile teams:

• Definition of Ready = conditions for a PBI to be ready to pull into a Sprint:
  • Description and acceptance criteria are clear.
  • Major dependencies are understood.
  • Estimates have been discussed.

PMI-ACP may mention “Ready/Done”, but the main exam focus is DoD – remember: DoD ties to the Increment, while Acceptance Criteria tie to individual PBIs.

One-line summary

• DoD – “Meets the common quality bar?”
• Acceptance Criteria – “Meets this story’s specific expectations?”
• DoR – “Ready enough to pull into the Sprint?”

---

5. Example Definition of Done & common anti-patterns

5.1. Example DoD for a web/app development team

Suppose a Scrum Team builds an internal web application. Their DoD might include:

• Code:
  • Code reviewed by at least one other developer.
  • No critical violations in static code analysis.
• Testing:
  • Unit tests for core logic; all key test cases pass.
  • Basic regression tests pass; no blocker/critical defects.
• Security & infra:
  • No secrets in code/logs.
  • Deployed successfully to a stable staging environment.
• Documentation:
  • API documentation / user guide updated.

Any PBI that does not satisfy all of the above → not Done.

5.2. Common anti-patterns

• Everyone has their own “Done” definition

  • Dev: “It’s Done, it runs on my machine.”
  • Tester: “Not Done, we haven’t tested it.”
  • Customer: “Not Done, the screen and flow don’t match what we agreed.”
    → No shared DoD, only personal assumptions.

• DoD exists only in people’s heads

  • The team “kind of knows”, but new members are confused.
  • Exam-wise, PMI-ACP expects DoD to be documented and shared.

• Lowering the DoD on the fly to hit deadlines

  • “Let’s skip tests this Sprint so we can ship on time.”
  • This is a classic exam trap:
    → The preferred answer is usually to keep the DoD and negotiate scope/dates, not silently lower quality.

• Counting incomplete work as “Done” to make reports look better

  • Velocity becomes fake; future planning breaks.
  • This violates transparency, against Agile principles.

---

6. Exam patterns & traps – Definition of Done in PMI-ACP

Typical traps

• “To meet the deadline, the team decides to ignore some steps in the Definition of Done.”
• “Allow counting untested items as Done to keep velocity stable.”
• “Product Owner changes the DoD alone mid-Sprint to declare partially completed work as Done.”
• “We don’t need a Definition of Done, acceptance criteria are enough.”
  → Most such options are anti-Agile.

Patterns to remember:

• DoD = shared understanding of “Done”, not just a tester’s checklist.
• An Increment is Done only when it meets the DoD – unfinished items remain work-in-progress.
• DoD can evolve across Sprints, but should not be randomly relaxed mid-Sprint just to “look good.”
• Acceptance Criteria and DoD complement each other, they don’t replace each other.

---

7. Checklist & self-reflection

1. Write 2–3 sentences in your own words explaining Definition of Done.
2. For a real project:
   • Does your team have a clear, shared DoD?
   • Where is it documented? Do new members quickly learn it?
3. Pick one user story and separate:
   • Its specific acceptance criteria.
   • The DoD steps that apply to every story/Increment.

Checklist – Definition of Done (EN)

Tiến độ: 0/5 (0%)

• 01. Can explain the Definition of Done in simple, non-academic terms.
• 02. Can describe DoD’s role for the Increment and product quality.
• 03. Can distinguish DoD, Acceptance Criteria, and (if used) Definition of Ready.
• 04. Can recognize anti-patterns: relaxing DoD, counting unfinished work as Done.
• 05. Can link DoD to transparency, inspect & adapt in the PMI-ACP ECO/Blueprint.

Mini-mock – Definition of Done

Loading questions…

Exam key takeaways – Definition of Done (EN)

• DoD is tied to the Increment and represents the minimum quality bar.
• DoD is the Scrum Team’s shared understanding, not just a tester’s checklist.
• Do not lower the DoD just to meet deadlines or keep velocity “stable” – that’s a classic anti-pattern in the exam.
• Acceptance Criteria do not replace the DoD; they complement each other (story-specific vs common quality bar).
• Multiple Scrum Teams working on one product should use a shared DoD to keep quality consistent.

---

8. Linking to ECO / Blueprint domains

• Agile Principles & Mindset
  • DoD is a key tool to create transparency around quality and completion.
• Product / Delivery
  • Increments that are Done according to the DoD show the team’s ability to deliver working software at a stable quality level.
• Team Performance
  • A shared DoD and consistent adherence demonstrate ownership and self-organization.
• Continuous Improvement / Problem Detection & Resolution
  • Teams can use retrospectives to gradually raise the DoD, addressing technical debt early.

---

Related articles:

Scrum Artifacts

•

Scrum Activities

•

Scrum Roles and Responsibilities