Mở đầu — vì sao bài này quan trọng
Hãy bắt đầu bằng một câu hỏi mà rất nhiều học viên ôn thi PSPO I hay vấp: "Release Planning có còn là một phần của Scrum không?"
Nếu bạn mở Scrum Guide 2020 ra và tìm cụm từ "Release Planning", bạn sẽ không thấy nó ở đâu cả. Không có event tên là Release Planning. Không có artifact, không có timebox cố định. Điều này khiến nhiều người nhầm tưởng rằng "lập kế hoạch phát hành" đã biến mất khỏi thế giới Scrum hiện đại. Đó là một hiểu lầm nguy hiểm — cả cho công việc thực tế lẫn cho phòng thi.
Sự thật là: Scrum bỏ Release Planning ra khỏi danh sách các event chính thức, nhưng quyết định khi nào phát hành (release decision) vẫn là trách nhiệm rõ ràng của Product Owner. Scrum Guide 2020 viết: "An Increment may be released to stakeholders prior to the end of the Sprint... a Sprint could be considered a short project". Mỗi Sprint tạo ra ít nhất một Increment khả dụng (usable Increment), và việc phát hành Increment đó ra sao, vào lúc nào, theo nhịp nào — đó là quyền và nghĩa vụ của PO trong vai trò tối đa hóa giá trị.
Bài này quan trọng vì nó chạm đúng vào ranh giới giữa "lý thuyết thuần Scrum" và "thực tế làm sản phẩm". Trong phòng thi PSPO I, người ta sẽ thử bẫy bạn bằng những câu hỏi như "Khi nào team được phép release?" hoặc "Ai quyết định phát hành?". Còn ngoài đời, hiểu sai về release planning khiến PO hoặc ôm đồm một bản kế hoạch cứng nhắc kiểu waterfall, hoặc buông lỏng đến mức sản phẩm chẳng bao giờ tới tay khách hàng. Chúng ta sẽ gỡ cả hai thái cực đó.
Khái niệm cốt lõi
Release Planning là gì — và không là gì
Trong các phiên bản Scrum Guide rất cũ (trước 2011), Release Planning từng được nhắc tới như một hoạt động lập kế hoạch ở cấp cao hơn Sprint: dự báo nhiều Sprint sẽ cần để hoàn thành một tập tính năng, ước lượng ngày phát hành, vẽ release burndown. Khi Scrum trưởng thành, các tác giả Ken Schwaber và Jeff Sutherland gỡ bỏ nó khỏi guide, không phải vì nó vô dụng, mà vì hai lý do:
- Nó không phải là một event bắt buộc để khung Scrum vận hành. Scrum cố tình tối giản (minimally sufficient).
- Tư duy "release lớn theo lịch cố định" đi ngược lại tinh thần phát hành liên tục (continuous delivery) mà Scrum khuyến khích.
Tách bạch "Done" và "Released"
Đây là phân biệt cốt lõi nhất của bài. Một Increment đạt Definition of Done (DoD) nghĩa là nó có thể phát hành (releasable) — nhưng có thể phát hành khác với đã phát hành.
- Done / Releasable: Increment đã đủ chất lượng, tích hợp xong, không còn việc dở dang để có thể đưa ra dùng. Mỗi Sprint phải tạo ra ít nhất một Increment như thế.
- Released: Quyết định kinh doanh để thực sự đưa Increment đó tới người dùng cuối.
Release strategy — các chiến lược phát hành
Khi nói về "release strategy", PO thường chọn giữa các mô hình sau:
1. Release on cadence (phát hành theo nhịp cố định): Ví dụ cứ cuối mỗi Sprint hoặc cứ mỗi 2 tuần là release. Dễ dự đoán, tốt cho team mới, tạo kỷ luật.
2. Release on demand (phát hành theo nhu cầu): Release bất cứ khi nào có giá trị đủ lớn hoặc khi thị trường cần. Linh hoạt, hợp với continuous delivery, nhưng đòi hỏi hạ tầng kỹ thuật tốt.
3. Feature-based release (phát hành theo tập tính năng): Gom các tính năng thành một "gói" có ý nghĩa với người dùng rồi mới release. Hợp với sản phẩm B2B, sản phẩm cần đào tạo người dùng.
4. Dark launch / feature toggle: Code đã được deploy lên production nhưng tính năng bị "tắt", chỉ bật cho một nhóm nhỏ trước. Đây là kỹ thuật tách hoàn toàn "deploy" khỏi "release" — cực kỳ mạnh để giảm rủi ro.
Vai trò của PO trong release
Hãy nhớ công thức này cho phòng thi: Developers quyết định "Done" về mặt kỹ thuật; PO quyết định "Release" về mặt giá trị. PO là người duy nhất chịu trách nhiệm tối đa hóa giá trị sản phẩm, nên quyết định phát hành — đánh đổi giữa "ra sớm để học" và "ra muộn để hoàn chỉnh" — thuộc về PO. PO làm việc này dựa trên thông tin từ stakeholder, từ thị trường, và từ chính Developers về tính khả thi kỹ thuật.
Tình huống thực tế
Ví dụ 1 — Tiki và quyết định release theo nhịp mùa cao điểm
Giả sử một nhóm sản phẩm tại một sàn thương mại điện tử lớn ở Việt Nam (lấy bối cảnh kiểu Tiki) đang phát triển tính năng "đặt hàng nhanh 1 chạm". Team chạy Sprint 2 tuần và sau Sprint thứ 3 đã có một Increment Done: luồng đặt hàng hoạt động, đã test, đã tích hợp.
Về kỹ thuật, họ hoàn toàn có thể release ngay. Nhưng PO nhìn vào lịch kinh doanh: còn 5 tuần nữa là tới đợt sale 11/11 — thời điểm lưu lượng tăng gấp 8 lần. PO quyết định không release ngay, mà:
- Bật tính năng cho 5% người dùng dưới dạng A/B test ở các Sprint kế tiếp (dark launch).
- Dùng dữ liệu để tinh chỉnh tỷ lệ chuyển đổi (conversion).
- Release rộng rãi đúng trước 11/11 để tận dụng đỉnh lưu lượng.
Ví dụ 2 — Startup fintech ở Đông Nam Á và bẫy "big bang release"
Một startup fintech (giả định, kiểu một ví điện tử mới nổi tại khu vực) có PO tên Linh. Linh được sếp yêu cầu lập một "release plan" cho 6 tháng tới với đầy đủ ngày phát hành từng tính năng: tháng 1 ra tính năng A, tháng 3 ra B và C, tháng 6 ra D. Bản kế hoạch trông rất đẹp trên slide.
Vấn đề xuất hiện ở tháng thứ 2: phản hồi người dùng cho thấy tính năng A gần như không ai dùng, trong khi nhu cầu về một tính năng E (chưa hề có trong kế hoạch) lại rất lớn. Nhưng vì đã "cam kết" release plan với ban lãnh đạo, Linh ngần ngại thay đổi, cứ tiếp tục đẩy B và C theo lịch. Kết quả: 6 tháng trôi qua, sản phẩm đủ tính năng theo kế hoạch nhưng tăng trưởng người dùng vẫn lẹt đẹt.
Sau đó Linh chuyển cách làm: thay vì một release plan cứng 6 tháng, cô duy trì một release forecast cập nhật mỗi Sprint, công khai với stakeholder rằng đây là dự báo, không phải cam kết. Cô release theo nhu cầu, ưu tiên học nhanh. Tính năng E được đưa lên ưu tiên cao và release chỉ sau 3 Sprint, kéo lại đà tăng trưởng.
Bài học: Release plan kiểu waterfall — cam kết cứng nhiều tháng — mâu thuẫn với empiricism. PSPO I rất thích bẫy ở điểm này: release planning trong Scrum phải là forecast có thể điều chỉnh, không phải hợp đồng cố định. (Chúng ta sẽ đào sâu phân biệt forecast vs commitment ở một bài riêng — ở đây chỉ cần nắm tinh thần.)
Ví dụ 3 — Team B2B và release theo gói có ý nghĩa
Một công ty phần mềm Việt Nam bán giải pháp quản lý nhân sự (HRM) cho doanh nghiệp. Khách hàng của họ là các phòng nhân sự — những người không thích phần mềm thay đổi liên tục mỗi tuần vì họ phải đào tạo lại nhân viên mỗi lần.
PO ở đây đối mặt một nghịch lý: team đạt Increment Done mỗi Sprint, nhưng khách hàng không muốn nhận release hàng tuần. Giải pháp của PO:
- Vẫn giữ kỷ luật "mỗi Sprint một Increment Done" (đúng Scrum).
- Nhưng gom các Increment thành một bản release lớn mỗi quý, kèm tài liệu hướng dẫn và buổi đào tạo (feature-based release).
- Với các bản vá lỗi quan trọng (hotfix), release ngay lập tức không chờ quý.
Hướng dẫn từng bước
Nếu bạn là PO và cần "lập kế hoạch phát hành" theo đúng tinh thần Scrum hiện đại, đây là quy trình thực dụng:
Bước 1 — Bắt đầu từ Product Goal. Mọi release đều nên phục vụ một mục tiêu sản phẩm rõ ràng. Hỏi: "Release này đưa chúng ta gần Product Goal hơn ở điểm nào?" Nếu không trả lời được, có thể bạn đang release vì lý do sai.
Bước 2 — Xác định "đơn vị giá trị có thể phát hành" nhỏ nhất. Đừng hỏi "cần bao nhiêu tính năng để release", hãy hỏi "đâu là lát cắt nhỏ nhất mang lại giá trị thật hoặc cho phép học được điều gì đó". Đây là tư duy thin slice.
Bước 3 — Chọn release strategy phù hợp. Cadence, on-demand, feature-based hay dark launch? Quyết định dựa trên: đặc thù khách hàng, năng lực kỹ thuật (CI/CD), mức độ rủi ro, và bối cảnh thị trường.
Bước 4 — Tạo release forecast, không phải release commitment. Dùng dữ liệu velocity hoặc throughput của team để dự báo mốc thời gian. Luôn truyền đạt với stakeholder bằng ngôn ngữ "dự kiến / khả năng cao", kèm khoảng tin cậy, không phải một ngày chốt cứng.
Bước 5 — Cập nhật forecast sau mỗi Sprint. Tại Sprint Review, dùng Increment và phản hồi mới để điều chỉnh dự báo. Release plan sống và thở theo nhịp Sprint.
Bước 6 — Tách deploy khỏi release khi có thể. Đầu tư vào feature toggle để có thể đưa code lên production an toàn mà chưa "bật" cho người dùng. Điều này cho PO quyền linh hoạt tối đa về thời điểm release.
Bước 7 — Đo lường sau release. Một release chưa kết thúc khi code lên production; nó kết thúc khi bạn biết nó có tạo ra outcome mong muốn không. Gắn release với metric cụ thể (tỷ lệ chuyển đổi, retention, doanh thu...).
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ rằng phải release vào cuối Sprint. Sai. Sprint kết thúc tạo ra Increment Done, nhưng release có thể xảy ra bất cứ lúc nào — giữa Sprint, cuối Sprint, hoặc gom nhiều Sprint. Trong phòng thi, nếu thấy đáp án nói "team phải release ở cuối mỗi Sprint", hãy cảnh giác.
Lỗi 2 — Coi release plan là cam kết cứng. Bản kế hoạch nhiều tháng với ngày chốt từng tính năng là tư duy waterfall đội lốt Scrum. Hãy dùng từ "forecast".
Lỗi 3 — Để Scrum Master hoặc Developers quyết định release. Quyết định Done (kỹ thuật) thuộc Developers; quyết định release (giá trị) thuộc PO. Đừng nhầm. Trong PSPO I, ai tối đa hóa giá trị thì người đó quyết định phát hành — đó là PO.
Lỗi 4 — Đợi sản phẩm "hoàn chỉnh" mới release. Mâu thuẫn với empiricism. Release sớm một lát cắt nhỏ để học thường tốt hơn release muộn một sản phẩm to.
Mẹo phòng thi: Khi gặp câu hỏi về release, hãy quét nhanh ba nguyên tắc — (1) Increment phải Done trước khi release; (2) PO quyết định release; (3) Scrum không bắt buộc nhịp release nào. Hầu hết đáp án sai sẽ vi phạm một trong ba điều này.
Mẹo thực tế: Đầu tư vào năng lực kỹ thuật (test tự động, CI/CD, feature flag) chính là đầu tư vào quyền tự do release của PO. Team càng có thể release dễ dàng, PO càng có nhiều lựa chọn chiến lược.
Bài tập thực hành
- Phân biệt khái niệm: Viết một đoạn ngắn (3–4 câu) giải thích sự khác nhau giữa "Increment Done" và "Increment Released" cho một đồng nghiệp chưa học Scrum. Dùng một ví dụ của riêng bạn.
- Chọn chiến lược: Cho ba bối cảnh sau, chọn release strategy phù hợp và giải thích vì sao: (a) một app game mobile cập nhật liên tục; (b) phần mềm kế toán cho doanh nghiệp lớn; (c) một startup đang cần học nhanh hành vi người dùng.
- Xử lý tình huống: Sếp yêu cầu bạn cam kết "release đủ 10 tính năng vào đúng ngày 30/9". Hãy soạn một câu trả lời (5–6 câu) vừa giữ được tinh thần forecast của Scrum, vừa không làm sếp cảm thấy bạn né tránh trách nhiệm.
- Tự kiểm tra phòng thi: Tự đặt 2 câu hỏi trắc nghiệm kiểu PSPO I về chủ đề release (một câu về "ai quyết định release", một câu về "khi nào được release"), kèm 4 đáp án và giải thích đáp án đúng.
Tóm tắt
- Scrum Guide 2020 không có event Release Planning, nhưng quyết định phát hành (release decision) là trách nhiệm của Product Owner trong vai trò tối đa hóa giá trị.
- Phân biệt cốt lõi: Done/Releasable ≠ Released. Mỗi Sprint phải tạo Increment Done; còn release là một quyết định kinh doanh riêng, có thể xảy ra bất cứ lúc nào.
- Release planning hiện đại là hoạt động liên tục dựa trên empiricism, thể hiện qua release forecast (dự báo, điều chỉnh được) chứ không phải release commitment cứng kiểu waterfall.
- Các chiến lược release: theo nhịp (cadence), theo nhu cầu (on-demand), theo gói tính năng (feature-based), và dark launch/feature toggle để tách deploy khỏi release.
- Phân vai rõ: Developers quyết định Done; PO quyết định Release. Đừng để nhầm vai trong cả công việc lẫn phòng thi.
- Năng lực kỹ thuật (CI/CD, automation, feature flag) chính là thứ mở rộng quyền tự do chiến lược của PO khi quyết định phát hành.