Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa kết thúc một buổi Sprint Planning. Team của bạn nhìn vào Sprint Backlog gồm 8 hạng mục công việc, gật đầu, và rồi sếp của bạn — một Project Manager kiểu cũ — bước vào phòng và hỏi: "Vậy là các bạn cam kết sẽ giao đủ 8 cái này cuối Sprint, đúng không?". Cả phòng im lặng. Bạn biết câu trả lời "đúng" sẽ đặt cả team vào một cái bẫy, nhưng nói "không" thì lại sợ bị quy là thiếu trách nhiệm.
Tình huống này diễn ra hằng ngày tại các công ty Việt Nam đang chuyển đổi sang Agile, và nó nằm ngay trung tâm của một trong những thay đổi tinh tế nhưng quan trọng nhất trong lịch sử Scrum: sự dịch chuyển từ chữ "commitment" (cam kết) sang chữ "forecast" (dự báo) đối với Sprint Backlog.
Với kỳ thi PSPO I, đây là vùng kiến thức cực kỳ hay bị gài bẫy. Đề thi thường đưa ra những câu hỏi kiểu: "Team phải hoàn thành toàn bộ Sprint Backlog vào cuối Sprint — đúng hay sai?", hoặc "Ai cam kết với khối lượng công việc của Sprint?". Nếu bạn không phân biệt rõ forecast và commitment, bạn sẽ chọn sai. Quan trọng hơn, hiểu đúng khái niệm này định hình cách bạn — với tư cách Product Owner — đối thoại với stakeholder, quản lý kỳ vọng, và bảo vệ tinh thần empirical (thực nghiệm) của Scrum.
Khái niệm cốt lõi
Forecast là gì, Commitment là gì
Forecast (dự báo) là một ước lượng có cơ sở về khối lượng công việc mà Scrum Team tin rằng họ có thể hoàn thành trong Sprint, dựa trên hiểu biết hiện tại. Bản chất của forecast là: nó có thể thay đổi khi có thêm thông tin, và nó không phải một lời hứa chắc chắn 100%.
Commitment (cam kết) mang hàm ý một lời hứa ràng buộc, một sự đảm bảo về kết quả. Khi bạn "cam kết" giao đủ 8 hạng mục, người nghe hiểu rằng nếu thiếu một hạng mục thì bạn đã thất hứa.
Sự khác biệt nghe có vẻ chỉ là chơi chữ, nhưng nó phản ánh một thực tế sâu sắc về bản chất của công việc phát triển sản phẩm: công việc phức tạp (complex work) vốn dĩ chứa đầy bất định. Bạn không thể biết trước mọi thứ. Một bug ẩn xuất hiện, một yêu cầu được làm rõ giữa Sprint, một thành viên nghỉ ốm — tất cả đều làm thay đổi những gì khả thi.
Lịch sử thay đổi trong Scrum Guide
Đây là phần kiến thức "chốt hạ" mà PSPO I rất thích hỏi:
- Scrum Guide 2011: Sử dụng từ "commitment". Team commit (cam kết) với khối lượng công việc đã chọn cho Sprint Backlog.
- Scrum Guide 2013: Ken Schwaber và Jeff Sutherland chính thức thay từ "commit" bằng "forecast". Đây là thời điểm thay đổi mấu chốt (nhiều tài liệu hay nhắc tới mốc 2011→2017, nhưng chính xác là thay đổi đã được đưa vào bản 2013).
- Scrum Guide 2020: Giữ nguyên tinh thần forecast cho Sprint Backlog, đồng thời giới thiệu khái niệm commitments ở một cấp độ hoàn toàn khác. Cụ thể: mỗi artefact giờ có một "commitment" gắn liền:
Hãy chú ý điểm tinh tế này: từ "commitment" không biến mất khỏi Scrum, nhưng nó được dùng lại với một ý nghĩa khác. Trong Scrum 2020, commitment KHÔNG còn nghĩa là "phải hoàn thành đủ mọi item trong Sprint Backlog". Thay vào đó, commitment là mục tiêu mang lại sự minh bạch và tập trung cho từng artefact. Cái team thực sự cam kết trong một Sprint là Sprint Goal — chứ không phải toàn bộ danh sách hạng mục.
Vì sao sự thay đổi này quan trọng
Lý do cốt lõi nằm ở triết lý empiricism (chủ nghĩa thực nghiệm) — nền tảng của Scrum. Empiricism nói rằng kiến thức đến từ kinh nghiệm và quyết định dựa trên những gì đã quan sát được. Khi bạn buộc một team phải "cam kết" hoàn thành một khối lượng cố định trong môi trường bất định, bạn đang đi ngược lại bản chất thực nghiệm. Bạn ép họ vào tư duy "kế hoạch cố định" (deterministic) trong một thế giới vốn dĩ "thay đổi liên tục" (empirical).
Hậu quả thực tế khi dùng sai từ "commit":
- Team chọn ít việc hơn để "an toàn" (sandbagging) — làm giảm năng suất thực.
- Team hi sinh chất lượng để đạt số lượng — cắt test, bỏ qua Definition of Done, tạo technical debt.
- Mất lòng tin — mỗi lần không đạt "cam kết", stakeholder mất niềm tin, team căng thẳng, không khí trở nên đổ lỗi.
- Che giấu vấn đề — team không dám nói thật về rủi ro vì sợ phá vỡ cam kết.
Điểm mấu chốt PSPO I hay gài
Cần ghi nhớ rõ ràng:
- Scrum Team forecast Sprint Backlog, commit với Sprint Goal.
- Không bắt buộc phải hoàn thành 100% hạng mục trong Sprint Backlog để Sprint được coi là thành công. Sprint thành công khi Sprint Goal đạt được và một Increment "Done" được tạo ra.
- Phạm vi (scope) trong Sprint có thể được thương lượng lại giữa Product Owner và Developers khi hiểu biết tăng lên — miễn là không làm hỏng Sprint Goal.
- Sprint Goal mang lại sự linh hoạt về phạm vi; chính nó là "neo" giúp team biết có thể bỏ bớt hoặc thêm việc gì mà vẫn giữ được giá trị.
Tình huống thực tế
Tình huống 1: Công ty fintech ở TP.HCM và cái bẫy "cam kết cứng"
Một công ty fintech tại Quận 1, TP.HCM (gọi là "MoMoney") đang xây tính năng chuyển tiền QR. Trong Sprint Planning, team Product Owner tên Linh cùng Developers chọn 10 hạng mục, ước lượng tổng 42 story points — đúng bằng velocity trung bình 3 Sprint gần nhất. Giám đốc sản phẩm yêu cầu team "cam kết giao đủ 10 cái".
Đến giữa Sprint, một Developer phát hiện cổng thanh toán của đối tác có giới hạn rate-limit không được ghi trong tài liệu, buộc phải làm thêm cơ chế retry và xử lý lỗi. Việc này "ăn" mất 8 points không hề có trong kế hoạch.
Vì đã "cam kết cứng" 10 hạng mục, team rơi vào lựa chọn tệ: hoặc bỏ qua test cho 3 hạng mục cuối để "đủ số", hoặc làm overtime cả tuần. Họ chọn cắt test. Kết quả: 2 tuần sau, một bug nghiêm trọng về xử lý lỗi thanh toán lọt ra production, gây sự cố giao dịch.
Diễn giải: Cái sai không phải ở việc ước lượng. Cái sai ở chỗ từ "cam kết cứng số lượng" đã ép team hi sinh chất lượng (Definition of Done) để bảo toàn một con số. Mục tiêu thật sự của Sprint — "người dùng chuyển tiền qua QR an toàn" — đã bị bỏ quên sau con số "10/10".
Bài học: Nếu Linh hiểu forecast vs commitment, cô sẽ đặt một Sprint Goal rõ ràng ("Người dùng có thể chuyển tiền qua QR cho 3 ngân hàng lớn một cách an toàn"), và khi phát sinh rate-limit, cô có thể thương lượng bỏ bớt 2-3 hạng mục ít quan trọng để đảm bảo phần lõi đạt chất lượng "Done". Sprint vẫn thành công vì mục tiêu đạt được, dù chỉ giao 7/10 hạng mục.
Tình huống 2: Đối thoại với stakeholder tại một agency ở Hà Nội
Tại một digital agency ở Cầu Giấy, Hà Nội, Product Owner tên Tuấn thường xuyên bị khách hàng (một chuỗi bán lẻ) hỏi: "Cuối Sprint này, chính xác những gì sẽ xong?". Trước đây Tuấn hứa chắc nịch danh sách cụ thể, rồi mỗi lần thiếu một mục là họp căng thẳng, khách hàng nghi ngờ năng lực team.
Sau khi học về forecast, Tuấn đổi cách giao tiếp. Anh nói: "Mục tiêu Sprint này là cho phép khách mua hàng đặt lịch giao tận nhà. Đây là dự báo các hạng mục chúng tôi tin sẽ hoàn thành để đạt mục tiêu đó. Nếu phát sinh, chúng tôi sẽ ưu tiên giữ mục tiêu và trao đổi ngay với anh về các hạng mục phụ."
Ba Sprint sau, mức độ hài lòng của khách tăng rõ rệt — không phải vì team làm nhanh hơn, mà vì kỳ vọng được quản lý đúng. Khách hiểu rằng họ vẫn nhận được giá trị cốt lõi mỗi Sprint, và những điều chỉnh nhỏ là dấu hiệu của một team minh bạch chứ không phải yếu kém.
Bài học: Vai trò của Product Owner không phải là "người bán lời hứa", mà là người chuyển dịch ngôn ngữ từ "danh sách task" sang "giá trị và mục tiêu". Forecast là công cụ giao tiếp giúp bạn trung thực mà vẫn đáng tin cậy.
Tình huống 3: Đội startup Đông Nam Á và văn hóa "sandbagging"
Một startup logistics hoạt động tại Singapore và Việt Nam có một team mà mỗi Sprint đều "đạt 100% cam kết". Nghe thì tuyệt, nhưng Scrum Master tinh ý nhận ra: velocity của họ ổn định một cách đáng ngờ ở mức thấp, và team luôn xong sớm 2 ngày rồi "nghỉ ngơi" cuối Sprint.
Hóa ra, vì văn hóa công ty trừng phạt việc "không đạt cam kết", team cố tình chọn ít việc hơn khả năng thật (sandbagging) để chắc chắn đạt 100%. Họ tối ưu cho việc "trông giỏi" thay vì "tạo nhiều giá trị nhất có thể".
Diễn giải: Đây là tác dụng phụ kinh điển của tư duy commitment cứng. Khi đo lường thành công bằng "% cam kết hoàn thành", bạn vô tình khuyến khích team báo thấp năng lực.
Bài học: Chuyển sang forecast, kết hợp đo lường bằng giá trị giao được và mức đạt Sprint Goal, đã giúp team này dám nhận thêm việc, dám thử nghiệm, và năng suất thật tăng khoảng 25% sau vài tháng — vì họ không còn cần "diễn".
Hướng dẫn từng bước
Dưới đây là cách bạn — với vai trò Product Owner — vận dụng đúng tinh thần forecast vs commitment trong thực tế:
- Luôn bắt đầu Sprint bằng một Sprint Goal rõ ràng. Trước khi bàn "làm bao nhiêu hạng mục", hãy thống nhất "Sprint này tạo ra giá trị gì". Sprint Goal chính là cái team thực sự commit.
- Trình bày Sprint Backlog như một forecast, không phải hợp đồng. Khi nói chuyện với team và stakeholder, dùng đúng từ ngữ: "Đây là dự báo của chúng tôi", thay vì "Chúng tôi cam kết tất cả những cái này".
- Giữ quyền thương lượng phạm vi mở trong suốt Sprint. Khi hiểu biết tăng lên (qua Daily Scrum, qua phát hiện kỹ thuật), bạn và Developers có thể đàm phán lại scope — thêm, bớt, hoặc làm rõ hạng mục — miễn không phá vỡ Sprint Goal.
- Bảo vệ Definition of Done bằng mọi giá. Forecast cho phép giảm số lượng, nhưng KHÔNG bao giờ cho phép giảm chất lượng. "Done" là một commitment thật sự (gắn với Increment).
- Giáo dục stakeholder. Chủ động giải thích cho stakeholder rằng forecast khác commitment, và vì sao điều đó tốt cho họ (chất lượng cao hơn, minh bạch hơn, ít rủi ro che giấu hơn). Đây là một phần trách nhiệm quản lý kỳ vọng của PO.
- Đo lường thành công bằng outcome, không bằng "% hạng mục xong". Câu hỏi đúng cuối Sprint là "Chúng ta có đạt Sprint Goal và tạo ra Increment Done không?", chứ không phải "Chúng ta xong mấy phần trăm danh sách?".
- Dùng Retrospective để cải thiện độ chính xác của forecast. Forecast sai liên tục là tín hiệu để team học cách hiểu công việc tốt hơn — không phải lý do để "ép cam kết".
Lỗi thường gặp & mẹo
Lỗi 1 — Hiểu nhầm "forecast" nghĩa là "không cần nghiêm túc". Forecast không có nghĩa là làm tùy hứng. Team vẫn nỗ lực hết sức để đạt forecast và đặc biệt là Sprint Goal. Forecast là "ước lượng trung thực và nỗ lực", không phải "lời bào chữa".
Lỗi 2 — Nghĩ rằng commitment đã biến mất hoàn toàn trong Scrum 2020. Sai. Commitment vẫn tồn tại, nhưng ở dạng Product Goal, Sprint Goal, và Definition of Done. PSPO I rất hay gài câu này.
Lỗi 3 — Coi Sprint thất bại khi không hoàn thành 100% Sprint Backlog. Sprint vẫn thành công nếu đạt Sprint Goal và tạo Increment Done. Việc còn vài hạng mục chưa xong là bình thường; chúng quay lại Product Backlog và được sắp xếp lại thứ tự.
Lỗi 4 — Product Owner ép Developers "cam kết" thêm việc giữa Sprint. PO không có quyền áp đặt khối lượng. Phạm vi được thương lượng khi cần làm rõ, và Developers là người quyết định họ làm được bao nhiêu.
Mẹo ghi nhớ cho phòng thi: Hãy khắc cụm này vào đầu — "Forecast the Sprint Backlog, commit to the Sprint Goal." (Dự báo Sprint Backlog, cam kết với Sprint Goal.) Khi gặp câu hỏi có chữ "commit/commitment" gắn với "phải hoàn thành mọi hạng mục", gần như chắc chắn đó là đáp án SAI.
Mẹo giao tiếp thực tế: Khi stakeholder hỏi "cam kết xong gì", đừng trả lời bằng danh sách task. Trả lời bằng mục tiêu Sprint trước, rồi mới đến forecast hạng mục. Điều này lập tức nâng chất lượng đối thoại.
Bài tập thực hành
- Phân biệt khái niệm: Viết ra bằng lời của bạn sự khác nhau giữa forecast và commitment trong Scrum 2020. Liệt kê 3 commitment của 3 artefact và cặp với artefact tương ứng.
- Tình huống ra quyết định: Giữa Sprint, một Developer phát hiện một phụ thuộc kỹ thuật khiến 2 hạng mục cuối không thể xong kịp. Với vai trò PO, hãy viết 3-4 câu bạn sẽ nói trong Daily Scrum để xử lý tình huống mà vẫn giữ được Sprint Goal. Gợi ý: đừng ép "phải làm cho xong", hãy đàm phán phạm vi.
- Viết lại lời hứa: Bạn từng (hoặc tưởng tượng) nói với khách hàng: "Cuối Sprint tụi em chắc chắn giao đủ 12 màn hình này." Hãy viết lại câu này theo tinh thần forecast + Sprint Goal, sao cho vừa trung thực vừa giữ được sự tin cậy.
- Câu hỏi luyện thi: Tự đặt 3 câu hỏi trắc nghiệm kiểu PSPO I về chủ đề forecast vs commitment, kèm đáp án đúng và giải thích vì sao các đáp án còn lại sai. Ví dụ một đầu bài: "Điều gì đúng về Sprint Backlog?".
- Soi văn hóa team: Nếu bạn đang làm trong một team thật, hãy quan sát 2 Sprint gần nhất. Team đang dùng tư duy forecast hay commitment cứng? Có dấu hiệu sandbagging hay cắt chất lượng để "đủ số" không? Ghi lại một cải tiến cụ thể bạn sẽ đề xuất trong Retrospective.
Tóm tắt
- Scrum đã chuyển từ "commit" (2011) sang "forecast" (chính thức từ bản 2013) đối với Sprint Backlog, để phản ánh đúng bản chất bất định của công việc phức tạp và bảo vệ tinh thần empiricism.
- Forecast = ước lượng trung thực, có thể điều chỉnh; commitment = lời hứa ràng buộc. Trong Scrum 2020, cái team thật sự cam kết là Sprint Goal, không phải toàn bộ danh sách hạng mục.
- Scrum 2020 đưa "commitment" trở lại với nghĩa mới: mỗi artefact có một commitment — Product Goal (Product Backlog), Sprint Goal (Sprint Backlog), Definition of Done (Increment).
- Sprint thành công khi đạt Sprint Goal và tạo ra Increment "Done" — không bắt buộc hoàn thành 100% Sprint Backlog.
- Phạm vi trong Sprint có thể thương lượng lại giữa PO và Developers khi hiểu biết tăng, miễn không phá vỡ Sprint Goal. Nhưng chất lượng (Definition of Done) thì không bao giờ thương lượng.
- Với vai trò PO: hãy giao tiếp bằng giá trị và mục tiêu, giáo dục stakeholder về forecast, và đo lường thành công bằng outcome thay vì "% hạng mục xong".
- Câu thần chú cho phòng thi: "Forecast the Sprint Backlog, commit to the Sprint Goal."