Bài 23 — Forecast vs Commit trên multi-Sprint horizon

Mở đầu — vì sao bài này quan trọng

Có một câu hỏi mà bất kỳ Product Owner nào cũng sẽ bị "tra tấn" ít nhất một lần mỗi tuần: "Khi nào tính năng X sẽ lên production?" hoặc tệ hơn — "Cả roadmap quý 4 có kịp xong không?". Câu hỏi nghe có vẻ đơn giản, nhưng câu trả lời của bạn lại quyết định rất nhiều thứ: niềm tin của ban lãnh đạo, áp lực lên đội ngũ, và đôi khi cả uy tín nghề nghiệp của chính bạn.

Vấn đề là phần lớn PO trả lời sai cách. Họ hoặc đưa ra một ngày cụ thể như đinh đóng cột ("ngày 15 tháng 11 sẽ xong") rồi sau đó trượt deadline và mất uy tín; hoặc né tránh hoàn toàn ("Scrum không cam kết deadline mà") rồi bị stakeholder coi là thiếu trách nhiệm. Cả hai thái cực đều phá hoại mối quan hệ với người ngoài đội.

Ở cấp độ PSPO II, bạn được kỳ vọng phải hiểu sâu sự khác biệt giữa forecast (dự báo) và commit (cam kết) — không phải như một khẩu hiệu giáo điều Scrum, mà như một công cụ giao tiếp và quản trị rủi ro thực thụ. Bạn phải biết cách dự báo trên một chân trời nhiều Sprint (multi-Sprint horizon), biết khi nào nên đưa ra cam kết và khi nào tuyệt đối không, và biết cách trình bày sự không chắc chắn (uncertainty) sao cho stakeholder vẫn ra quyết định được mà không cảm thấy bị "đá quả bóng trách nhiệm". Đó chính là nội dung của bài này.

Khái niệm cốt lõi

Forecast khác Commit như thế nào?

Hãy phân biệt thật rạch ròi, vì đây là gốc rễ của mọi sai lầm sau đó.

Forecast (dự báo) là một phát biểu về xác suất, dựa trên dữ liệu trong quá khứ và các giả định hiện tại. Nó nói: "Dựa trên những gì chúng tôi biết hôm nay, nhiều khả năng tính năng X sẽ hoàn thành trong khoảng Sprint 8 đến Sprint 10." Forecast luôn đi kèm một khoảng (range) và một mức độ tin cậy (confidence level). Forecast được phép — và bắt buộc — thay đổi khi có thông tin mới. Đó không phải là thất hứa; đó là bản chất của dự báo.

Commit (cam kết) là một lời hứa. Nó nói: "Chúng tôi sẽ giao tính năng X vào ngày 15/11, và nếu không kịp, đó là vấn đề nghiêm trọng." Cam kết tạo ra ràng buộc, thường gắn với hợp đồng, sự kiện marketing, hay nghĩa vụ pháp lý.

Điểm mấu chốt trong tư duy Scrum: đội Scrum cam kết vào Sprint Goal, không cam kết vào toàn bộ nội dung Product Backlog của nhiều Sprint phía trước. Càng nhìn xa, độ bất định càng lớn, nên những gì xa hơn Sprint hiện tại nên được trình bày dưới dạng forecast, chứ không phải commit.

Vì sao càng xa càng không thể cam kết — Cone of Uncertainty

Ở bài trước bạn đã làm quen với Cone of Uncertainty (hình nón bất định). Ý tưởng cốt lõi áp dụng vào đây: tại thời điểm đầu dự án, một ước lượng có thể sai lệch theo hệ số 4 lần (tức việc bạn nghĩ mất 1 tháng có thể thực tế mất từ nửa tháng đến 4 tháng). Càng tiến gần, hình nón càng hẹp, sai số càng nhỏ.

Hệ quả thực tế: forecast cho Sprint kế tiếp thì khá chính xác, forecast cho 6 tháng sau thì gần như là phỏng đoán có cơ sở. PO giỏi không cố ép sự chính xác mà thị trường không cho phép; thay vào đó, họ truyền đạt đúng mức độ bất định ứng với từng khoảng thời gian.

Velocity và Throughput — hai nền tảng để dự báo

Có hai cách định lượng phổ biến để dự báo multi-Sprint:

Cách 1 — Velocity-based forecasting (dựa trên Story Points). Bạn lấy velocity trung bình của vài Sprint gần nhất (ví dụ 40 điểm/Sprint), ước lượng tổng số điểm còn lại của phạm vi cần giao (ví dụ 320 điểm), rồi chia ra: 320 / 40 = 8 Sprint. Đơn giản, dễ hiểu, nhưng có nhược điểm: Story Point mang tính chủ quan, velocity dao động, và việc lấy trung bình đơn thuần che giấu rủi ro.

