Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười người mới học Scrum câu "Product Backlog và Sprint Backlog khác nhau ở đâu?", thì có lẽ tới bảy người sẽ trả lời mơ hồ kiểu "một cái dài, một cái ngắn". Câu trả lời đó không sai, nhưng cũng chẳng đủ để qua được kỳ thi PSM I — và quan trọng hơn, nó không đủ để bạn vận hành một Scrum Team thực sự.
Đây là một trong những "cặp khái niệm gây nhầm lẫn" mà đề thi PSM I khai thác triệt để. Người ra đề rất thích những câu hỏi xoáy vào ranh giới: Ai sở hữu cái nào? Ai được phép thay đổi cái nào? Cái nào "thuộc về" cái nào? Khi nào một item "chuyển" từ backlog này sang backlog kia? Nếu bạn nắm khái niệm theo kiểu cảm tính, bạn sẽ rơi vào bẫy ngay.
Trong thực tế làm việc, sự nhầm lẫn này còn nguy hiểm hơn cả trong phòng thi. Tôi đã chứng kiến nhiều team Việt Nam vận hành với một cái Jira board mà ở đó Product Backlog và Sprint Backlog bị trộn làm một, dẫn đến Product Owner can thiệp vào việc của Developers, Sprint mất Focus, và Sprint Goal trở nên vô nghĩa. Hiểu rõ ranh giới giữa hai artifact này không chỉ giúp bạn thi đỗ, mà còn giúp bạn bảo vệ được sự tự quản (self-management) của team.
Bài này tôi sẽ chỉ tập trung vào sự khác biệt và mối quan hệ giữa hai artifact: quyền sở hữu, phạm vi, vòng đời, ai được thay đổi, và cách chúng kết nối với nhau. Các nội dung sâu về từng artifact riêng lẻ (cấu trúc, commitment đi kèm như Product Goal hay Sprint Goal) đã có ở các bài chuyên biệt — ở đây tôi chỉ dùng chúng để làm rõ ranh giới.
Khái niệm cốt lõi
Product Backlog — danh sách công việc của cả sản phẩm
Product Backlog là một danh sách có thứ tự (ordered), nổi lên dần (emergent) chứa tất cả những gì cần thiết để cải thiện sản phẩm. Hãy ghi nhớ những đặc điểm xương sống sau:
- Owner (người chịu trách nhiệm): Product Owner. Đây là điểm tuyệt đối quan trọng. Product Owner sở hữu nội dung, tính sẵn có và thứ tự (ordering) của Product Backlog. Không ai khác được phép yêu cầu Developers làm việc theo một bộ Product Backlog item khác.
- Scope (phạm vi): Tất cả những gì được đề xuất cho sản phẩm trong tương lai — tính năng, cải tiến, sửa lỗi, công việc kỹ thuật. Nó đại diện cho toàn bộ "công việc còn lại" của sản phẩm.
- Lifespan (vòng đời): Tồn tại xuyên suốt vòng đời của sản phẩm. Chừng nào sản phẩm còn được phát triển, Product Backlog còn tồn tại. Nó không bị "reset" sau mỗi Sprint.
- Tính chất: Sống động, không bao giờ "hoàn thành". Nó liên tục được refine, sắp xếp lại, thêm bớt item khi thị trường và hiểu biết thay đổi.
- Commitment đi kèm: Product Goal — mục tiêu dài hạn mà sản phẩm đang hướng tới.
Sprint Backlog — kế hoạch của Developers cho một Sprint
Sprint Backlog là tập hợp gồm ba thành phần: Sprint Goal (tại sao), một bộ Product Backlog item được chọn cho Sprint (cái gì), và kế hoạch hành động (plan) để chuyển giao Increment (làm thế nào). Đặc điểm cốt lõi:
- Owner: Developers. Sprint Backlog là kế hoạch do và cho Developers. Đây là điểm đối xứng quan trọng nhất với Product Backlog. Product Owner không sở hữu Sprint Backlog.
- Scope: Chỉ gồm phần công việc mà Developers dự báo (forecast) có thể hoàn thành trong một Sprint duy nhất, phục vụ cho Sprint Goal.
- Lifespan: Tồn tại trong phạm vi một Sprint. Khi Sprint kết thúc, Sprint Backlog đó cũng kết thúc. Sprint sau bắt đầu với một Sprint Backlog mới.
- Tính chất: Cũng nổi lên dần (emergent) trong Sprint — Developers cập nhật nó hằng ngày khi hiểu biết tăng lên, đặc biệt tại Daily Scrum.
- Commitment đi kèm: Sprint Goal — mục tiêu duy nhất của Sprint, tạo sự gắn kết và Focus.
Mối quan hệ: tập con, không phải "chuyển giao quyền sở hữu"
Đây là chỗ nhiều người hiểu sai nhất. Khi một Product Backlog item được chọn vào Sprint trong Sprint Planning, nó không bị "lấy ra khỏi" Product Backlog và đổi chủ. Bản chất:
- Sprint Backlog chứa một bộ con (subset) các Product Backlog item được Developers chọn cho Sprint, cùng với kế hoạch để hoàn thành chúng.
- Product Owner vẫn chịu trách nhiệm về nội dung của những item đó (ý nghĩa, giá trị), nhưng Developers là người quyết định bao nhiêu item lấy vào và làm thế nào để hoàn thành.
- Trong Sprint, Developers có thể bổ sung chi tiết, tách nhỏ, thêm task vào Sprint Backlog — đây là việc của họ, không cần xin phép Product Owner.
Bảng so sánh nhanh để ghi nhớ
| Tiêu chí | Product Backlog | Sprint Backlog |
|---|---|---|
| Người chịu trách nhiệm | Product Owner | Developers |
| Phạm vi | Toàn bộ sản phẩm, tương lai | Một Sprint duy nhất |
| Vòng đời | Suốt vòng đời sản phẩm | Một Sprint |
| Commitment đi kèm | Product Goal | Sprint Goal |
| Ai quyết "cái gì & thứ tự" | Product Owner | (đã chốt cho Sprint) |
| Ai quyết "bao nhiêu & thế nào" | — | Developers |
| Tạo/cập nhật tại | Liên tục (Refinement) | Sprint Planning + hằng ngày |
Tình huống thực tế
Ví dụ 1 — Tiki và cái bẫy "một board làm tất"
Giả định một nhóm phát triển tính năng thanh toán tại một công ty thương mại điện tử lớn như Tiki. Họ dùng một board Jira duy nhất, và Product Owner tên Lan có thói quen: mỗi sáng vào board, thấy ticket nào "ngon" thì kéo thẳng vào cột "In Progress" của Sprint đang chạy, rồi nhắn Slack cho Developers "ưu tiên cái này nhé em".
Hậu quả sau hai Sprint: team liên tục trễ Sprint Goal. Vì mỗi khi Lan kéo thêm item vào giữa Sprint, Developers buộc phải gánh thêm việc ngoài kế hoạch họ đã forecast. Cảm giác "không bao giờ xong" lan khắp team.
Diễn giải: Lan đang nhầm lẫn vai trò của hai backlog. Việc thêm/sắp xếp item ở Product Backlog là quyền của Product Owner — hoàn toàn đúng. Nhưng Sprint Backlog sau khi đã được chốt trong Sprint Planning là tài sản của Developers. Product Owner không được tự ý nhét việc vào Sprint Backlog. Nếu thật sự có việc khẩn cấp, Lan nên thương lượng với Developers về phạm vi (scope) — và nếu việc mới làm Sprint Goal trở nên vô nghĩa, thì lựa chọn theo Scrum là hủy Sprint, chứ không phải âm thầm phình Sprint Backlog.
Bài học: Một công cụ chung không xóa bỏ ranh giới quyền sở hữu. Product Backlog "vào" được, ai cũng đề xuất, Product Owner sắp xếp; Sprint Backlog thì sau khi chốt là "khu vực tự quản" của Developers.
Ví dụ 2 — Startup fintech 8 người ở TP.HCM và câu hỏi "item này nằm ở backlog nào?"
Một startup ví điện tử nhỏ ở Quận 1 có Product Backlog khoảng 180 item. Trong Sprint Planning cho Sprint 14 (2 tuần), Developers chọn 12 item phục vụ Sprint Goal "Cho phép người dùng liên kết tài khoản ngân hàng qua OTP". Họ chia 12 item này thành khoảng 40 task nhỏ.
Giữa Sprint, một Developer phát hiện cần thêm một bước xử lý timeout cho OTP — một task chưa từng có khi lập kế hoạch. Bạn ấy hỏi Scrum Master: "Em phải tạo Product Backlog item mới và xin Product Owner duyệt không?"
Diễn giải: Không cần. Task xử lý timeout này là công việc kỹ thuật phát sinh để hoàn thành item đã có trong Sprint — nó thuộc về Sprint Backlog và Developers tự thêm vào. Sprint Backlog vốn dĩ emergent, được cập nhật hằng ngày. Ngược lại, nếu giữa Sprint khách hàng yêu cầu thêm tính năng "liên kết qua thẻ tín dụng" — đó là phạm vi sản phẩm mới, thuộc về Product Backlog, Product Owner quản lý, và sẽ được cân nhắc cho các Sprint sau.
Bài học: Hãy hỏi đúng câu — "Việc này phục vụ hoàn thành cái đã cam kết trong Sprint, hay là phạm vi sản phẩm mới?". Phục vụ Sprint hiện tại thì vào Sprint Backlog (Developers chủ động). Phạm vi sản phẩm mới thì vào Product Backlog (Product Owner sắp xếp).
Ví dụ 3 — Đề thi PSM I và cái bẫy "ai cập nhật Sprint Backlog?"
Một học viên của tôi kể lại câu hỏi gần như nguyên văn trong đề luyện: "Ai chịu trách nhiệm sắp xếp thứ tự (ordering) các item trong Product Backlog?" — bạn ấy trả lời nhanh "Developers", và sai.
Cùng đề đó có câu đối xứng: "Trong Sprint, ai có thể cập nhật Sprint Backlog?" — bạn ấy đoán "Product Owner", và lại sai.
Diễn giải: Hai câu này là cặp đối xứng kinh điển mà đề PSM I dùng để phân loại thí sinh. Đáp án "by the book":
- Sắp xếp thứ tự Product Backlog → Product Owner (có thể ủy quyền cho người khác làm, nhưng vẫn chịu trách nhiệm).
- Cập nhật Sprint Backlog trong Sprint → chỉ Developers, vì đó là kế hoạch của họ.
Bài học: Hãy gắn cứng trong đầu cặp ánh xạ: Product Backlog ↔ Product Owner (cái gì & thứ tự); Sprint Backlog ↔ Developers (bao nhiêu & thế nào). Mọi câu hỏi xoáy vào quyền sở hữu đều quy về cặp này.
Hướng dẫn từng bước
Khi gặp một câu hỏi (trong thi hoặc trong công việc) liên quan đến hai backlog, hãy đi theo quy trình bốn bước:
- Xác định "tầng" của vấn đề. Hỏi: chuyện này nói về toàn bộ sản phẩm hay về một Sprint cụ thể? Tầng sản phẩm → Product Backlog. Tầng Sprint → Sprint Backlog. Đây là bước phân loại đầu tiên, gạt được nửa số phương án sai.
- Xác định loại quyết định. Câu hỏi đang về "cái gì cần làm và theo thứ tự nào" hay "bao nhiêu việc và làm thế nào"? Loại thứ nhất thuộc Product Owner (trên Product Backlog). Loại thứ hai thuộc Developers (trên Sprint Backlog).
- Kiểm tra thời điểm. Trước Sprint / liên tục → đó là hoạt động trên Product Backlog (Refinement, ordering). Trong Sprint → cập nhật Sprint Backlog là của Developers, và Product Backlog vẫn có thể được Product Owner refine song song.
- Áp ngược về commitment. Nếu vấn đề liên quan tới mục tiêu dài hạn của sản phẩm → Product Goal (Product Backlog). Nếu liên quan tới mục tiêu duy nhất của Sprint → Sprint Goal (Sprint Backlog). Commitment giúp bạn xác nhận mình đang đứng đúng artifact.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ rằng item "chuyển khỏi" Product Backlog khi vào Sprint. Không. Sprint Backlog tham chiếu một tập con các Product Backlog item. Product Backlog vẫn là nguồn chân lý về sản phẩm. Mẹo: hình dung Sprint Backlog "trỏ tới" các item, chứ không "cắt dán" chúng đi.
Lỗi 2 — Cho rằng Product Owner sở hữu Sprint Backlog. Sai phổ biến nhất. Product Owner sở hữu Product Backlog; Sprint Backlog là của Developers. Product Owner tham gia Sprint Planning để làm rõ giá trị và thương lượng phạm vi, nhưng không "ra lệnh" cho Sprint Backlog.
Lỗi 3 — Tin rằng Sprint Backlog cố định sau Sprint Planning. Sai. Sprint Backlog là emergent, cập nhật hằng ngày khi Developers học được điều mới. Cái không nên thay đổi tùy tiện là Sprint Goal, còn kế hoạch và task bên trong thì linh hoạt.
Lỗi 4 — Lẫn lộn "thêm việc kỹ thuật cho item đang làm" với "thêm phạm vi sản phẩm mới". Việc kỹ thuật để hoàn thành item trong Sprint → Sprint Backlog (Developers tự thêm). Tính năng/yêu cầu mới của sản phẩm → Product Backlog (Product Owner quản lý).
Lỗi 5 — Nghĩ Product Backlog "reset" mỗi Sprint. Không. Product Backlog sống suốt vòng đời sản phẩm. Chỉ có Sprint Backlog mới gắn với một Sprint và "kết thúc" cùng Sprint đó.
Mẹo ghi nhớ nhanh cho phòng thi: lặp lại cặp đối xứng — "Product = Owner = toàn sản phẩm = lâu dài; Sprint = Developers = một Sprint = ngắn hạn". Khi phương án trả lời hoán đổi chủ thể, đó gần như chắc chắn là bẫy.
Bài tập thực hành
- Phân loại nhanh. Với mỗi tình huống, hãy ghi rõ thuộc Product Backlog hay Sprint Backlog và ai chịu trách nhiệm:
- Tự kiểm tra ranh giới. Mở board (Jira/Trello/giấy) của một dự án bạn biết. Hãy chỉ ra: đâu là Product Backlog, đâu là Sprint Backlog, và liệu hai vùng này có bị trộn lẫn không. Nếu có, hãy đề xuất một cách tách bạch để bảo vệ self-management của Developers.
- Viết lại quy tắc. Bằng đúng một câu cho mỗi backlog, hãy diễn đạt: ai sở hữu, phạm vi, vòng đời. Nếu bạn viết được trôi chảy mà không tra lại, bạn đã nắm chắc bài này.
Tóm tắt
- Product Backlog: do Product Owner chịu trách nhiệm; chứa mọi thứ đề xuất cho sản phẩm; sống suốt vòng đời sản phẩm; commitment là Product Goal. Product Owner quyết "cái gì & thứ tự".
- Sprint Backlog: do Developers chịu trách nhiệm; chỉ gồm phần việc cho một Sprint; sống trong một Sprint; commitment là Sprint Goal. Developers quyết "bao nhiêu & làm thế nào".
- Sprint Backlog là tập con các Product Backlog item kèm kế hoạch — không phải "đổi chủ" hay "cắt rời" khỏi Product Backlog.
- Sai lầm nguy hiểm nhất trong thực tế: Product Owner can thiệp vào Sprint Backlog. Sai lầm phổ biến nhất trong thi: hoán đổi chủ thể của hai artifact.
- Khi phân vân, đi qua bốn bước: tầng (sản phẩm/Sprint) → loại quyết định (cái gì/bao nhiêu) → thời điểm (liên tục/trong Sprint) → commitment (Product Goal/Sprint Goal).