Mở đầu — vì sao bài này quan trọng
Trong hành trình ôn thi PSM I, có một câu nói trong Scrum Guide mà rất nhiều học viên đọc lướt qua nhưng lại bị "đánh gục" trong phòng thi:
> "Quality cannot be reduced during a Sprint." (Chất lượng không được phép giảm xuống trong một Sprint.)
Nghe có vẻ đơn giản, nhưng phía sau câu này là cả một triết lý về cách Scrum nhìn nhận chất lượng — một triết lý đi ngược lại trực giác của rất nhiều người làm dự án truyền thống ở Việt Nam. Trong môi trường outsourcing hay agency mà nhiều bạn đang làm, khi deadline đến gần, phản xạ tự nhiên là gì? Là "thôi cứ ship đại đi rồi fix sau", "bỏ qua test cho kịp", "cắt bớt code review". Đó chính là việc đang giảm chất lượng để đổi lấy tốc độ — và đó là điều mà Scrum nói thẳng: không được phép.
Bài này quan trọng vì hai lý do. Thứ nhất, về mặt thi cử: PSM I rất hay ra câu hỏi xoay quanh việc "biến nào trong dự án được phép điều chỉnh, biến nào thì không". Người mới thường chọn sai vì họ nghĩ chất lượng là thứ "linh hoạt". Thứ hai, về mặt thực hành: hiểu đúng vai trò của Definition of Done (DoD) sẽ giúp bạn — với tư cách Scrum Master tương lai — bảo vệ được đội của mình khỏi cái bẫy "nợ kỹ thuật" (technical debt) tích lũy qua từng Sprint cho đến khi cả sản phẩm sụp đổ.
Chúng ta sẽ làm rõ: chất lượng trong Scrum được định nghĩa qua đâu, vì sao nó là baseline chứ không phải variable, và DoD đóng vai trò "người gác cổng chất lượng" như thế nào.
Khái niệm cốt lõi
Chất lượng không phải là một "biến số" có thể đánh đổi
Trong quản lý dự án truyền thống, người ta thường nói về "tam giác sắt" (iron triangle): Scope (phạm vi), Time (thời gian), Cost (chi phí). Khi một góc thay đổi, các góc còn lại phải điều chỉnh. Và trong thực tế, có một "góc thứ tư" thường âm thầm bị hy sinh khi mọi thứ căng thẳng: chất lượng.
Scrum lật ngược tư duy này. Trong Scrum, khi đối mặt với áp lực, biến số được phép điều chỉnh là Scope (phạm vi công việc) — bạn có thể làm ít tính năng hơn trong một Sprint. Nhưng chất lượng của những gì bạn làm thì không được giảm. Một tính năng làm xong phải đạt chuẩn "Done" thật sự, chứ không phải "Done một nửa".
Hãy ghi nhớ công thức tư duy này cho phòng thi: Thà làm ít tính năng nhưng làm cho đến nơi đến chốn, còn hơn làm nhiều tính năng nhưng cái nào cũng dở dang. Đây là tinh thần cốt lõi.
Definition of Done — nơi chất lượng được "đóng dấu"
Vậy "chất lượng" trong Scrum được đo bằng gì? Câu trả lời nằm ở Definition of Done (DoD) — Định nghĩa Hoàn thành.
Theo Scrum Guide 2020, DoD là một mô tả chính thức về trạng thái của Increment khi nó đạt được những tiêu chuẩn chất lượng cần thiết cho sản phẩm. Nói cách khác, DoD chính là bộ tiêu chuẩn chất lượng được viết ra rõ ràng mà mọi phần công việc phải đáp ứng trước khi được coi là "xong".
Điểm mấu chốt mà bạn phải khắc cốt ghi tâm cho kỳ thi:
- Khi một Product Backlog Item đáp ứng DoD, nó trở thành một phần của Increment.
- DoD tạo ra tính minh bạch (transparency) về chất lượng — mọi người đều hiểu giống nhau về nghĩa của từ "Done".
- Nếu một item không đạt DoD, nó không được release và không được trình bày tại Sprint Review như một phần Increment. Nó quay lại Product Backlog.
Vì sao "Quality cannot be reduced during a Sprint"
Câu nói này gắn chặt với một quy tắc khác trong Scrum Guide về Sprint Planning: Developers chọn vào Sprint số lượng công việc mà họ tin có thể hoàn thành — nhưng "hoàn thành" ở đây luôn được hiểu theo nghĩa đạt DoD.
Nếu giữa Sprint, đội nhận ra mình không kịp làm hết, lựa chọn đúng là giảm phạm vi (đàm phán lại scope với Product Owner), chứ tuyệt đối không hạ thấp DoD để "ép" cho các item trông như đã xong. Bởi vì nếu bạn hạ DoD, bạn đang:
- Phá vỡ tính minh bạch — Increment trông "xong" nhưng thực ra ẩn chứa nợ kỹ thuật.
- Tạo ra một Increment không khả dụng (not usable) — vi phạm bản chất của Increment.
- Đánh lừa stakeholder tại Sprint Review về tình trạng thật của sản phẩm.
DoD và mối quan hệ với Increment
Có một liên kết logic mà PSM I rất thích kiểm tra:
> Increment là một bước cụ thể tiến tới Product Goal. Mỗi Increment được cộng dồn vào các Increment trước, và tất cả Increment phải hoạt động cùng nhau (work together). Để đảm bảo giá trị thực, mỗi Increment phải usable (khả dụng). Việc "usable" này được đảm bảo bởi việc đạt DoD.
Tức là: DoD → đảm bảo Increment usable → đảm bảo chất lượng tích lũy không suy giảm qua các Sprint. Đây là chuỗi nhân quả bạn cần thuộc lòng.
Tình huống thực tế
Tình huống 1 — Công ty fintech ở TP.HCM và cái bẫy "Done một nửa"
Một startup fintech tại Quận 1, TP.HCM — tạm gọi là VietPay — đang phát triển tính năng chuyển tiền liên ngân hàng. Sprint kéo dài 2 tuần. Đội Developers gồm 5 người nhận vào Sprint 8 Product Backlog Items.
Đến ngày thứ 8, Scrum Master nhận ra đội sẽ không kịp. Product Owner — vốn xuất thân từ ngành ngân hàng quen với deadline cứng — đề nghị: "Mấy item còn lại cứ code xong phần chính, phần test bảo mật với xử lý lỗi để Sprint sau làm bù, miễn là demo được cho nhà đầu tư tuần này."
Đây chính là đề nghị giảm chất lượng. DoD của VietPay yêu cầu: code được review, có unit test phủ tối thiểu 80%, vượt qua quét bảo mật tự động (security scan), và xử lý được các trường hợp lỗi giao dịch.
Scrum Master đã làm đúng: thay vì hạ DoD, anh facilitate một cuộc trao đổi để giảm scope. Kết quả: đội quyết định chỉ đưa vào Increment 5 item đạt DoD đầy đủ, 3 item còn lại quay về Product Backlog. Tại Sprint Review, họ demo 5 tính năng thực sự dùng được, minh bạch về việc 3 tính năng kia chưa xong.
Bài học: Trong lĩnh vực tài chính, một giao dịch thiếu xử lý lỗi không phải là "tính năng chưa hoàn thiện" — nó là lỗ hổng có thể gây mất tiền thật. Việc bảo vệ DoD ở đây không phải sự cứng nhắc, mà là bảo vệ chính sản phẩm và uy tín của công ty. Ba tháng sau, đội VietPay nhận ra nếu hồi đó họ "ship đại", họ đã release một module chuyển tiền có thể bị khai thác.
Tình huống 2 — Agency outsourcing ở Đà Nẵng và món nợ kỹ thuật tích lũy
Một agency outsourcing ở Đà Nẵng nhận dự án xây dựng nền tảng thương mại điện tử cho khách hàng Singapore. Ban đầu, để "ghi điểm tiến độ" với khách, đội liên tục hạ thấp tiêu chuẩn: không viết test, bỏ qua refactor, copy-paste code để nhanh.
Trong 4 Sprint đầu, biểu đồ tiến độ trông rất đẹp — velocity cao, nhiều tính năng "xong". Khách hàng hài lòng. Nhưng đến Sprint thứ 5, mọi thứ chậm lại đột ngột: mỗi tính năng mới đều làm vỡ tính năng cũ, bug tái xuất hiện liên tục, không ai dám sửa code vì sợ "đụng vào là sập". Velocity rớt thê thảm.
Nguyên nhân: trong 4 Sprint đầu, mỗi Increment "Done" thực ra không usable hoàn toàn, không tích hợp sạch với nhau. Họ đã vi phạm chính xác câu "Quality cannot be reduced during a Sprint". Nợ kỹ thuật tích lũy đến mức lãi suất phải trả còn lớn hơn cả vốn.
Khi một Scrum Master mới được đưa vào, việc đầu tiên anh làm là cùng đội xây dựng lại một DoD nghiêm túc và coi nó là bất khả xâm phạm. Tốc độ "ảo" ban đầu biến mất, nhưng tốc độ thật dần ổn định và bền vững.
Bài học: Giảm chất lượng cho ta cảm giác nhanh trong ngắn hạn, nhưng nó tạo ra một khoản vay với lãi kép. DoD chính là cơ chế phòng ngừa khoản vay đó ngay từ đầu.
Tình huống 3 — Đội product nội bộ và DoD "tiến hóa"
Một công ty SaaS ở Hà Nội có đội product làm phần mềm quản lý nhân sự. Ở giai đoạn đầu khi còn là MVP, DoD của họ khá đơn giản: code review + chạy được trên môi trường staging.
Khi sản phẩm trưởng thành và có khách hàng doanh nghiệp lớn, họ bổ sung thêm vào DoD: phải có automated test, phải đạt chuẩn accessibility, phải qua kiểm thử hiệu năng với 1.000 người dùng đồng thời. Lưu ý: họ chỉ làm DoD chặt hơn theo thời gian, không bao giờ nới lỏng.
Điều này hoàn toàn phù hợp Scrum Guide: DoD có thể tiến hóa khi tổ chức trưởng thành. Một câu hỏi PSM I có thể đánh lừa bạn ở đây — "DoD có cố định mãi mãi không?" Câu trả lời: không, nó có thể được cải tiến (thường tại Sprint Retrospective), nhưng việc cải tiến đi theo hướng nâng chuẩn, không hạ chuẩn giữa chừng để dễ "qua bài".
Bài học: Chất lượng là baseline, nhưng baseline đó có thể được nâng lên theo độ trưởng thành của sản phẩm và đội ngũ.
Hướng dẫn từng bước
Nếu bạn là Scrum Master và muốn dùng DoD để bảo vệ chất lượng đúng tinh thần Scrum, đây là quy trình tư duy:
- Xác nhận DoD đã tồn tại và được hiểu chung. Nếu đội chưa có DoD rõ ràng, hoặc mỗi người hiểu "Done" một kiểu, thì transparency về chất lượng đang bằng không. Hãy facilitate buổi cùng nhau viết DoD.
- Kiểm tra DoD có đang là mức tối thiểu của tổ chức. Nếu tổ chức có chuẩn chung, DoD của đội phải bằng hoặc chặt hơn, không được lỏng hơn.
- Đưa DoD vào Sprint Planning. Khi đội ước lượng khối lượng công việc, phải hiểu "hoàn thành" = "đạt DoD". Điều này ngăn việc đội nhận quá tải rồi cắt chất lượng sau.
- Theo dõi trong Sprint. Khi áp lực thời gian xuất hiện, nhắc đội rằng biến cần điều chỉnh là scope, không phải DoD. Facilitate đối thoại giữa Developers và Product Owner để đàm phán lại phạm vi.
- Áp dụng DoD nghiêm tại "cổng" Increment. Item nào không đạt DoD thì không vào Increment, không demo như đã xong, mà quay về Product Backlog. Không có khái niệm "Done 90%".
- Cải tiến DoD tại Retrospective. Khi đội trưởng thành, hãy đặt câu hỏi: "Tiêu chuẩn chất lượng của chúng ta có cần nâng lên không?" Nhưng cải tiến theo hướng nâng chuẩn, có chủ đích.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi chất lượng là biến số có thể đánh đổi khi gấp. Đây là sai lầm kinh điển. Trong phòng thi, nếu một đáp án gợi ý "giảm chất lượng / hạ DoD để kịp deadline", gần như chắc chắn đó là đáp án sai. Đáp án đúng thường là "giảm scope" hoặc "đàm phán lại với Product Owner".
Lỗi 2 — Nhầm DoD với Acceptance Criteria. Acceptance Criteria là điều kiện chấp nhận riêng cho từng item cụ thể (do thường gắn với chức năng của item đó). DoD là tiêu chuẩn chất lượng chung áp dụng cho mọi item của Increment. Một item phải đạt cả hai. Đừng nhầm lẫn — PSM I hay đưa hai khái niệm này vào cùng một câu hỏi để bẫy.
Lỗi 3 — Nghĩ rằng Scrum Master là người tạo ra DoD. Sai. DoD do Scrum Team xây dựng (hoặc kế thừa từ chuẩn tổ chức). Scrum Master facilitate, không "ban hành". Đây là chi tiết hay bị test.
Lỗi 4 — Cho rằng item "gần xong" vẫn được tính một phần vào velocity. Không có "Done một phần". Item chưa đạt DoD = chưa Done = không phải Increment, dù đã làm 95%.
Mẹo ghi nhớ cho phòng thi:
- "Quality cannot be reduced during a Sprint" → biến điều chỉnh được là Scope, không phải Quality.
- DoD → tạo transparency về chất lượng → đảm bảo Increment usable.
- Không đạt DoD → quay về Product Backlog, không vào Increment, không release.
- DoD có thể nâng chuẩn theo thời gian, không hạ chuẩn giữa Sprint.
- DoD của tổ chức = mức tối thiểu; đội có thể làm chặt hơn.
Bài tập thực hành
Bài tập 1 — Phân tích tình huống. Đội của bạn còn 2 ngày cuối Sprint và 3 item chưa đạt DoD (thiếu test tự động). Product Owner muốn demo cả 3 cho khách. Hãy viết ra 3 lựa chọn hành động và chỉ ra lựa chọn nào đúng tinh thần Scrum, vì sao.
Bài tập 2 — Viết DoD. Giả định bạn là Scrum Master của một đội làm app đặt đồ ăn. Hãy phác thảo một DoD gồm 5–7 mục, bao quát: code review, testing, bảo mật, hiệu năng, và khả năng release. Sau đó tự hỏi: mục nào là "tối thiểu của tổ chức", mục nào đội tự nâng thêm?
Bài tập 3 — Phân biệt khái niệm. Tự giải thích bằng lời của bạn sự khác nhau giữa: (a) Definition of Done, (b) Acceptance Criteria, (c) Sprint Goal. Cho một ví dụ cụ thể cho mỗi khái niệm trên cùng một tính năng "đăng nhập bằng số điện thoại".
Bài tập 4 — Câu hỏi luyện thi. "Giữa Sprint, đội nhận ra khối lượng công việc lớn hơn dự kiến. Họ nên làm gì để vẫn giữ chất lượng?" Hãy tự trả lời, sau đó kiểm tra: đáp án của bạn có nhắc đến việc giảm scope / đàm phán với PO mà KHÔNG hạ DoD không?
Tóm tắt
Bài 37 xoay quanh một nguyên tắc nền tảng của Scrum: chất lượng không phải là biến số có thể đánh đổi, nó là baseline. Câu "Quality cannot be reduced during a Sprint" nói rõ rằng khi áp lực đến, thứ được điều chỉnh là phạm vi công việc (scope), chứ không phải chất lượng.
Cơ chế thực thi nguyên tắc này chính là Definition of Done — bộ tiêu chuẩn chất lượng được viết rõ ràng. DoD tạo ra tính minh bạch về nghĩa của từ "Done", quyết định item nào trở thành Increment, và đảm bảo mỗi Increment đều usable. Item không đạt DoD sẽ quay về Product Backlog, không được release, không được trình bày như đã hoàn thành.
Qua ba tình huống thực tế — fintech VietPay bảo vệ DoD để tránh lỗ hổng giao dịch, agency Đà Nẵng trả giá vì nợ kỹ thuật, và đội SaaS Hà Nội nâng chuẩn DoD theo thời gian — chúng ta thấy rõ: giảm chất lượng cho cảm giác nhanh trong ngắn hạn nhưng tạo lãi kép trong dài hạn. Vai trò của Scrum Master là bảo vệ DoD như một tiêu chuẩn bất khả xâm phạm trong Sprint, đồng thời facilitate việc nâng chuẩn khi đội trưởng thành.
Nắm chắc chuỗi logic DoD → Increment usable → chất lượng tích lũy không suy giảm, và bạn sẽ trả lời đúng phần lớn câu hỏi PSM I liên quan đến chất lượng.