Cách 2 — Throughput-based forecasting / Monte Carlo (dựa trên số lượng item). Thay vì đếm điểm, bạn đếm số Product Backlog Item hoàn thành mỗi Sprint (throughput). Sau đó dùng mô phỏng Monte Carlo: lấy ngẫu nhiên lịch sử throughput hàng nghìn lần để tạo ra một phân phối xác suất ngày hoàn thành. Kết quả không phải một con số mà là dạng: "85% khả năng xong trước Sprint 10, 50% khả năng xong trước Sprint 8." Đây là cách tiếp cận trưởng thành hơn vì nó trả lời đúng bản chất câu hỏi: không phải "khi nào xong" mà "xác suất xong vào lúc nào".

Trình bày forecast bằng xác suất, không bằng một điểm

Đây là kỹ năng phân biệt PO bình thường với PO cấp PSPO II. Thay vì nói "xong vào Sprint 8", hãy nói: "Với mức tin cậy 85%, tính năng sẽ xong trước cuối Sprint 10. Nếu anh chị cần chắc chắn hơn nữa ở mức 95%, mốc đó là Sprint 11." Cách nói này biến một câu hỏi nhị phân (xong/không xong) thành một cuộc đối thoại về quản trị rủi ro, và trao quyền quyết định cho stakeholder dựa trên khẩu vị rủi ro của họ.

Tình huống thực tế

Ví dụ 1 — Sàn TMĐT "ChợViệt" và áp lực Mega Sale 11/11

Công ty TMĐT giả định "ChợViệt" có một PO tên Linh phụ trách tính năng "ví trả góp tích hợp ngân hàng". Giám đốc thương mại hỏi vào đầu tháng 8: "Tính năng này có kịp cho Mega Sale 11/11 không? Marketing cần chốt kế hoạch."

Linh KHÔNG trả lời "kịp" hay "không kịp". Cô lấy dữ liệu: đội đã chạy 6 Sprint hai tuần, throughput dao động 5–9 item/Sprint, phạm vi tính năng còn khoảng 34 item. Chạy mô phỏng Monte Carlo, Linh có kết quả: 50% khả năng xong sau 5 Sprint, 85% khả năng xong sau 7 Sprint. Tính ra lịch: nếu mọi thứ thuận lợi (50%), sẽ xong khoảng cuối tháng 10; nếu thận trọng (85%), sẽ rơi vào giữa tháng 11 — tức trượt mốc 11/11.

Linh trình bày: "Em không thể cam kết kịp 11/11 với độ chắc chắn cao. Ở mức tin cậy 85%, mốc thực tế là 16/11. Nếu mình muốn nâng xác suất kịp, có hai lựa chọn: cắt phạm vi xuống còn tích hợp 2 ngân hàng lớn nhất thay vì 5 ngân hàng, hoặc chấp nhận rủi ro 50/50."

Bài học: Linh không hứa liều, cũng không né tránh. Cô đưa dữ liệu xác suất và đặt quyết định cắt phạm vi vào tay người có thẩm quyền. Kết quả: ban lãnh đạo chọn cắt phạm vi còn 2 ngân hàng, kịp 11/11 với độ tin cậy 90%. Quan trọng hơn, khi PO trung thực về uncertainty, stakeholder tin tưởng hơn ở các forecast lần sau.

Ví dụ 2 — Fintech "PayNow" và cái bẫy "velocity trung bình"

PO tên Tuấn ở một startup fintech giả định "PayNow" được hỏi roadmap quý có xong không. Anh tính nhanh: velocity trung bình 45 điểm, backlog còn 270 điểm, vậy 270/45 = 6 Sprint, đúng bằng quý. Tuấn báo cáo "kịp".

Sai lầm lộ ra sau đó. Velocity 45 là trung bình của các Sprint dao động từ 28 đến 58 điểm — biến động rất lớn. Hai Sprint đầu quý dính sự cố hạ tầng và một thành viên nghỉ, velocity rớt xuống 30. Đến giữa quý, Tuấn nhận ra với đà này phải mất 8 Sprint chứ không phải 6. Anh báo trượt deadline muộn, ban lãnh đạo đã lỡ truyền thông với đối tác.

