Mở đầu — vì sao bài này quan trọng
Nếu bạn đang ôn thi PSM I, hãy chuẩn bị tinh thần: phần Artifacts (tạm dịch là "tạo tác", nhưng mình sẽ giữ nguyên từ tiếng Anh vì đề thi dùng nguyên văn) là một trong những khu vực mà thí sinh Việt Nam thường mất điểm oan nhất. Lý do không phải vì khó, mà vì nhiều người học Scrum theo kiểu "nghe quen tai" — biết Product Backlog là cái danh sách công việc, biết Increment là sản phẩm — nhưng lại không nắm rõ cấu trúc chính xác mà Scrum Guide 2020 định nghĩa.
Điểm mấu chốt mà bài này muốn bạn khắc cốt ghi tâm: trong Scrum có đúng 3 Artifacts, và mỗi Artifact gắn liền với đúng 1 Commitment. Đây là một thiết kế đối xứng rất đẹp mà Scrum Guide 2020 cố tình tạo ra. Nếu bạn nắm được cặp "Artifact ↔ Commitment" này một cách máy móc và chính xác, bạn sẽ trả lời đúng hàng loạt câu hỏi trong đề thi mà không cần suy nghĩ nhiều.
Trong bài này, mình sẽ tập trung chỉ vào bản chất của 3 Artifacts và 3 Commitments, mục đích tồn tại của chúng, và mối quan hệ với tính minh bạch (transparency). Mình sẽ không đi sâu vào từng Artifact riêng lẻ — vì các bài 17 đến 22 sẽ mổ xẻ Product Backlog, Sprint Backlog, Increment, Definition of Done, Product Goal và Sprint Goal một cách chi tiết. Bài 3 là bức tranh tổng thể giúp bạn xâu chuỗi tất cả lại với nhau.
Khái niệm cốt lõi
Artifact là gì trong Scrum?
Theo Scrum Guide 2020, các Artifacts của Scrum đại diện cho công việc (work) hoặc giá trị (value). Chúng được thiết kế để tối đa hóa tính minh bạch (transparency) của thông tin quan trọng. Đây là câu chốt mà bạn cần thuộc lòng: lý do tồn tại của Artifacts không phải là để "lưu trữ tài liệu" hay "quản lý task", mà là để mọi người cùng nhìn vào và có chung một sự hiểu biết về tình hình thực tế.
Vì sao transparency quan trọng đến vậy? Vì Scrum là một framework dựa trên empiricism (chủ nghĩa thực nghiệm — sẽ học sâu ở bài 6). Empiricism nói rằng quyết định phải dựa trên những gì quan sát được. Nhưng nếu thông tin không minh bạch — ví dụ Product Backlog lộn xộn, Increment không thực sự "done" — thì mọi quan sát đều sai, dẫn đến quyết định sai. Nói cách khác, Artifacts là "bề mặt" để Scrum Team và stakeholders đặt mắt vào mà inspect (kiểm tra) và adapt (thích nghi).
3 Artifacts của Scrum
Scrum Guide 2020 định nghĩa chính xác 3 Artifacts, không hơn không kém:
- Product Backlog — danh sách có thứ tự (ordered list) của mọi thứ cần có để cải thiện sản phẩm. Đây là nguồn công việc duy nhất (single source of work) mà Scrum Team đảm nhận. Nó luôn "emerging" — tức luôn tiến hóa, không bao giờ hoàn thiện vĩnh viễn, vì sản phẩm và môi trường luôn thay đổi.
- Sprint Backlog — bao gồm Sprint Goal (why), tập hợp các Product Backlog item được chọn cho Sprint (what), và kế hoạch hành động để giao Increment (how). Đây là Artifact do Developers sở hữu và cập nhật xuyên suốt Sprint.
- Increment — một bước tiến cụ thể, hữu hình hướng tới Product Goal. Mỗi Increment cộng dồn với các Increment trước và phải hoạt động được, đã được kiểm chứng. Một Increment chỉ được coi là Increment khi nó đáp ứng Definition of Done.
3 Commitments — phần mới và đắt giá của Scrum Guide 2020
Điểm cách mạng của Scrum Guide phiên bản 2020 là việc giới thiệu khái niệm Commitment (cam kết). Mỗi Artifact chứa đựng một Commitment để tăng cường tính minh bạch và tập trung (focus), qua đó giúp đo lường tiến độ:
| Artifact | Commitment |
|---|---|
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Definition of Done |
Commitment để làm gì?
Commitment không phải là "lời hứa sẽ hoàn thành đúng deadline" theo nghĩa thông thường — đây là điểm nhiều người Việt hiểu sai vì dịch chữ "commitment" thành "cam kết tiến độ". Trong Scrum, Commitment là điểm tựa để đo lường sự tiến bộ và minh bạch của Artifact tương ứng. Ví dụ:
- Một Product Backlog mà không có Product Goal thì giống như một danh sách việc vặt không có đích đến — bạn không biết mình đang đi về đâu.
- Một Sprint Backlog mà không có Sprint Goal thì chỉ là một mớ task rời rạc — Developers mất đi sự focus và tính linh hoạt khi cần đàm phán phạm vi.
- Một Increment mà không có Definition of Done thì không ai biết "xong" nghĩa là gì — chất lượng trở nên mơ hồ, nợ kỹ thuật tích tụ.
Tình huống thực tế
Ví dụ 1 — Tiki và Product Backlog "không có đích đến"
Hãy tưởng tượng một nhóm phát triển tính năng thanh toán tại một sàn thương mại điện tử lớn ở Việt Nam, ta gọi là nhóm "Payment Squad" của Tiki. Product Backlog của họ có 240 item: sửa lỗi cổng thanh toán, thêm ví điện tử MoMo, tối ưu trải nghiệm trả góp, refactor module hoàn tiền... Mọi thứ đều được liệt kê, có ưu tiên rõ ràng, ai nhìn vào cũng thấy "rất chuyên nghiệp".
Nhưng có một vấn đề: khi Scrum Master hỏi "Product Goal của các bạn quý này là gì?", cả nhóm im lặng. Họ có danh sách công việc, nhưng không có mục tiêu sản phẩm thống nhất. Hậu quả là mỗi Sprint họ làm một thứ khác nhau — Sprint này tập trung ví điện tử, Sprint sau nhảy sang trả góp — không tích lũy thành một bước tiến lớn nào.
Sau khi Scrum Master facilitate một buổi làm việc, Product Owner đặt ra Product Goal: "Tăng tỷ lệ thanh toán thành công ngay lần đầu từ 82% lên 92% trong quý 3." Ngay lập tức, Product Backlog được sắp xếp lại quanh mục tiêu này. Những item không phục vụ mục tiêu bị đẩy xuống dưới.
Bài học rút ra: Product Backlog (Artifact) cung cấp danh sách công việc, nhưng chính Product Goal (Commitment) mới tạo ra sự tập trung và minh bạch về phương hướng. Một Backlog "đẹp" mà thiếu Goal vẫn là một Backlog mù.
Ví dụ 2 — Startup fintech ở Singapore và "Increment giả"
Một startup fintech tại Singapore (gọi là PayLite) có nhóm 6 Developers. Cuối mỗi Sprint, họ demo cho stakeholders những tính năng "đã làm xong". Stakeholders gật gù, hài lòng. Nhưng có một sự thật được giấu kín: phần lớn những gì được demo chỉ chạy trên máy của developer, chưa qua kiểm thử tích hợp, chưa được review bảo mật — vốn là yêu cầu sống còn với một sản phẩm tài chính.
Đến Sprint thứ 5, khi cần phát hành thật ra production, cả nhóm "vỡ trận": hàng loạt tính năng tưởng đã xong hóa ra phải làm lại vì không qua được kiểm thử bảo mật. Họ trượt deadline ra mắt với một ngân hàng đối tác, thiệt hại uy tín nghiêm trọng.
Vấn đề gốc rễ: nhóm này không có Definition of Done rõ ràng. Cái họ gọi là "Increment" thực chất không phải Increment theo định nghĩa Scrum — vì một Increment buộc phải đáp ứng Definition of Done thì mới được công nhận. Sau sự cố, họ thiết lập Definition of Done gồm: code review xong, unit test phủ trên 80%, qua integration test, qua security scan, và deploy được lên môi trường staging. Từ đó, "xong" có nghĩa thật sự là xong.
Bài học rút ra: Definition of Done (Commitment) chính là thứ biến một mớ công việc thành một Increment minh bạch và đáng tin. Không có DoD, transparency của Increment chỉ là ảo giác, và empiricism sụp đổ vì mọi người inspect dựa trên thông tin sai.
Ví dụ 3 — Nhóm gia công phần mềm Đà Nẵng và Sprint Goal bị bỏ quên
Một công ty gia công phần mềm ở Đà Nẵng có nhóm làm dự án cho khách hàng Nhật. Mỗi đầu Sprint, họ chọn ra khoảng 15 Product Backlog item kéo vào Sprint Backlog rồi bắt tay vào làm. Nhưng họ bỏ qua một bước: không bao giờ xác định Sprint Goal.
Giữa Sprint, một item phát sinh khó hơn dự kiến. Vì không có Sprint Goal làm kim chỉ nam, cả nhóm bối rối: "Có nên bỏ item này không? Bỏ thì có ảnh hưởng gì không?" Họ không có cơ sở để đàm phán phạm vi với Product Owner, nên cứ thế cố làm hết tất cả 15 item, dẫn đến quá tải và chất lượng giảm.
Khi Scrum Master giúp nhóm bắt đầu mỗi Sprint bằng một Sprint Goal — ví dụ "Cho phép khách hàng đăng nhập và xem lịch sử đơn hàng" — mọi thứ thay đổi. Khi gặp item khó, nhóm tự hỏi: "Item này có cần thiết cho Sprint Goal không?" Nếu không, họ tự tin đàm phán đẩy nó sang Sprint sau, vẫn đảm bảo Sprint Goal đạt được.
Bài học rút ra: Sprint Goal (Commitment) tạo ra sự focus và linh hoạt. Sprint Backlog có thể thay đổi trong Sprint khi Developers học được điều mới, nhưng Sprint Goal thì giữ nguyên — nó là điểm tựa giúp nhóm điều chỉnh phạm vi mà không lạc hướng.
Hướng dẫn từng bước
Để nắm vững Artifacts và Commitments cho kỳ thi PSM I, hãy đi theo trình tự sau:
Bước 1 — Học thuộc cặp đôi. Trước hết, in vào đầu bảng ánh xạ: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done. Hãy tự kiểm tra bằng cách che một cột và đọc lại cột kia. Đây là kiến thức "phản xạ" bạn cần có.
Bước 2 — Hiểu mục đích chung. Ghi nhớ rằng tất cả Artifacts tồn tại để tối đa hóa transparency, và tất cả Commitments tồn tại để tăng cường focus và đo lường tiến độ. Khi gặp câu hỏi "Tại sao Scrum có Artifacts?", câu trả lời "by the book" luôn xoay quanh transparency.
Bước 3 — Phân biệt cái gì KHÔNG phải Artifact. Luyện tập nhận diện bẫy: Sprint là Event chứ không phải Artifact. Definition of Done, Sprint Goal, Product Goal là Commitments chứ không phải Artifacts. Burndown chart, velocity, user story... đều không phải là Artifact chính thức của Scrum.
Bước 4 — Gắn mỗi Artifact với chủ sở hữu. Product Owner chịu trách nhiệm về Product Backlog. Developers sở hữu Sprint Backlog. Increment là kết quả của cả Scrum Team nhưng được tạo ra bởi Developers. Việc nắm ai sở hữu cái gì giúp bạn trả lời nhiều câu hỏi tình huống.
Bước 5 — Liên hệ với empiricism. Tự hỏi: nếu một Artifact thiếu minh bạch thì điều gì xảy ra? Câu trả lời: việc inspect sẽ cho kết luận sai, dẫn đến adapt sai, và rủi ro tăng lên. Hiểu được mạch logic này, bạn sẽ trả lời được các câu hỏi "vì sao" thay vì chỉ học vẹt.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm số lượng Artifacts. Nhiều người kể thêm Sprint, hoặc Definition of Done vào danh sách Artifacts. Hãy nhớ chắc: đúng 3 Artifacts, và DoD là Commitment chứ không phải Artifact.
Lỗi 2 — Hiểu Commitment là "lời hứa hoàn thành đúng hạn". Trong Scrum, Commitment là điểm tựa để đo tiến độ và tạo focus, không phải cam kết bàn giao một số lượng công việc cố định. Đặc biệt, Sprint Goal không có nghĩa là "phải làm xong 100% item trong Sprint Backlog".
Lỗi 3 — Cho rằng Product Backlog phải "hoàn chỉnh" trước khi bắt đầu. Sai. Product Backlog luôn emerging — nó tiến hóa liên tục. Việc đòi hỏi một Backlog hoàn chỉnh, đầy đủ ngay từ đầu là phản Scrum và là dấu hiệu tư duy predictive (học ở bài 24).
Lỗi 4 — Tách Sprint Goal khỏi Sprint Backlog. Hãy nhớ Sprint Goal là một phần của Sprint Backlog, không phải một thứ tách rời. Tương tự, Product Goal nằm trong Product Backlog.
Mẹo ghi nhớ nhanh: Hình dung ba tầng. Tầng cao nhất là sản phẩm (Product Backlog + Product Goal), tầng giữa là một nhịp làm việc (Sprint Backlog + Sprint Goal), tầng dưới cùng là kết quả hữu hình (Increment + Definition of Done). Ba tầng, mỗi tầng một cặp Artifact-Commitment.
Mẹo làm bài: Khi đề hỏi điều gì đó về "what must a Product Backlog item meet to be released" — câu trả lời thường là Definition of Done. Khi đề hỏi "what provides direction for the Sprint" — đó là Sprint Goal. Hãy gắn từ khóa của câu hỏi với đúng Commitment.
Bài tập thực hành
- Tự kiểm tra trí nhớ: Không nhìn lại bài, hãy viết ra 3 Artifacts của Scrum và Commitment tương ứng của mỗi cái. Sau đó so sánh với bảng ở phần Khái niệm cốt lõi.
- Phân loại nhanh: Với mỗi mục sau, hãy phân loại nó là Artifact, Commitment, Event, hay không thuộc Scrum: (a) Sprint, (b) Definition of Done, (c) Product Goal, (d) Burndown chart, (e) Increment, (f) Daily Scrum, (g) Sprint Backlog. Tự chấm và lý giải vì sao.
- Tình huống áp dụng: Một nhóm tại công ty bạn (giả định) có Product Backlog với 300 item nhưng không ai biết mục tiêu sản phẩm là gì. Hãy viết một Product Goal mẫu cho một sản phẩm bạn quen thuộc (ví dụ một ứng dụng giao đồ ăn), và giải thích Product Goal đó sẽ giúp sắp xếp lại Backlog như thế nào.
- Phân tích lỗi: Quay lại Ví dụ 2 (PayLite). Hãy chỉ ra chính xác Artifact nào đã mất tính minh bạch và Commitment nào bị thiếu, rồi giải thích bằng ngôn ngữ empiricism vì sao điều đó khiến nhóm "vỡ trận".
Tóm tắt
Bài này xây cho bạn bộ khung tổng thể về Artifacts và Commitments — nền tảng để các bài sau đi sâu vào từng phần.
- Scrum có đúng 3 Artifacts: Product Backlog, Sprint Backlog, Increment. Mục đích tồn tại của chúng là tối đa hóa tính minh bạch (transparency).
- Mỗi Artifact gắn với đúng 1 Commitment: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done. Commitments tăng cường focus và giúp đo lường tiến độ.
- Commitment không có nghĩa là "lời hứa hoàn thành đúng hạn". Nó là điểm tựa cho sự minh bạch và phương hướng.
- Cảnh giác các bẫy: Sprint là Event (không phải Artifact); DoD, Sprint Goal, Product Goal là Commitments (không phải Artifacts); Product Backlog luôn emerging, không bao giờ "hoàn chỉnh".
- Tất cả gắn chặt với empiricism: thiếu minh bạch ở Artifacts thì việc inspect và adapt đều sai, rủi ro tăng.