Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm bài thi thử PSM I và bị trừ điểm ở những câu hỏi "tưởng dễ", thì khả năng cao một trong số đó liên quan đến sự nhầm lẫn giữa Sprint Goal (Mục tiêu Sprint) và Sprint Backlog (Danh sách công việc của Sprint). Đây là một trong những cặp khái niệm bị nhầm lẫn nhiều nhất, không chỉ với người mới mà cả với những người đã đi làm Scrum vài năm.
Lý do sự nhầm lẫn này nguy hiểm là vì cả hai đều "thuộc về Sprint", cả hai đều "do Developers tạo ra trong Sprint Planning", và cả hai đều xuất hiện trong cùng một artifact — Sprint Backlog. Nhiều người gộp chung chúng lại thành "kế hoạch cho Sprint" rồi đánh đồng. Nhưng Scrum Guide 2020 tách bạch rất rõ: Sprint Goal là một commitment (cam kết) gắn với Sprint Backlog, còn Sprint Backlog là một artifact (tạo tác). Chúng có vai trò, tính chất và cách hành xử hoàn toàn khác nhau.
Trong PSM I, người ra đề biết rõ điểm yếu này của thí sinh và thường xuyên gài bẫy. Một câu hỏi có thể hỏi "Cái gì cung cấp sự linh hoạt cho Developers khi tình hình thay đổi?" — đáp án đúng phụ thuộc vào việc bạn có phân biệt được Sprint Goal (cố định) với phạm vi công việc (có thể thương lượng lại). Nắm vững bài này không chỉ giúp bạn qua vài câu thi, mà còn giúp bạn hiểu đúng cách một Sprint thực sự vận hành. Hãy cùng đi sâu.
Khái niệm cốt lõi
Trước khi phân biệt, hãy nắm chắc từng khái niệm theo đúng tinh thần Scrum Guide 2020.
Sprint Goal là gì
Sprint Goal là mục tiêu duy nhất (single objective) cho cả Sprint. Nó trả lời câu hỏi WHY — tại sao Sprint này đáng để thực hiện, và WHAT ở cấp độ giá trị — Sprint này muốn đạt được điều gì cho sản phẩm.
Một vài đặc tính quan trọng:
- Sprint Goal là commitment của Sprint Backlog. Trong Scrum Guide 2020, mỗi artifact gắn với đúng một commitment: Product Backlog gắn với Product Goal, Sprint Backlog gắn với Sprint Goal, Increment gắn với Definition of Done.
- Sprint Goal được tạo ra trong Sprint Planning, là kết quả của sự cộng tác giữa cả Scrum Team. Khi Sprint bắt đầu, nó không thay đổi.
- Sprint Goal tạo nên sự gắn kết (coherence) và tập trung (focus), khuyến khích Scrum Team làm việc cùng nhau thay vì mỗi người làm một việc rời rạc.
- Sprint Goal mang tính ngắn gọn, định hướng giá trị, không phải một danh sách task. Ví dụ: "Cho phép khách hàng thanh toán qua ví MoMo" — đó là một mục tiêu, không phải mười dòng công việc kỹ thuật.
Sprint Backlog là gì
Sprint Backlog là một artifact bao gồm ba thành phần:
- Sprint Goal (Why) — mục tiêu của Sprint.
- Tập hợp các Product Backlog items được chọn cho Sprint (What) — những hạng mục Developers dự định hoàn thành.
- Một kế hoạch khả thi để giao Increment (How) — cách thức thực hiện.
Đặc tính của Sprint Backlog:
- Là kế hoạch của Developers, do Developers, vì Developers (by the Developers, for the Developers). Đây là một bức tranh thời gian thực (real-time picture) về công việc cần làm để đạt Sprint Goal.
- Được cập nhật liên tục trong suốt Sprint khi Developers học hỏi thêm. Phần "What" và "How" có thể thay đổi, được tinh chỉnh, đàm phán lại với Product Owner.
- Có đủ chi tiết để có thể inspect (kiểm tra) tiến độ trong Daily Scrum.
Cốt lõi của sự khác biệt
Hãy ghi nhớ bảng đối chiếu tinh thần này:
| Tiêu chí | Sprint Goal | Sprint Backlog |
|---|---|---|
| Bản chất | Commitment (cam kết) | Artifact (tạo tác) |
| Trả lời câu hỏi | WHY / WHAT (giá trị) | WHAT + HOW (Goal + items + plan) |
| Quan hệ | Nằm bên trong Sprint Backlog | Chứa Sprint Goal |
| Tính ổn định | Cố định trong Sprint | Cập nhật liên tục |
| Số lượng | Duy nhất (một) | Một, nhưng gồm nhiều items |
| Có thể đàm phán lại | Không (về mục tiêu) | Có (về phạm vi/cách làm) |
Vì sao Sprint Goal cố định nhưng phạm vi lại linh hoạt
Đây là điểm "by the book" mà PSM I rất thích hỏi. Scrum Guide nói: trong Sprint, scope (phạm vi) có thể được làm rõ và đàm phán lại giữa Product Owner và Developers khi có thêm hiểu biết. Tuy nhiên, Sprint Goal thì không bị thỏa hiệp — Developers vẫn cam kết đạt nó.
Nói cách khác: nếu giữa Sprint, Developers phát hiện một hạng mục khó hơn dự kiến, họ có thể bỏ bớt hoặc thêm công việc (thay đổi Sprint Backlog items) miễn là vẫn đạt được Sprint Goal. Sprint Goal đóng vai trò "la bàn" giúp quyết định đâu là việc nên giữ, đâu là việc có thể cắt. Không có Sprint Goal, việc cắt giảm phạm vi trở thành tùy tiện và mất phương hướng.
Tình huống thực tế
Ví dụ 1 — Tiki và bài học "cắt phạm vi nhưng giữ mục tiêu"
Giả sử một nhóm Scrum tại Tiki bước vào Sprint với Sprint Goal: "Khách hàng có thể theo dõi trạng thái đơn hàng theo thời gian thực trên app." Trong Sprint Planning, Developers chọn vào Sprint Backlog 6 Product Backlog items: tích hợp API đơn vị vận chuyển, màn hình tracking, push notification, bản đồ shipper, lịch sử trạng thái, và bộ lọc đơn hàng.
Đến ngày thứ 5, nhóm phát hiện API của đối tác vận chuyển trả dữ liệu chậm và thiếu ổn định. Nếu cố làm cả "bản đồ shipper real-time", họ sẽ không kịp. Scrum Master nhắc nhóm quay lại Sprint Goal: mục tiêu là theo dõi trạng thái đơn hàng, chứ không bắt buộc phải có bản đồ shipper. Developers cùng Product Owner đàm phán lại: bỏ "bản đồ shipper" và "bộ lọc" ra khỏi Sprint Backlog cho Sprint này, tập trung vào các item cốt lõi.
Diễn giải: Họ đã thay đổi Sprint Backlog (cắt 2 items) nhưng không thay đổi Sprint Goal. Cuối Sprint, khách hàng vẫn theo dõi được trạng thái đơn — Sprint Goal đạt, dù phạm vi đã co lại.
Bài học rút ra: Sprint Backlog có thể đàm phán lại; Sprint Goal là điểm tựa giúp quyết định cắt cái gì. Trong bài thi, nếu gặp câu "Developers nhận ra không kịp hoàn thành mọi item, họ nên làm gì?" — đáp án đúng theo Scrum là đàm phán lại phạm vi với Product Owner trong khi vẫn giữ Sprint Goal, chứ không phải hủy Sprint hay làm thêm giờ vô tội vạ.
Ví dụ 2 — Startup fintech ở Singapore và sai lầm "Sprint Goal là danh sách task"
Một startup fintech tại Singapore có nhóm Scrum mới thành lập. Trong Sprint Planning, khi Scrum Master hỏi "Sprint Goal của chúng ta là gì?", nhóm trả lời: "Làm xong 8 user stories này." Họ viết Sprint Goal nguyên văn là: "Hoàn thành story #101, #102, #103... đến #108."
Hậu quả xuất hiện ngay tuần đầu. Khi một story bị block bởi yêu cầu pháp lý (compliance), nhóm bối rối không biết nên ưu tiên gì, vì "mục tiêu" của họ chỉ là tích đủ checkbox. Mỗi developer ôm một story riêng, không ai cộng tác vì chẳng có mục tiêu chung để xoay quanh. Daily Scrum biến thành buổi báo cáo trạng thái từng task rời rạc.
Một Agile Coach được mời vào và chỉ ra: danh sách 8 stories đó là phần "What" của Sprint Backlog, không phải Sprint Goal. Họ viết lại Sprint Goal thành: "Người dùng có thể mở tài khoản tiết kiệm và nạp tiền lần đầu trong dưới 3 phút." Ngay lập tức nhóm có một điểm đến chung. Khi một story bị block, họ biết story nào thực sự phục vụ mục tiêu nạp tiền và ưu tiên nó; những thứ ngoài lề được gác lại.
Diễn giải: Sprint Goal không phải là tổng các task. Nó là một câu chuyện giá trị mà các item cùng phục vụ.
Bài học rút ra: PSM I hay gài bẫy bằng cách mô tả một "Sprint Goal" thực ra chỉ là danh sách công việc, rồi hỏi bạn nhận xét. Nếu mục tiêu của bạn chỉ là "làm xong các item", thì bạn đang viết phần What của Sprint Backlog, không phải Sprint Goal.
Ví dụ 3 — Nhóm ngân hàng ở TP.HCM và câu hỏi "ai sở hữu cái gì"
Một ngân hàng tại TP.HCM có Product Owner rất "máu lửa". Giữa Sprint, ông muốn thêm hẳn một tính năng mới vào Sprint vì sếp tổng vừa yêu cầu. Ông tự ý mở công cụ quản lý và thêm 3 task vào Sprint Backlog, đồng thời tuyên bố "đổi luôn Sprint Goal cho phù hợp".
Scrum Master can thiệp và làm rõ hai điều theo Scrum Guide:
- Thứ nhất, Sprint Backlog thuộc về Developers — chỉ Developers mới thêm/bớt công việc của họ. Product Owner có thể trao đổi, đàm phán phạm vi, nhưng không tự ý nhồi task.
- Thứ hai, Sprint Goal đã được Scrum Team thống nhất trong Planning và không đổi giữa Sprint. Nếu mục tiêu của Sprint không còn ý nghĩa với tổ chức, thì lựa chọn theo Scrum là Product Owner có thể hủy Sprint (cancel), chứ không phải lén đổi Sprint Goal giữa chừng.
Diễn giải: Sự nhầm lẫn ở đây không chỉ về "Goal vs Backlog" mà còn về quyền sở hữu. Sprint Backlog là kế hoạch của Developers; Sprint Goal là cam kết chung nhưng cố định.
Bài học rút ra: Ai có quyền chạm vào Sprint Backlog? Developers. Ai quyết định hủy Sprint khi Sprint Goal lỗi thời? Product Owner. Hai vai trò, hai quyền khác nhau — đừng gộp.
Hướng dẫn từng bước
Để không bao giờ nhầm lẫn nữa, hãy áp dụng quy trình tư duy sau mỗi khi gặp một câu hỏi hoặc một tình huống thực tế.
Bước 1 — Hỏi: "Đây là cam kết hay là tạo tác?" Nếu thứ đang nói đến là một mục tiêu, một định hướng giá trị, một câu trả lời cho WHY → đó là Sprint Goal (commitment). Nếu là vật chứa kế hoạch, danh sách item, bức tranh công việc → đó là Sprint Backlog (artifact).
Bước 2 — Xác định quan hệ chứa đựng. Nhắc bản thân: Sprint Goal nằm trong Sprint Backlog. Nếu một câu hỏi ngụ ý chúng tách rời hoàn toàn và ngang hàng, hãy cảnh giác — đó có thể là bẫy.
Bước 3 — Kiểm tra tính ổn định. Hỏi: "Thứ này có được phép thay đổi giữa Sprint không?" Sprint Goal → không (cố định). Phạm vi/items/plan trong Sprint Backlog → có (đàm phán lại, cập nhật liên tục).
Bước 4 — Xác định quyền sở hữu và trách nhiệm. Sprint Backlog do Developers sở hữu và cập nhật. Sprint Goal do cả Scrum Team tạo ra trong Planning; chỉ Product Owner mới được hủy Sprint nếu Goal lỗi thời.
Bước 5 — Quy chiếu về ba bộ ba commitment–artifact. Khi bí, hãy nhớ ba cặp: Product Goal ↔ Product Backlog; Sprint Goal ↔ Sprint Backlog; Definition of Done ↔ Increment. Bộ ba này giúp bạn lập tức định vị Sprint Goal là commitment của Sprint Backlog.
Bước 6 — Diễn đạt lại bằng một câu. Tự nói: "Sprint Goal là lý do và đích đến của Sprint; Sprint Backlog là bản kế hoạch (gồm cả mục tiêu đó, các item, và cách làm) để tới đích." Nếu câu này trôi chảy, bạn đã nắm được.
Lỗi thường gặp & mẹo
Lỗi 1: Coi Sprint Goal và Sprint Backlog là hai thứ song song, ngang hàng. Sai. Sprint Goal là một thành phần của Sprint Backlog. Mẹo: hình dung Sprint Backlog như một chiếc hộp, bên trong có ba ngăn — Goal (Why), Items (What), Plan (How).
Lỗi 2: Viết Sprint Goal thành một danh sách task. "Hoàn thành story A, B, C" không phải Sprint Goal — đó là phần What của Sprint Backlog. Sprint Goal phải nói lên giá trị hoặc kết quả mong muốn. Mẹo kiểm tra: nếu bạn có thể đạt từng task nhưng người dùng vẫn chẳng nhận được giá trị gì rõ ràng, thì "goal" của bạn chưa phải goal.
Lỗi 3: Tưởng Sprint Goal có thể thay đổi giữa Sprint cho "linh hoạt". Sai. Cái linh hoạt là phạm vi (scope), không phải Sprint Goal. Mẹo nhớ: Scope flexes, Goal stays — phạm vi co giãn, mục tiêu đứng yên.
Lỗi 4: Tưởng "không kịp làm xong items" nghĩa là "thất bại Sprint Goal". Không nhất thiết. Bạn có thể bỏ bớt items mà vẫn đạt Sprint Goal (xem Ví dụ Tiki). Một Sprint hoàn thành ít item hơn nhưng đạt Sprint Goal vẫn là Sprint thành công.
Lỗi 5: Nhầm rằng Product Owner sở hữu Sprint Backlog. Không. Product Owner sở hữu Product Backlog. Sprint Backlog thuộc về Developers. PO chỉ tham gia đàm phán phạm vi.
Lỗi 6: Nghĩ rằng một Sprint có thể có nhiều Sprint Goal. Sai. Mỗi Sprint có đúng một Sprint Goal duy nhất (single objective). Nhiều mục tiêu rời rạc sẽ phá vỡ sự tập trung — đây là điểm cốt lõi và thường bị hỏi.
Mẹo thi cử "by the book": Khi câu hỏi nói về "tính linh hoạt", "đàm phán lại", "cập nhật liên tục" → nghĩ tới Sprint Backlog (scope). Khi câu hỏi nói về "cam kết", "không đổi", "tập trung", "lý do của Sprint" → nghĩ tới Sprint Goal.
Bài tập thực hành
Bài 1 — Phân loại. Với mỗi phát biểu, xác định nó mô tả Sprint Goal hay Sprint Backlog: a) "Bức tranh thời gian thực về công việc Developers cần làm." b) "Mục tiêu duy nhất tạo nên sự gắn kết và tập trung cho Sprint." c) "Bao gồm Why, What và How." d) "Là commitment, không thay đổi trong Sprint."
Bài 2 — Sửa lỗi Sprint Goal. Một nhóm viết Sprint Goal như sau: "Làm xong API thanh toán, sửa 5 bug, viết unit test, deploy lên staging." Hãy chỉ ra tại sao đây chưa phải Sprint Goal đúng, rồi viết lại thành một Sprint Goal đúng tinh thần (định hướng giá trị).
Bài 3 — Tình huống quyết định. Giữa Sprint, Developers nhận ra một item phức tạp hơn nhiều so với dự kiến và không thể hoàn thành mọi item đã chọn. Theo Scrum, họ nên làm gì? Giải thích vai trò của Sprint Goal trong quyết định này.
Bài 4 — Câu hỏi kiểu PSM I. "Điều nào sau đây có thể được đàm phán lại giữa Product Owner và Developers trong khi Sprint diễn ra?" A. Sprint Goal B. Độ dài của Sprint C. Phạm vi (scope) của công việc D. Definition of Done
Gợi ý đáp án:
- Bài 1: a) Sprint Backlog; b) Sprint Goal; c) Sprint Backlog (vì nó gồm cả ba); d) Sprint Goal.
- Bài 2: Đây là danh sách task (phần What/How), không phải mục tiêu giá trị. Viết lại ví dụ: "Khách hàng có thể hoàn tất thanh toán đơn hàng bằng thẻ nội địa một cách an toàn."
- Bài 3: Đàm phán lại phạm vi với Product Owner, cắt/điều chỉnh items nhưng giữ Sprint Goal. Sprint Goal đóng vai trò la bàn để quyết định giữ item nào, bỏ item nào.
- Bài 4: C. Sprint Goal cố định; độ dài Sprint và Definition of Done không đàm phán giữa Sprint; chỉ phạm vi công việc mới được làm rõ và đàm phán lại.
Tóm tắt
- Sprint Goal là commitment — mục tiêu duy nhất của Sprint, trả lời WHY, tạo sự tập trung và gắn kết, và không thay đổi khi Sprint đã bắt đầu.
- Sprint Backlog là artifact, gồm ba phần: Sprint Goal (Why) + các items được chọn (What) + kế hoạch giao Increment (How).
- Mấu chốt: Sprint Goal nằm BÊN TRONG Sprint Backlog, không phải hai vật thể ngang hàng.
- Phạm vi (scope) co giãn được — Developers và Product Owner đàm phán lại khi cần — nhưng Sprint Goal đứng yên.
- Sprint Backlog thuộc về Developers; chỉ Product Owner mới được hủy Sprint nếu Sprint Goal trở nên lỗi thời.
- Câu thần chú: "Sprint Goal là điểm đến cố định; Sprint Backlog là con đường có thể điều chỉnh để tới đó."