Nếu Tuấn dùng dải velocity thay vì trung bình đơn, anh đã thấy: ở kịch bản xấu (velocity 30), cần 9 Sprint; ở kịch bản tốt (velocity 58), cần 5 Sprint; trung bình 6 Sprint. Một forecast trung thực phải là: "Khả năng cao nằm trong khoảng 5–9 Sprint; để chắc 85% thì nên dự phòng đến 8 Sprint."

Bài học: Trung bình hóa che giấu rủi ro. Luôn dùng khoảng (range) và kịch bản (best/worst/likely). Và đừng bao giờ chuyển một forecast (xác suất) thành một commit (lời hứa) khi báo cáo lên trên — sự "làm tròn" này là nguồn gốc của hầu hết khủng hoảng niềm tin.

Ví dụ 3 — Spotify và mô hình Now/Next/Later thay cho ngày cụ thể

Nhiều công ty sản phẩm trưởng thành như Spotify từ lâu đã từ chối roadmap dạng "Gantt chart có ngày cụ thể cho 12 tháng". Thay vào đó họ dùng tư duy theo chân trời tin cậy: những gì Now (đang làm) thì cam kết khá chắc, những gì Next thì forecast có khoảng, những gì Later thì chỉ là định hướng — không hứa ngày.

Áp dụng vào multi-Sprint horizon: với 1–2 Sprint sắp tới, PO có thể nói khá chắc chắn (gần như commit ở mức Sprint Goal). Với 3–6 Sprint, đưa forecast dạng khoảng kèm xác suất. Xa hơn 6 Sprint, chỉ nên nói về thứ tự ưu tiên và mục tiêu, tuyệt đối không gắn ngày.

Bài học: Cấu trúc giao tiếp theo độ xa của chân trời. Khách hàng nội bộ chấp nhận sự mơ hồ ở xa nếu bạn rõ ràng ở gần và nhất quán trong cách trình bày.

Hướng dẫn từng bước

Đây là quy trình bạn có thể áp dụng ngay khi bị hỏi "khi nào xong":

Làm rõ câu hỏi và phạm vi. "Tính năng X" cụ thể gồm những Backlog Item nào? Bao gồm cả testing, hardening, compliance không? Phạm vi mơ hồ thì forecast vô nghĩa. Chốt một định nghĩa "xong" rõ ràng trước.

Thu thập dữ liệu lịch sử thực. Lấy throughput (số item hoàn thành/Sprint) hoặc velocity của tối thiểu 5–8 Sprint gần nhất. Đừng dùng dữ liệu quá cũ vì đội hình và bối cảnh đã thay đổi.

Chọn phương pháp dự báo. Nếu đội ước lượng Story Point ổn định, dùng velocity-based. Nếu muốn chính xác hơn về xác suất, dùng throughput + Monte Carlo (nhiều công cụ như Jira, ActionableAgile, hoặc một bảng tính đơn giản đều làm được).

Tính ra dải kết quả, không phải một số. Luôn cho ra ít nhất ba con số: mốc 50%, mốc 85%, mốc 95%. Đây là ngôn ngữ bạn sẽ dùng với stakeholder.

Liệt kê giả định và rủi ro kèm theo. Forecast này giả định đội không đổi người, không có dependency lớn chưa giải quyết, scope không phình. Ghi rõ ra. Khi giả định thay đổi, forecast được phép cập nhật.

Trình bày dưới dạng xác suất và đưa lựa chọn. "85% xong trước Sprint 10. Nếu cần chắc hơn, ta có thể cắt scope hoặc thêm nguồn lực." Trao quyền quyết định cho stakeholder.

Cập nhật forecast mỗi Sprint. Sau mỗi Sprint Review, tính lại với dữ liệu mới nhất. Một burn-up chart cập nhật liên tục là công cụ giao tiếp tuyệt vời vì nó cho thấy forecast tiến hóa theo thời gian thực.

Chỉ commit khi thực sự cần và khi đã thu hẹp được hình nón. Cam kết một ngày cụ thể chỉ nên xảy ra khi phạm vi đã rõ, đội đã chạy ổn định vài Sprint, và mốc đó nằm gần (trong tầm 1–2 Sprint). Khi commit, hãy commit cho cái nhỏ nhất có giá trị (một lát mỏng), không commit cho cả tảng băng.

Lỗi thường gặp & mẹo

Lỗi 1 — Biến forecast thành commit khi báo cáo lên trên. PO tính ra "50% khả năng Sprint 8" nhưng khi sếp hỏi lại nói gọn "Sprint 8 nhé". Sự đơn giản hóa này giết chết uy tín. Mẹo: luôn giữ nguyên ngôn ngữ xác suất từ phòng họp đội đến phòng họp ban giám đốc.

