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ị hỏi, đôi khi nhiều lần trong một tuần: "Khi nào tính năng X xong?" hoặc "Bao giờ chúng ta release được?". Câu hỏi nghe đơn giản, nhưng nó là nơi rất nhiều PO bị mất uy tín. Trả lời bừa "cuối tháng tới" rồi trượt deadline ba lần liên tiếp, bạn sẽ bị gắn mác "PO không đáng tin". Trả lời kiểu phòng thủ "Scrum không cam kết ngày tháng đâu anh" thì stakeholder sẽ nghĩ bạn đang trốn trách nhiệm.
Sự thật nằm ở giữa. Scrum Guide 2020 thực sự không có sự kiện nào tên là "Release Planning". Scrum chỉ định nghĩa Sprint, Sprint Planning, Daily Scrum, Sprint Review, Retrospective. Nhưng trong thực tế kinh doanh, không một tổ chức nào để team làm việc vô thời hạn mà không cần biết "khi nào ra mắt". Marketing cần đặt lịch chiến dịch, sales cần báo khách hàng, ban giám đốc cần báo cáo nhà đầu tư. Release Planning — hay chính xác hơn là forecasting nhiều Sprint phía trước — chính là kỹ năng giúp PO bắc cầu giữa thế giới empirical của Scrum và nhu cầu lập kế hoạch của doanh nghiệp.
Bài này dạy bạn cách dự báo (forecast) một cách trung thực, dựa trên dữ liệu, và truyền đạt sự không chắc chắn (uncertainty) thay vì che giấu nó. Đây là kỹ năng phân biệt một PO chuyên nghiệp với một người chỉ biết viết user story.
Khái niệm cốt lõi
Forecast, không phải Commitment
Điểm khởi đầu quan trọng nhất về tư duy: bạn đang tạo ra một dự báo (forecast), chứ không phải một cam kết cứng (commitment). Dự báo là phát biểu xác suất dựa trên dữ liệu hiện có; nó sẽ được cập nhật khi có thêm thông tin. Cũng giống dự báo thời tiết: "70% khả năng mưa cuối tuần" — không ai bắt đài khí tượng phải bồi thường nếu trời nắng. Khi bạn đóng khung câu trả lời là forecast, bạn được phép — và có trách nhiệm — cập nhật nó sau mỗi Sprint.
Phương pháp 1: Velocity-based forecasting
Đây là cách phổ biến nhất và dễ hiểu nhất. Velocity là số Story Point trung bình mà team hoàn thành mỗi Sprint. Công thức nền tảng:
Số Sprint còn lại = Tổng Story Point còn lại trong phạm vi release ÷ Velocity trung bình
Ví dụ: phạm vi release còn 240 điểm, velocity trung bình 30 điểm/Sprint → khoảng 8 Sprint nữa. Nếu Sprint dài 2 tuần, đó là khoảng 16 tuần.
Nhưng đừng dùng một con số duy nhất — đó là cái bẫy chết người. Hãy dùng dải velocity: lấy velocity thấp nhất, cao nhất và trung bình của 6–8 Sprint gần nhất để tạo ra ba kịch bản.
- Lạc quan (velocity cao, ví dụ 36): 240 ÷ 36 ≈ 7 Sprint
- Khả dĩ nhất (velocity 30): 8 Sprint
- Thận trọng (velocity 24): 240 ÷ 24 = 10 Sprint
Phương pháp 2: Throughput-based forecasting (đếm số item)
Nhiều team đã bỏ Story Point, chuyển sang đếm throughput — số item (story) hoàn thành mỗi Sprint hoặc mỗi tuần. Cách này đặc biệt mạnh khi các story được chẻ nhỏ tương đối đồng đều. Thay vì ước lượng điểm, bạn chỉ cần biết backlog còn bao nhiêu item và team thường "đóng" được bao nhiêu item mỗi Sprint.
Ví dụ: còn 50 item, throughput dao động 5–8 item/Sprint → cần khoảng 6 đến 10 Sprint. Ưu điểm: bỏ qua tranh cãi về việc story này "3 điểm hay 5 điểm", giảm chi phí estimation.
Phương pháp 3: Forecasting xác suất (Monte Carlo)
Đây là cấp độ nâng cao và chính xác hơn cả. Thay vì dùng một velocity trung bình, mô phỏng Monte Carlo lấy ngẫu nhiên hàng nghìn lần từ lịch sử throughput thực tế của team để tính ra phân phối xác suất ngày hoàn thành. Kết quả không phải một ngày, mà là dạng: "85% khả năng xong trước ngày 15/9; 50% khả năng xong trước 1/9".
Bạn không cần tự code — các công cụ như Actionable Agile, hoặc thậm chí một file Excel/Google Sheets với hàm RANDBETWEEN, đều làm được. Điểm mạnh của Monte Carlo là nó tự nhiên thể hiện sự không chắc chắn dưới dạng phần trăm, đúng thứ stakeholder cần để ra quyết định kinh doanh. (Lưu ý: kỹ thuật xác suất so với deterministic được đào sâu ở Bài 48, ở đây ta chỉ dùng nó như một công cụ release planning.)
Hai biến số: Scope cố định hay Date cố định?
Mọi release planning đều xoay quanh việc biến nào bị khóa:
- Fixed scope, flexible date: "Phải làm xong đủ tính năng A, B, C — ngày ra mắt linh hoạt." Bạn forecast ra ngày.
- Fixed date, flexible scope: "Phải ra mắt đúng dịp Black Friday — làm được bao nhiêu thì làm." Bạn forecast ra bao nhiêu scope kịp. Đây là tình huống phổ biến nhất ở Việt Nam với các sự kiện như sale 11.11, 12.12, Tết.
Tình huống thực tế
Ví dụ 1: Sàn TMĐT chuẩn bị cho 11.11
Một sàn thương mại điện tử tại TP.HCM (gọi là ShopFast) cần ra mắt tính năng "Flash Sale theo khung giờ" kịp ngày 11/11. Hôm nay là 1/8, tức còn khoảng 7 Sprint (Sprint 2 tuần). Đây là bài toán fixed date.
PO của ShopFast làm như sau. Cô lấy velocity 8 Sprint gần nhất: 28, 32, 25, 30, 22, 35, 29, 31 → trung bình ≈ 29, thấp nhất 22, cao nhất 35. Với 7 Sprint còn lại, team có thể hoàn thành trong khoảng 7×22 = 154 đến 7×35 = 245 điểm, khả dĩ nhất ≈ 203 điểm.
Cô ngồi với team chia backlog "Flash Sale" thành ba nhóm: Must-have (engine flash sale, đếm ngược, giới hạn tồn kho) — 130 điểm; Should-have (thông báo đẩy, widget trang chủ) — 60 điểm; Could-have (gamification, mini-game quay thưởng) — 50 điểm. Tổng 240 điểm.
Forecast cho thấy: 130 điểm Must-have gần như chắc chắn kịp (kịch bản thận trọng 154 điểm vẫn đủ). Nhóm Should-have phụ thuộc velocity. Nhóm Could-have gần như không kịp. Cô báo ban giám đốc: "Core Flash Sale đảm bảo lên đúng 11/11. Mini-game quay thưởng nhiều khả năng phải dời sang đợt 12/12." Đến cuối, đúng như dự báo, mini-game được hoãn — nhưng vì đã báo trước 3 tháng, không ai bất ngờ hay trách móc.
Bài học: Khi date cố định, hãy forecast scope và phân tầng Must/Should/Could. Sự minh bạch sớm bảo vệ uy tín của bạn.
Ví dụ 2: Startup fintech và lời hứa với nhà đầu tư
Một startup fintech ở Hà Nội (FinViet) gọi vốn vòng Series A. CEO đã lỡ hứa với nhà đầu tư rằng tính năng "eKYC định danh điện tử" sẽ live "trong quý này". PO mới về, kiểm tra backlog: hạng mục eKYC còn ước tính 180 điểm, nhưng team mới thành lập 3 Sprint, velocity rất nhiễu: 12, 25, 18.
Vấn đề: chỉ 3 điểm dữ liệu, lại biến động lớn, nên forecast velocity-based sẽ rất thiếu tin cậy. PO trung thực nói với CEO: "Với dữ liệu hiện tại, em chỉ dám đưa dải rất rộng: 180 ÷ 12 = 15 Sprint trong kịch bản xấu, 180 ÷ 25 = 8 Sprint kịch bản tốt. Tức 4 đến 7 tháng. 'Trong quý này' là không thực tế." Thay vì im lặng cầu may, PO đề xuất cắt phạm vi: chỉ làm eKYC luồng cơ bản (chụp CMND/CCCD + đối chiếu khuôn mặt) ở MVP, hoãn phần liveness detection nâng cao. Phạm vi rút còn 90 điểm → khả thi trong quý.
CEO mang con số này quay lại đàm phán kỳ vọng với nhà đầu tư. Sau 3 Sprint nữa, khi velocity ổn định quanh 20, PO cập nhật forecast chính xác hơn và mọi thứ đi đúng hướng.
Bài học: Với team mới hoặc ít dữ liệu, dải forecast phải rộng và bạn phải nói thẳng điều đó. Đừng để một lời hứa miệng của sếp biến thành cam kết bất khả thi. Cắt scope là đòn bẩy mạnh nhất của PO.
Ví dụ 3: Đội ngân hàng số dùng Monte Carlo
Một ngân hàng số ở Đông Nam Á có đội phát triển ứng dụng mobile, đã bỏ Story Point và chuyển sang đếm throughput. Họ cần forecast khi nào hoàn thành 64 story còn lại của bản nâng cấp lớn. Lịch sử throughput 12 tuần gần nhất: 6, 4, 7, 5, 8, 3, 6, 7, 5, 4, 9, 6 item/tuần.
Thay vì chia trung bình đơn giản (64 ÷ 5.8 ≈ 11 tuần), team chạy mô phỏng Monte Carlo 10.000 lần, mỗi lần rút ngẫu nhiên từ 12 con số lịch sử cho đến khi cộng đủ 64 item. Kết quả: 50% khả năng xong trong 11 tuần, 85% khả năng xong trong 14 tuần, 95% trong 16 tuần.
PO báo cáo ban lãnh đạo: "Em cam kết theo mức 85% — tức 14 tuần — để có vùng đệm an toàn." Cách trình bày này khiến lãnh đạo tin tưởng vì nó dựa trên dữ liệu thật và thể hiện rõ mức rủi ro họ đang chấp nhận.
Bài học: Khi có đủ lịch sử dữ liệu, forecast xác suất cho câu trả lời vừa trung thực vừa dễ ra quyết định hơn một con số trung bình đơn lẻ.
Hướng dẫn từng bước
Bước 1 — Xác định phạm vi release. Gom tất cả các item thuộc release này thành một nhóm rõ ràng trong Product Backlog (dùng label, epic hoặc version). Bạn không thể forecast nếu không biết chính xác "đích đến" gồm những gì.
Bước 2 — Xác định biến cố định. Hỏi stakeholder: ngày cố định hay scope cố định? Nếu cả hai đều "cố định", hãy nhẹ nhàng giải thích rằng phải có ít nhất một biến linh hoạt — thường là chất lượng sẽ bị hy sinh nếu khóa cả hai, điều không ai muốn.
Bước 3 — Thu thập dữ liệu lịch sử. Lấy velocity hoặc throughput của 6–10 Sprint/tuần gần nhất. Bỏ qua dữ liệu quá cũ (thành phần team đã khác) và loại các Sprint bất thường (nghỉ Tết, nửa team nghỉ phép) nếu kỳ release không có bất thường tương tự.
Bước 4 — Tính ba kịch bản. Lạc quan / khả dĩ nhất / thận trọng, dựa trên velocity cao/trung bình/thấp. Nếu có công cụ, chạy thêm Monte Carlo.
Bước 5 — Cộng thêm các yếu tố ngoài development. Đừng quên thời gian cho hardening, UAT, kiểm thử bảo mật, phê duyệt pháp lý, thời gian release/deploy. Một forecast "code xong" không phải là "ra mắt được".
Bước 6 — Truyền đạt dưới dạng dải và xác suất. Trình bày bằng dải ngày kèm mức tin cậy, không phải một ngày cứng. Dùng biểu đồ trực quan nếu được.
Bước 7 — Cập nhật sau mỗi Sprint. Đây là bước quan trọng nhất và hay bị quên. Sau mỗi Sprint, cập nhật velocity, scope còn lại và phát hành lại forecast. Forecast là tài liệu sống.
Lỗi thường gặp & mẹo
Lỗi 1: Dùng một con số velocity duy nhất. "8 Sprint nữa là xong" nghe rất chắc chắn nhưng lại sai về bản chất, vì velocity luôn dao động. Luôn báo cáo dải.
Lỗi 2: Quên rằng scope sẽ phình ra. Backlog không đứng yên — refinement sẽ tạo thêm story, bug sẽ phát sinh. Hãy cộng một khoản đệm cho scope creep, hoặc theo dõi tốc độ scope tăng (scope growth rate).
Lỗi 3: Forecast một lần rồi để đó. Một forecast làm hồi đầu quý và không cập nhật chính là cam kết trá hình. Hãy biến nó thành nghi thức cuối mỗi Sprint.
Lỗi 4: Lấy velocity của Sprint "thần thánh". Một Sprint bùng nổ 45 điểm không đại diện cho năng lực bền vững. Đừng để stakeholder neo kỳ vọng vào điểm cao nhất.
Lỗi 5: Quên thời gian "non-development". UAT, kiểm thử bảo mật, phê duyệt của ngân hàng nhà nước (với fintech), app store review — tất cả ngốn thời gian thật.
Mẹo: Khi áp lực buộc "chốt một ngày", hãy đưa ra ngày ở mức tin cậy 85% thay vì 50%. Bạn sẽ về đích sớm hoặc đúng hạn nhiều hơn, và uy tín tăng dần — tốt hơn nhiều so với việc luôn trễ vì chốt theo kịch bản lạc quan.
Mẹo: Vẽ Release Burndown hoặc Burnup chart treo ở nơi mọi người thấy. Burnup đặc biệt tốt vì nó tách riêng đường "scope" và đường "đã hoàn thành", giúp stakeholder thấy rõ khi nào scope phình ra là nguyên nhân làm chậm — chứ không phải team chậm.
Bài tập thực hành
- Tính forecast cơ bản. Team của bạn có velocity 6 Sprint gần nhất: 22, 28, 19, 25, 31, 24. Phạm vi release còn 200 điểm. Hãy tính ba kịch bản (lạc quan / khả dĩ nhất / thận trọng) ra số Sprint, rồi đổi sang số tuần với Sprint 2 tuần. Viết câu trả lời bạn sẽ nói với stakeholder.
- Xử lý tình huống fixed date. Sếp yêu cầu ra mắt sau đúng 6 Sprint. Với velocity trung bình 24, hãy tính tổng điểm khả thi và phác một bảng phân tầng Must/Should/Could cho một tính năng giả định bạn đang làm. Quyết định nhóm nào nên cắt.
- Lập Release Burnup. Lấy một sản phẩm bạn quen thuộc, liệt kê 5 hạng mục lớn còn lại với ước lượng điểm. Giả lập 4 Sprint với velocity tự chọn và vẽ tay đường burnup (scope vs completed). Thử thêm một story mới vào Sprint 3 để thấy đường scope nhích lên.
- Soạn thông điệp. Viết một đoạn email 4–5 câu báo cáo forecast release cho ban giám đốc, thể hiện rõ tính dải, mức tin cậy, và cam kết cập nhật mỗi Sprint. Tránh mọi từ ngữ tạo cảm giác cam kết cứng.
Tóm tắt
Scrum không có sự kiện "Release Planning" chính thức, nhưng PO trong thực tế bắt buộc phải forecast nhiều Sprint phía trước để trả lời câu hỏi muôn thuở: "Khi nào xong?". Chìa khóa là tư duy forecast chứ không phải commitment — một dự báo xác suất, dựa trên dữ liệu, được cập nhật liên tục.
Bạn có ba công cụ chính: velocity-based (chia điểm cho velocity, dùng dải ba kịch bản), throughput-based (đếm item, bỏ tranh cãi estimation), và Monte Carlo (mô phỏng xác suất từ lịch sử, cho ra câu trả lời dạng "85% khả năng xong trước ngày X"). Luôn xác định biến nào cố định — date hay scope — vì điều đó định hình cả cách lập kế hoạch lẫn đàm phán. Khi date cố định, hãy phân tầng Must/Should/Could và forecast scope kịp được, như đội ShopFast làm với 11.11.
Tránh các bẫy kinh điển: một con số velocity duy nhất, quên scope creep, quên thời gian non-development, và tệ nhất là forecast một lần rồi bỏ đó. Hãy báo cáo bằng dải và mức tin cậy, ưu tiên chốt ở mức 85%, dùng burnup chart để minh bạch. Một PO forecast trung thực và đều đặn sẽ xây được thứ quý giá nhất với stakeholder: sự tin cậy.