Mở đầu — vì sao bài này quan trọng
Hãy thành thật với nhau một chuyện: gần như mọi Product Owner đều từng nói một câu mà sau này họ hối hận — "Tính năng X sẽ xong vào ngày 15/8." Câu nói nghe có vẻ chuyên nghiệp, dứt khoát, làm hài lòng sếp trong cuộc họp. Nhưng đến ngày 15/8, tính năng chưa xong, và bạn trở thành người "hứa lèo". Vấn đề không nằm ở việc bạn đoán sai. Vấn đề nằm ở cách bạn đoán.
Forecasting (dự báo) là một trong những kỹ năng bị hiểu nhầm nhiều nhất của một PO. Nhiều người nghĩ dự báo giỏi nghĩa là đoán đúng ngày. Sai. Tương lai vốn dĩ không chắc chắn — không ai trong chúng ta đoán đúng tương lai cả. Dự báo giỏi nghĩa là truyền đạt đúng mức độ không chắc chắn đó cho stakeholder, để họ ra quyết định dựa trên rủi ro thực tế chứ không phải một ảo tưởng về sự chắc chắn.
Bài học này tập trung vào sự khác biệt cốt lõi giữa hai trường phái dự báo: Deterministic (xác định, một con số duy nhất) và Probabilistic (xác suất, một dải kết quả kèm độ tin cậy). Hiểu được sự khác biệt này sẽ thay đổi cách bạn nói chuyện với stakeholder mãi mãi — từ một người "hứa rồi trượt" thành một người mà cả tổ chức tin tưởng khi cần biết "bao giờ xong".
Khái niệm cốt lõi
Deterministic Forecasting — Lời hứa nguy hiểm
Dự báo theo kiểu deterministic là khi bạn đưa ra một con số duy nhất, không kèm độ không chắc chắn:
- "Feature X sẽ xong ngày 15/8."
- "Team sẽ hoàn thành 80 story points trong release này."
- "Dự án ra mắt quý 3."
Vì sao deterministic forecast hay trượt? Vì nó thường được lấy từ kịch bản lạc quan nhất (best case). Khi bạn nói "ngày 15/8", trong đầu bạn đang giả định mọi thứ diễn ra trơn tru. Nhưng xác suất để mọi thứ trơn tru là cực thấp. Đó là lý do một con số deterministic thường có xác suất trượt khoảng 50% trở lên — và đôi khi cao hơn nhiều.
Probabilistic Forecasting — Nói sự thật về tương lai
Dự báo theo kiểu probabilistic thừa nhận rằng tương lai là một dải các kết quả khả dĩ, mỗi kết quả gắn với một mức độ tin cậy (confidence level). Thay vì một con số, bạn đưa ra một câu kiểu:
- "Có 50% khả năng xong trước 15/8, 85% khả năng xong trước 29/8, và 95% khả năng xong trước 5/9."
- "Khả năng cao nhất là khoảng 8–11 sprint nữa, với độ tin cậy 85% là 11 sprint."
Ngôn ngữ của xác suất: percentile và confidence level
Trái tim của probabilistic forecasting là khái niệm percentile (phân vị). Khi nói "85% confidence là ngày 29/8", nghĩa là: dựa trên dữ liệu lịch sử của team, trong 100 kịch bản tương lai mô phỏng, có 85 kịch bản hoàn thành vào hoặc trước ngày 29/8.
Ba mốc thường dùng trong thực tế:
- P50 (50%): kịch bản "may rủi 50-50". Thích hợp cho mục tiêu nội bộ, không nên cam kết ra ngoài.
- P85 (85%): mốc cam kết an toàn phổ biến. Đủ tin cậy để hứa với khách hàng mà vẫn không quá thừa.
- P95 (95%): rất an toàn, dùng khi cái giá của việc trễ là cực lớn (hợp đồng phạt, sự kiện cố định).
Hai nguồn của dự báo xác suất
Có hai cách tạo ra một probabilistic forecast:
- Dựa trên throughput lịch sử (số item team hoàn thành mỗi sprint/tuần). Ví dụ, nếu 12 tuần qua team hoàn thành lần lượt 7, 9, 5, 8, 11... item/tuần, ta lấy chính dải dữ liệu thật này để mô phỏng tương lai. Cách này không cần ước lượng story point — chỉ cần đếm số item còn lại.
- Monte Carlo Simulation — phương pháp mạnh nhất. Máy tính lấy ngẫu nhiên một giá trị throughput từ lịch sử cho mỗi tuần tương lai, lặp lại đến khi hoàn thành hết backlog, ghi nhận số tuần. Chạy mô phỏng này 10.000 lần sẽ cho ra một phân bố — từ đó rút ra P50, P85, P95. Nó "tái hiện" sự ngẫu nhiên của thực tế thay vì giả định mọi tuần đều giống nhau.
Tình huống thực tế
Ví dụ 1: Sàn thương mại điện tử ở TP.HCM và cái bẫy "ngày 15/8"
Một công ty thương mại điện tử tại TP.HCM (tạm gọi ShopViet) chuẩn bị ra mắt tính năng "Mua trước trả sau". CEO hỏi PO: "Bao giờ xong?" PO nhìn backlog, nhẩm tính rồi đáp chắc nịch: "Ngày 15/8 anh ạ." CEO lập tức cho marketing chạy chiến dịch, đặt KOL, in voucher với mốc ra mắt 16/8.
Thực tế diễn ra thế nào? Team có throughput dao động: tuần làm được 9 item, tuần được 5 item (vì kẹt tích hợp với đối tác tài chính). Đến 15/8, mới xong 70%. Marketing đã tiêu 300 triệu cho chiến dịch, KOL đã đăng bài, và ShopViet phải vội vã thông báo dời ngày — mất uy tín với khách lẫn đối tác.
Bài học rút ra: con số "15/8" của PO là một deterministic forecast lấy từ best case. Nếu PO đã nói "P50 là 15/8, nhưng P85 là 30/8", CEO hoàn toàn có thể chọn lên lịch marketing vào đầu tháng 9 cho an toàn. Sai lầm không phải team làm chậm — mà là PO đã giấu đi sự không chắc chắn, biến một phỏng đoán thành một lời hứa.
Ví dụ 2: Fintech Singapore dùng Monte Carlo để "thắng" cuộc họp board
Một startup fintech ở Singapore phục vụ thị trường Đông Nam Á cần dự báo ngày hoàn thành module KYC (xác minh danh tính) cho hội đồng quản trị. PO mới — vừa học probabilistic forecasting — làm khác đi.
Cô lấy throughput của 14 sprint gần nhất (số item hoàn thành mỗi sprint, dao động từ 4 đến 13). Backlog còn lại 96 item. Cô chạy Monte Carlo Simulation 10.000 lần trên một file spreadsheet đơn giản. Kết quả: P50 = 12 sprint, P85 = 15 sprint, P95 = 17 sprint.
Trước board, cô không nói "xong sau 12 sprint". Cô trình bày: "Nếu board cần cam kết với regulator, em đề xuất dùng mốc 85% là 15 sprint, tức khoảng cuối tháng 11. Mốc lạc quan 12 sprint chỉ có 50% khả năng đạt được, em không khuyên cam kết theo mốc đó." Board ấn tượng vì lần đầu họ thấy một con số có gắn rủi ro rõ ràng. Họ chọn mốc 85%, và đến cuối tháng 11 team hoàn thành đúng hẹn — uy tín của PO tăng vọt.
Bài học rút ra: probabilistic forecasting không chỉ chính xác hơn, nó còn là công cụ giao tiếp và quản lý kỳ vọng. Khi bạn cho stakeholder quyền chọn mức rủi ro, bạn chuyển trách nhiệm quyết định về đúng người — và bạn không còn là người "hứa lèo" nữa.
Ví dụ 3: Team outsourcing và bài học về throughput bất ổn
Một công ty gia công phần mềm ở Đà Nẵng nhận dự án cho khách hàng Nhật. PO ban đầu dự báo theo velocity trung bình: "Velocity trung bình 40 điểm/sprint, backlog 400 điểm, vậy 10 sprint là xong." Đây là deterministic dùng giá trị trung bình — vẫn là một con số.
Vấn đề: velocity của team rất bất ổn (có sprint 55 điểm, có sprint chỉ 22 điểm do thành viên luân chuyển dự án). Khi PO nhìn vào dải throughput thay vì trung bình, cô nhận ra độ lệch rất lớn. Chạy probabilistic: P50 = 10 sprint, nhưng P85 = tận 14 sprint — chênh tới 4 sprint. Khoảng cách rộng này là một tín hiệu cảnh báo: team quá thiếu ổn định để cam kết chắc một mốc.
PO mang phát hiện này nói chuyện với quản lý: "Sự bất ổn về nhân sự đang khiến dự báo của chúng ta có vùng rủi ro 4 sprint. Nếu giữ team ổn định, em có thể thu hẹp khoảng này lại." Kết quả: công ty cam kết không luân chuyển người giữa chừng, throughput ổn định hơn, và lần forecast sau khoảng P50–P85 chỉ còn chênh 1 sprint.
Bài học rút ra: độ rộng của dải dự báo (P50 đến P85) không chỉ là con số — nó là chẩn đoán sức khỏe của team. Trung bình che giấu sự thật; phân bố phơi bày nó.
Hướng dẫn từng bước
Đây là quy trình thực tế để bạn tạo một probabilistic forecast mà không cần là chuyên gia thống kê:
- Thu thập dữ liệu throughput lịch sử. Đếm số item (story, task — không cần story point) team hoàn thành mỗi tuần hoặc mỗi sprint trong 8–15 chu kỳ gần nhất. Đây là nguyên liệu thật nhất bạn có.
- Đếm số item còn lại trong scope. Nhìn vào phần backlog cần cho mục tiêu/release này còn bao nhiêu item chưa xong. Lưu ý rằng scope có thể thay đổi — đây là một nguồn bất định.
- Chạy mô phỏng (Monte Carlo). Với mỗi lần mô phỏng: lặp lại việc rút ngẫu nhiên một giá trị throughput từ lịch sử, cộng dồn cho đến khi đủ số item còn lại, ghi nhận đã mất bao nhiêu tuần. Lặp 10.000 lần. Có thể làm bằng spreadsheet, plugin của Jira, hoặc công cụ như Actionable Agile.
- Rút ra các percentile. Sắp xếp 10.000 kết quả, lấy giá trị ở vị trí 50%, 85%, 95% — đó là P50, P85, P95 của bạn.
- Diễn dịch ra ngôn ngữ stakeholder. Đừng nói "P85". Hãy nói: "85% khả năng xong trước ngày X; nếu cần an toàn hơn cho sự kiện ra mắt, chọn mốc Y với 95% tin cậy."
- Cập nhật forecast liên tục. Forecast không phải làm một lần. Mỗi sprint, cập nhật throughput mới và chạy lại. Dải dự báo sẽ thu hẹp dần khi tiến gần đích — đây là điều stakeholder rất thích thấy.
Lỗi thường gặp & mẹo
Lỗi 1 — Vẫn báo một con số sau khi đã tính ra dải. Nhiều PO chạy Monte Carlo ra ba mốc nhưng khi vào họp lại "thu gọn" thành "tầm cuối tháng 8 nhé sếp". Như vậy là vứt bỏ toàn bộ giá trị của probabilistic. Mẹo: luôn báo tối thiểu hai mốc (P50 và P85) để stakeholder thấy được vùng rủi ro.
Lỗi 2 — Dùng best case làm cam kết. Bộ não con người thiên về lạc quan (planning fallacy). Mẹo: quy ước rõ ràng trong tổ chức rằng cam kết ra ngoài luôn dùng P85 trở lên, P50 chỉ là mục tiêu nội bộ.
Lỗi 3 — Quên rằng scope thay đổi. Forecast chỉ đúng với scope hiện tại. Nếu stakeholder liên tục thêm việc, ngày sẽ lùi dù team không hề chậm. Mẹo: khi báo forecast, luôn kèm câu "với scope hiện tại N item; mỗi item thêm vào sẽ dịch chuyển mốc này".
Lỗi 4 — Lấy quá ít dữ liệu lịch sử. Dùng 2–3 sprint để mô phỏng cho ra kết quả không đáng tin. Mẹo: cần ít nhất 7–11 điểm dữ liệu; nếu team mới, hãy nói rõ độ tin cậy còn thấp và cập nhật sớm.
Mẹo vàng — Đừng hứa độ chính xác, hãy hứa độ trung thực. Stakeholder thông minh không cần bạn đoán đúng tuyệt đối. Họ cần biết rủi ro thật để quyết định. Một PO nói "85% xong trước 30/8" và thực tế xong 28/8 đáng tin hơn nhiều một PO nói "chắc chắn 15/8" rồi trượt.
Bài tập thực hành
- Thu thập dữ liệu thật của bạn. Mở công cụ quản lý công việc (Jira/Trello/...) và ghi lại số item team bạn hoàn thành trong 10 sprint/tuần gần nhất. Tính throughput cao nhất, thấp nhất, trung bình. Quan sát: dải dao động rộng hay hẹp?
- Tạo forecast ba kịch bản. Với một mục tiêu thật của team (ví dụ: còn 60 item), dùng throughput tốt/khả dĩ/tệ để tính ra ba mốc thời gian hoàn thành. Viết chúng ra dưới dạng câu probabilistic thay vì một con số.
- Viết lại một lời hứa cũ. Nhớ lại một lần bạn (hoặc đồng nghiệp) đã nói một deterministic forecast với sếp. Viết lại câu đó theo kiểu probabilistic, kèm ít nhất hai percentile. So sánh cảm giác khi đọc hai phiên bản.
- Tập diễn đạt với stakeholder. Soạn một đoạn 3–4 câu trình bày forecast cho một stakeholder không rành kỹ thuật. Mục tiêu: giúp họ chọn được mức rủi ro phù hợp mà không cần hiểu Monte Carlo là gì.
- (Nâng cao) Dựng một Monte Carlo mini. Trong một spreadsheet, dùng hàm random để rút throughput từ lịch sử, mô phỏng 1.000 lần một mục tiêu nhỏ, và tự tay rút ra P50/P85. Bạn sẽ "thấm" được vì sao dải dự báo lại có hình dạng như vậy.
Tóm tắt
- Deterministic forecast là một con số duy nhất không kèm độ không chắc chắn ("xong 15/8"). Nó nghe dứt khoát nhưng thường lấy từ best case và có xác suất trượt rất cao — biến PO thành người "hứa lèo".
- Probabilistic forecast đưa ra một dải kết quả kèm độ tin cậy ("50% trước 15/8, 85% trước 30/8"). Nó trung thực hơn và giúp stakeholder ra quyết định dựa trên rủi ro thật.
- Công cụ mạnh nhất là Monte Carlo Simulation, dùng throughput lịch sử thật của team để mô phỏng hàng nghìn kịch bản tương lai, rồi rút ra các mốc percentile P50, P85, P95.
- Khoảng cách giữa các percentile chính là vùng rủi ro — đồng thời là một chẩn đoán sức khỏe về độ ổn định của team.
- Mục tiêu của dự báo không phải là đoán đúng, mà là truyền đạt đúng sự không chắc chắn. Hãy luôn báo tối thiểu hai mốc, dùng P85 trở lên cho cam kết ra ngoài, và cập nhật forecast mỗi sprint.