Lỗi 2 — Dùng velocity trung bình đơn, bỏ qua biến động. Như ví dụ PayNow. Mẹo: luôn nhìn cả độ phân tán (dải min–max), không chỉ con số trung bình.

Lỗi 3 — Quên rằng scope creep phá vỡ mọi forecast. Forecast giả định phạm vi cố định. Nếu mỗi Sprint backlog lại phình thêm, đường đích lùi mãi. Mẹo: vẽ burn-up chart có hai đường — đường tiến độ và đường tổng phạm vi. Khi đường phạm vi đi lên, ai cũng thấy ngay lý do trễ.

Lỗi 4 — Forecast một lần rồi để đó. Forecast là vật sống. Mẹo: cập nhật mỗi Sprint, coi đó là một phần nghi thức của Sprint Review với stakeholder.

Lỗi 5 — Né tránh hoàn toàn bằng cách núp sau giáo điều Scrum. Nói "Scrum không có deadline" để khỏi trả lời là vô trách nhiệm và phản tác dụng. Mẹo: Scrum không cấm forecast — nó khuyến khích forecast trung thực. Hãy là người đưa dữ liệu, không phải người trốn câu hỏi.

Mẹo nâng cao: Khi không chắc giữa "forecast" và "commit", hãy tự hỏi: "Nếu mốc này trượt, hậu quả là gì?" Nếu hậu quả lớn (mất hợp đồng, lỡ sự kiện luật định), bạn cần commit — và do đó phải thu hẹp scope đến mức kiểm soát được rủi ro. Nếu hậu quả chỉ là "ra muộn hơn một chút", forecast khoảng là đủ.

Bài tập thực hành

Tự dựng một forecast. Lấy một sản phẩm bạn đang làm (hoặc giả định). Ghi lại throughput của 6 Sprint gần nhất, ví dụ: 6, 9, 5, 8, 7, 6 item. Giả sử phạm vi còn lại là 40 item. Hãy tính: với kịch bản tốt (throughput 9), trung bình (≈6.8), và xấu (5), bạn cần bao nhiêu Sprint? Viết ra một câu forecast theo đúng ngôn ngữ xác suất để trình bày cho stakeholder.

Đóng vai và phản xạ. Tưởng tượng giám đốc hỏi: "Cả roadmap quý 4 có xong không?" Viết ra câu trả lời của bạn theo mô hình Now/Next/Later, trong đó phần Now bạn nói chắc, phần Next bạn đưa khoảng, phần Later bạn chỉ nói định hướng. So sánh với phản xạ cũ của bạn.

Săn lỗi commit ẩn. Đọc lại 3 email hoặc tin nhắn gần nhất bạn từng gửi về tiến độ. Đánh dấu chỗ nào bạn vô tình biến forecast thành commit (nói một ngày cụ thể mà không kèm mức tin cậy). Viết lại câu đó cho đúng.

Thiết kế burn-up. Phác một burn-up chart với hai đường: tổng phạm vi và tiến độ tích lũy. Kéo dài hai đường theo xu hướng để tìm điểm giao — đó là forecast ngày hoàn thành. Thử nâng đường phạm vi lên (giả lập scope creep) và quan sát điểm giao lùi đi như thế nào.

Tóm tắt

Forecast là xác suất; commit là lời hứa. Đội Scrum cam kết Sprint Goal, dự báo cho những gì xa hơn. Đừng lẫn lộn hai khái niệm khi giao tiếp.
Càng xa càng bất định (Cone of Uncertainty): forecast cho Sprint gần thì chắc, cho 6 tháng sau thì chỉ là phỏng đoán có cơ sở. Trình bày uncertainty đúng với độ xa của chân trời.
Dự báo bằng dải và xác suất, không bằng một điểm. Dùng velocity-based cho đơn giản, throughput + Monte Carlo cho chính xác. Luôn đưa mốc 50/85/95%.
Trung bình hóa che giấu rủi ro. Luôn nhìn độ biến động, không chỉ con số trung bình.
Cập nhật forecast mỗi Sprint và canh chừng scope creep bằng burn-up chart.
Chỉ commit khi cần và khi hình nón đã hẹp, và khi commit thì commit cho lát mỏng nhỏ nhất có giá trị.
Cuối cùng, vai trò của bạn không phải là tiên tri đoán đúng ngày, mà là người quản trị kỳ vọng bằng dữ liệu trung thực. Đó mới là dấu hiệu của một Senior Product Owner thực thụ.