Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua các bài về Product Backlog, Sprint Backlog, Increment cùng ba Commitment đi kèm (Product Goal, Sprint Goal, Definition of Done), thì đây chính là lúc "đóng đinh" kiến thức bằng cách giải đề. Trong kỳ thi PSM I, nhóm câu hỏi về Artifacts và Commitments chiếm một tỷ trọng đáng kể — theo kinh nghiệm luyện thi, khoảng 12–18% trong tổng 80 câu sẽ xoay quanh ba artifact và ba commitment. Quan trọng hơn, đây là nhóm câu mà thí sinh Việt Nam hay mất điểm oan nhất, không phải vì khó mà vì dễ nhầm các khái niệm gần giống nhau.
Ví dụ điển hình: Sprint Goal là commitment của Sprint Backlog hay là một phần của Sprint Backlog? Definition of Done có nằm trong Product Backlog không? Ai sở hữu Increment? Những câu hỏi này, nếu bạn chỉ "cảm tính", rất dễ chọn sai. PSM I là kỳ thi "by the book" — câu trả lời đúng luôn là câu khớp chính xác với Scrum Guide 2020, không phải câu hợp lý theo trải nghiệm thực tế của bạn.
Bài này không dạy lại lý thuyết. Bài này là một phòng tập gồm các câu hỏi mô phỏng đúng phong cách đề thi, kèm lời giải chi tiết để bạn hiểu tại sao đáp án đúng là đúng và tại sao các đáp án nhiễu (distractor) lại sai. Hãy làm bài một cách nghiêm túc: che phần đáp án, tự chọn, rồi mới đọc giải thích.
Khái niệm cốt lõi
Trước khi vào câu hỏi, hãy nhắc lại "bản đồ" mà bạn cần thuộc lòng như bảng cửu chương — đây là khung tham chiếu để bạn đối chiếu mọi câu trả lời.
Ba Artifact và ba Commitment ghép cặp
Scrum Guide 2020 nêu rõ: mỗi artifact chứa một commitment để tăng tính minh bạch và làm điểm tựa đo lường tiến độ.
- Product Backlog → commitment là Product Goal (mục tiêu sản phẩm dài hạn).
- Sprint Backlog → commitment là Sprint Goal (mục tiêu của một Sprint).
- Increment → commitment là Definition of Done (định nghĩa "Hoàn thành").
Những đặc tính dễ bị hỏi xoáy
- Sprint Backlog = Sprint Goal (why) + các Product Backlog item được chọn cho Sprint (what) + kế hoạch để giao Increment (how). Sprint Backlog do Developers sở hữu, là kế hoạch rất "highly visible, real-time picture" và được cập nhật suốt Sprint.
- Increment: một Sprint có thể tạo ra nhiều Increment. Một Increment chỉ "có giá trị" khi nó đạt Definition of Done. Increment "additive" — cộng dồn với các Increment trước. Việc trình bày ở Sprint Review không biến nó thành Done; nó phải Done trước đã.
- Product Goal nằm trong Product Backlog, là đích đến mà Scrum Team lập kế hoạch hướng tới. Product Backlog là "emergent" — luôn tiến hóa.
- Definition of Done là một commitment cho Increment. Nếu tổ chức chưa có DoD chuẩn thì Scrum Team phải tự tạo. Nếu có nhiều team trên cùng một sản phẩm, họ phải cùng tuân theo một DoD chung.
- Sprint Goal được tạo ra trong Sprint Planning, là commitment duy nhất cho Sprint, mang lại sự linh hoạt về phạm vi (scope) nhưng không thay đổi mục tiêu.
Tình huống thực tế
Ở đây, thay vì kể chuyện công ty, tôi sẽ dựng các tình huống dạng đề thi lồng trong bối cảnh doanh nghiệp Việt Nam — đúng tinh thần "scenario question" mà PSM I rất ưa dùng.
Tình huống 1 — Tiki và câu chuyện "ghép cặp"
Bối cảnh: Đội phát triển tính năng thanh toán của Tiki (một sàn TMĐT lớn tại Việt Nam) đang chuẩn bị Sprint mới. Linh — Scrum Master — đặt một câu hỏi trong buổi training nội bộ:
> "Mỗi artifact trong Scrum chứa một commitment. Hãy ghép đúng cặp:" > A. Product Backlog → Definition of Done; Sprint Backlog → Sprint Goal; Increment → Product Goal > B. Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done > C. Product Backlog → Sprint Goal; Sprint Backlog → Product Goal; Increment → Definition of Done > D. Product Backlog → Product Goal; Sprint Backlog → Definition of Done; Increment → Sprint Goal
Đáp án đúng: B.
Diễn giải: Đây là câu "must-get" — nếu sai câu này thì cả nhóm artifact bạn sẽ rớt đậm. Phương án A và D đảo lộn DoD và Product Goal; phương án C đảo Product Goal với Sprint Goal. Chỉ B đúng tuyệt đối với Scrum Guide 2020.
Bài học rút ra: Khi gặp câu "matching", đừng đọc cả ba dòng một lúc. Hãy khóa từng cặp chắc chắn nhất trước (Increment → DoD là cặp ít người nhầm nhất), loại ngay các phương án sai cặp đó, rồi mới xét hai cặp còn lại. Kỹ thuật loại trừ này tiết kiệm thời gian và giảm sai sót.
Tình huống 2 — VNG và tranh cãi "ai sở hữu cái gì"
Bối cảnh: Tại VNG, trong một Sprint phát triển tính năng cho ứng dụng Zalo, một Developer mới tên Hùng khẳng định trong Daily Scrum: "Sprint Backlog là của Product Owner, nên muốn đổi việc trong Sprint phải xin phép PO." Quân — Scrum Master — muốn dùng tình huống này ra đề cho buổi ôn thi.
> "Phát biểu nào sau đây ĐÚNG về Sprint Backlog?" > A. Sprint Backlog thuộc về Product Owner và chỉ PO được thay đổi nó. > B. Sprint Backlog thuộc về Developers; họ cập nhật nó suốt Sprint khi hiểu biết tăng lên. > C. Sprint Backlog cố định sau Sprint Planning và không được thay đổi. > D. Sprint Backlog chính là Product Backlog đã được sắp xếp lại.
Đáp án đúng: B.
Diễn giải: Sprint Backlog là của riêng Developers ("by the Developers, for the Developers"). Nó là kế hoạch và bức tranh thời gian thực, được cập nhật liên tục trong Sprint khi nhóm học được điều mới — chứ không hề "đóng băng". Phương án A sai vì gán quyền sở hữu cho PO. Phương án C sai vì Sprint Backlog emergent, luôn được điều chỉnh. Phương án D sai vì Sprint Backlog không phải là Product Backlog sắp xếp lại; nó còn chứa Sprint Goal và kế hoạch thực thi.
Bài học rút ra: Phát biểu của Hùng phản ánh một hiểu lầm rất phổ biến ở doanh nghiệp Việt — coi PO như "sếp giao việc". Trong Scrum, Developers tự quản lý cách thực hiện. PO quyết định cái gì (what) ở cấp Product Backlog, nhưng Sprint Backlog là sân của Developers. Trong phòng thi, hễ thấy phương án nói "PO kiểm soát Sprint Backlog", hãy loại ngay.
Tình huống 3 — FPT Software và bẫy "Increment chưa Done"
Bối cảnh: Một dự án outsourcing tại FPT Software cho khách hàng Nhật Bản. Cuối Sprint, đội demo một tính năng "đã chạy được nhưng chưa qua kiểm thử bảo mật" — vốn là một mục bắt buộc trong DoD. Mai — Scrum Master — đưa ra câu hỏi:
> "Một phần công việc đã chạy demo được nhưng chưa đáp ứng Definition of Done. Theo Scrum Guide, điều nào đúng?" > A. Đó vẫn được tính là một Increment hợp lệ vì đã demo được. > B. Nó không phải là Increment; chỉ công việc đạt DoD mới là Increment có giá trị có thể phát hành. > C. PO có thể quyết định nới lỏng DoD ngay tại Sprint Review để công nhận nó. > D. Nó trở thành Increment ngay khi được trình bày ở Sprint Review.
Đáp án đúng: B.
Diễn giải: Định nghĩa rất rạch ròi: công việc chưa đạt DoD thì không được coi là một phần của Increment, không được trình bày như đã "Done", và phải quay lại Product Backlog cho tương lai. Phương án A và D nhầm "demo được" với "Done" — đây là bẫy kinh điển. Phương án C sai vì DoD không phải thứ "nới lỏng tùy hứng giữa chừng"; nó là commitment tạo nên tính minh bạch về chất lượng.
Bài học rút ra: Ở các dự án outsourcing, áp lực "cho khách thấy đồ" rất lớn, dễ khiến đội demo đồ chưa Done. Nhưng đề thi PSM I luôn đứng về phía "by the book": Done là Done, không có Done 90%. Hãy nhớ cụm từ "valid Increment must meet the Definition of Done".
Hướng dẫn từng bước
Dưới đây là quy trình 6 bước để xử lý bất kỳ câu hỏi nào về Artifacts + Commitments trong phòng thi. Hãy biến nó thành phản xạ.
Bước 1 — Nhận diện artifact/commitment đang được hỏi. Đọc câu hỏi và gạch chân từ khóa: "Product Backlog", "Sprint Backlog", "Increment", "Product Goal", "Sprint Goal", "Definition of Done". Xác định chính xác câu đang xoay quanh đối tượng nào.
Bước 2 — Đối chiếu cặp ghép. Nếu là câu matching, áp dụng ngay bản đồ: Product Backlog–Product Goal, Sprint Backlog–Sprint Goal, Increment–DoD. Khóa cặp chắc chắn nhất trước.
Bước 3 — Kiểm tra quyền sở hữu. Tự hỏi: artifact này của ai? Product Backlog → trách nhiệm của Product Owner (PO quản lý). Sprint Backlog → của Developers. Increment → kết quả của cả Scrum Team nhưng chất lượng do Developers đảm bảo qua DoD. Bất kỳ phương án nào gán sai quyền sở hữu → loại.
Bước 4 — Kiểm tra tính "emergent" và thời điểm. Nhớ rằng Product Backlog và Sprint Backlog đều liên tục tiến hóa. Sprint Goal sinh ra trong Sprint Planning. Product Goal sống trong Product Backlog. Loại các phương án nói artifact "cố định/đóng băng".
Bước 5 — Áp dụng nguyên tắc minh bạch. Mọi artifact tồn tại để tăng transparency. Nếu một phương án làm giảm minh bạch (giấu việc chưa xong, gọi đồ chưa Done là Done), nó gần như chắc chắn sai.
Bước 6 — Loại trừ và chọn câu "by the book". Giữa các phương án còn lại, chọn câu khớp ngôn từ Scrum Guide nhất, không phải câu "thực tế công ty tôi vẫn làm vậy".
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Sprint Goal là "một item trong Sprint Backlog". Sai. Sprint Goal là commitment của Sprint Backlog, là phần "tại sao" (why). Nó không phải một dòng task trong danh sách. Mẹo: hãy hình dung Sprint Goal như tiêu đề mục tiêu, còn các PBI là nội dung bên dưới.
Lỗi 2 — Cho rằng mỗi Sprint chỉ tạo một Increment. Sai. Một Sprint có thể sinh nhiều Increment. Sprint Review không phải lúc "mới có" Increment — Increment có thể được phát hành bất cứ lúc nào trong Sprint, không cần đợi đến cuối.
Lỗi 3 — Coi Definition of Done như Definition of Ready hoặc như "tiêu chí nghiệm thu của từng story". DoD áp cho Increment, là chuẩn chất lượng chung. Acceptance criteria của từng PBI là chuyện khác. (DoR thì thậm chí không phải là phần của Scrum Guide — sẽ bàn ở bài riêng.)
Lỗi 4 — Nghĩ Product Owner "viết" Product Backlog một mình. PO chịu trách nhiệm (accountable) cho Product Backlog hiệu quả, nhưng có thể ủy quyền việc tạo/chỉnh item cho người khác; PO vẫn là người chịu trách nhiệm cuối cùng. Đề thi hay phân biệt "accountable" với "do everything alone".
Lỗi 5 — Tin rằng artifact nào cũng phải có đủ commitment ngay từ đầu Sprint đầu tiên. Commitment tồn tại để định hướng, nhưng Product Goal có thể chưa rõ ràng tuyệt đối; điều quan trọng là Scrum Team luôn hướng về nó.
Mẹo vàng: Khi phân vân giữa hai phương án, hãy chọn phương án nào tăng tính minh bạch và trao quyền tự quản cho team. Scrum Guide gần như luôn nghiêng về hướng đó.
Mẹo thời gian: Câu matching và câu "phát biểu nào đúng" thường giải được dưới 45 giây nếu bạn thuộc bản đồ. Đừng sa lầy — đánh dấu lại câu mơ hồ và quay lại sau.
Bài tập thực hành
Hãy tự làm các câu sau (che đáp án), bấm giờ 8 phút cho 6 câu, rồi đối chiếu.
Câu 1. Commitment nào gắn với Product Backlog? A. Sprint Goal B. Product Goal C. Definition of Done D. Sprint Backlog
Câu 2. Ai là người sở hữu (own) Sprint Backlog? A. Product Owner B. Scrum Master C. Developers D. Stakeholders
Câu 3. Một công việc trong Sprint chưa đạt Definition of Done. Điều gì xảy ra? A. Vẫn được phát hành cho khách hàng. B. Quay lại Product Backlog để xem xét cho tương lai. C. Tự động chuyển sang Sprint sau. D. Bị xóa vĩnh viễn.
Câu 4. Phát biểu nào về Increment là ĐÚNG? A. Mỗi Sprint chỉ tạo đúng một Increment. B. Increment chỉ tồn tại sau Sprint Review. C. Một Sprint có thể tạo nhiều Increment; mỗi cái phải đạt DoD. D. Increment do Product Owner xây dựng.
Câu 5. Sprint Goal được tạo ra ở đâu? A. Trong Sprint Retrospective B. Trong Sprint Planning C. Trong Refinement D. Do Scrum Master đặt trước Sprint
Câu 6. Khi nhiều Scrum Team cùng làm trên một sản phẩm, Definition of Done nên như thế nào? A. Mỗi team tự có DoD riêng hoàn toàn độc lập. B. Họ phải tuân theo một DoD chung cho sản phẩm. C. DoD do khách hàng quyết định từng Sprint. D. Không cần DoD vì đã có nhiều team kiểm tra chéo.
---
Đáp án và giải thích ngắn:
- B — Product Goal là commitment của Product Backlog.
- C — Sprint Backlog là của Developers, do chính họ tạo và cập nhật.
- B — Công việc chưa Done quay về Product Backlog; không được coi là Done và không phát hành.
- C — Một Sprint có thể có nhiều Increment, mỗi Increment phải đạt DoD. Increment không cần đợi đến Sprint Review.
- B — Sprint Goal được hình thành trong Sprint Planning (chủ đề thứ nhất: "Why is this Sprint valuable?").
- B — Nhiều team trên cùng sản phẩm phải tuân theo một DoD chung để Increment tích hợp được và minh bạch về chất lượng.
Tóm tắt
Nhóm câu hỏi Artifacts + Commitments thực ra là nhóm "dễ ăn điểm nhất" nếu bạn thuộc bản đồ ghép cặp và nắm vững quyền sở hữu cùng tính minh bạch. Hãy khắc cốt:
- Ba cặp ghép bất di bất dịch: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done.
- Quyền sở hữu: Product Backlog gắn với trách nhiệm của Product Owner; Sprint Backlog là của Developers; Increment đạt chất lượng nhờ DoD.
- "Done là Done": đồ chưa đạt DoD thì không phải Increment, không demo như đã xong, và quay về Product Backlog.
- Artifact luôn emergent: Product Backlog và Sprint Backlog liên tục tiến hóa, không "đóng băng".
- Một Sprint có thể tạo nhiều Increment, và Increment không cần đợi Sprint Review mới tồn tại.
- Nhiều team, một DoD chung cho cùng một sản phẩm.