Một roadmap nhìn từ xa thường rất yên. Các ô nằm ngay ngắn theo tháng, milestone có tên đẹp, release nào cũng có vẻ biết chỗ của mình. Rồi công việc thật bắt đầu. Một khách hàng đổi ý. Một dependency trễ. Một story nhỏ hóa ra là câu hỏi sản phẩm. Một feature không ai chú ý bỗng trở nên quan trọng sau một cuộc gọi với người dùng.
Đó là lúc release planning chứng minh giá trị. Một release plan tốt không phải lời hứa rằng mọi thứ sẽ đứng yên. Nó là cách để team tiếp tục hỏi, có kỷ luật hơn: nên xây gì trước, rủi ro nào cần học sớm, scope nào có thể lùi, và evidence hiện tại đang nói gì?
Bài viết này tiếp tục reflection từ Agile Estimating and Planning của Mike Cohn, do Prentice Hall / Addison-Wesley Professional xuất bản năm 2005. Trọng tâm ở đây là release planning: prioritization, tách user story, buffer, monitoring và communication.
Release planning là đi tìm giá trị
Một ý trong sách rất đáng được nhắc kỹ: planning là một cuộc tìm kiếm giá trị. Team không chỉ trả lời “khi nào xong?” Team còn trả lời “điều gì đáng làm trước?” Câu hỏi thứ hai thường khó hơn.
Nhiều backlog được sắp theo tiếng ồn. Stakeholder nói to nhất được làm trước. Feature dễ nhất được làm trước. Việc thuận tiện cho kỹ thuật được làm trước. Agile release planning cố đưa vào một bộ kính tốt hơn: value, cost, risk và learning.
Ví dụ một product team có ba ứng viên: dashboard mới, tool reconciliation cho billing, và redesign màn onboarding. Dashboard có thể hào hứng, nhưng nếu reconciliation giảm việc thủ công của finance mỗi tuần và giảm lỗi support, value của nó có thể cao hơn cảm giác ban đầu. Onboarding redesign có thể tạo product learning vì chưa ai hiểu vì sao user rớt. Thứ tự đúng không rõ cho tới khi team nói về value và uncertainty cùng lúc.
Một cách nhìn cụ thể hơn là đặt ba dòng lên bàn. Dashboard mới có thể giúp sales demo tốt hơn, nhưng chưa chắc tạo revenue ngay. Reconciliation tool có thể tiết kiệm 6 giờ thao tác mỗi tuần, giảm sai sót đối soát và làm finance bớt phải hỏi engineer tra log. Onboarding redesign có thể không tạo tiền ngay, nhưng nếu đang mất 40% user ở bước xác minh email, nó mở ra tri thức sản phẩm quan trọng. Khi nói ra được các dòng value này, cuộc họp ưu tiên bớt giống tranh luận gu cá nhân.
Ưu tiên bằng value, risk và learning
Tư duy value-risk của Cohn hữu ích vì nó ngăn team đối xử mọi việc high-value như nhau. Một feature high-value nhưng low-risk có thể chờ một chút. Một feature vừa high-value vừa high-risk nên đi sớm hơn vì nó tạo tri thức. Nếu nó thất bại, team muốn biết điều đó khi vẫn còn thời gian đổi hướng.
Ví dụ team muốn thêm thanh toán qua ví điện tử mới. Business value cao vì nhiều khách hàng đang hỏi, nhưng risk cũng cao vì partner chưa từng tích hợp, callback có thể trễ, reconciliation chưa rõ và quy trình support sau lỗi thanh toán còn mỏng. Nếu để việc này tới cuối release, team có thể phát hiện rủi ro khi đã hết đường xoay. Làm một lát cắt nhỏ sớm hơn, ví dụ chỉ nạp tiền test cho một nhóm user nội bộ, giúp team học về API, vận hành và support trước khi cam kết rollout rộng.
| Loại công việc | Ví dụ | Bản năng planning nên có |
|---|---|---|
| Value cao, risk cao | Partner thanh toán mới, fraud rule lạ, compliance path chưa rõ. | Làm đủ sớm để học và giảm risk. |
| Value cao, risk thấp | Export được khách hàng hỏi thường xuyên, dùng data và UI pattern đã quen. | Làm sớm, nhưng không nhất thiết đầu tiên. |
| Value thấp, risk cao | Feature thử nghiệm chưa rõ user, ảnh hưởng kiến trúc lớn. | Tránh, đơn giản hóa hoặc chạy discovery slice rất nhỏ. |
| Value thấp, risk thấp | Setting nhỏ chưa có bằng chứng sử dụng nhiều. | Làm sau, hoặc giữ làm ứng viên buffer. |
Kano thêm một lăng kính khác. Có feature là must-have: khi chạy tốt thì user ít khen, nhưng thiếu nó thì họ từ chối sản phẩm. Có feature là performance: càng tốt thì hài lòng càng tăng. Có feature là delighter: user chưa chắc đã hỏi, nhưng khi có thì cảm giác sản phẩm đổi hẳn.
Một payroll product chẳng hạn không thể xem tính đúng lương là delighter. Đó là threshold feature. Flow duyệt nhanh hơn có thể là linear: càng nhanh càng tăng hài lòng. Một cảnh báo bất thường trước khi submit bảng lương có thể là delighter với một số user. Các nhóm này giúp team tránh tiêu hết năng lượng để đánh bóng sai chỗ.
Trong một app học tiếng Anh, must-have có thể là bài học chạy được, lưu tiến độ đúng và phát âm thanh ổn định. Linear feature có thể là số lượng bài luyện tập hoặc tốc độ phản hồi khi chấm bài. Delighter có thể là một gợi ý nhỏ sau khi người học sai cùng một âm nhiều lần. Nếu team dành ba sprint để làm hiệu ứng chuyển cảnh đẹp nhưng app vẫn mất tiến độ học, họ đang đầu tư vào cảm giác trong khi threshold còn thủng.
Tách story thành lát cắt có giá trị, không tách theo lớp kỹ thuật
Story splitting là một phần rất thực dụng của sách. Một story quá lớn khi nó không vừa iteration, không estimate đủ tự tin, hoặc giấu nhiều mức ưu tiên trong một câu. Câu trả lời không phải là tách thành “UI, API, database”. Cách đó chỉ tạo task kỹ thuật, không tạo tiến bộ sản phẩm có thể dùng.
Cách tách tốt hơn là lát cắt dọc. Nếu story là “người dùng có thể quản lý phương thức thanh toán”, lát cắt đầu tiên có thể là thêm một loại thẻ cho một region với validation cơ bản. Các lát sau thêm xóa thẻ, nhiều card brand, retry behavior và xử lý lỗi nâng cao. Lát đầu vẫn nên đi xuyên qua các lớp thật của hệ thống như một tracer bullet. Nó nhỏ, nhưng dạy team một điều thật.
| Story quá lớn | Lát cắt dễ học hơn | Điều team học được |
|---|---|---|
| Quản lý phương thức thanh toán | Thêm một thẻ Visa ở một region, với validation tối thiểu. | API, form, tokenization và lỗi validation có đi xuyên hệ thống được không. |
| Báo cáo doanh thu đầy đủ | Xuất CSV cho một khoảng ngày và một loại giao dịch. | Data source, permission, timezone và performance cơ bản. |
| Notification center | Hiển thị một loại thông báo trong app, chưa cần filter hay preference. | Event source, unread state và UX đọc thông báo có hợp lý không. |
Thay vì hỏi “cần những task kỹ thuật nào?”, hãy hỏi “hành vi nhỏ nhất nhìn thấy được bởi user, giúp giảm risk hoặc tạo learning, là gì?”
Điều này đặc biệt hữu ích khi priority bị trộn. Một story lớn có thể chứa một hành vi must-have, hai chi tiết nice-to-have và một yêu cầu performance chỉ quan trọng khi scale. Giữ chúng cùng nhau làm release plan cứng. Tách chúng ra cho Product Owner có lựa chọn.
Ví dụ “người dùng nhận thông báo đơn hàng” nghe như một story duy nhất, nhưng bên trong có nhiều lớp ưu tiên: email xác nhận đơn là must-have, push notification có thể là should-have, template đẹp theo brand là could-have, còn hệ thống preference phức tạp có thể chờ tới khi có đủ tín hiệu sử dụng. Khi tách như vậy, release đầu tiên vẫn có giá trị và team không bị giữ lại chỉ vì phần trang trí chưa xong.
Hãy nói rõ plan đang date-driven hay feature-driven
Release planning rõ hơn khi team gọi tên constraint. Có release date-driven: ngày cố định, scope phải thương lượng. Có release feature-driven: bộ feature cố định, ngày phải thương lượng. Nhiều vấn đề planning đến từ việc giả vờ cả hai đều cố định, trong khi vẫn mong quality không đổi.
Một deadline compliance thường là date-driven. Team cần bảo vệ must-have scope và chuẩn bị scope ưu tiên thấp để cắt. Một platform rewrite chiến lược thường là feature-driven. Nếu minimum capability chưa sẵn sàng, ship sớm có thể tạo nhiều chi phí vận hành hơn giá trị.
Ví dụ một thay đổi báo cáo thuế bắt buộc có hiệu lực từ ngày 1 tháng 7. Đây gần như chắc chắn là date-driven: form đúng, export đúng và audit trail đủ dùng phải có trước ngày đó; dashboard đẹp hơn hoặc bulk action tiện hơn có thể lùi. Ngược lại, một migration từ hệ thống billing cũ sang billing mới thường feature-driven hơn: nếu chưa có invoice generation, retry payment và reconciliation tối thiểu, việc bật ngày đẹp trên calendar chỉ làm vận hành chịu rủi ro lớn hơn.
Câu hỏi hữu ích không phải “có xong hết trước ngày này không?”. Câu hỏi hữu ích là: với ngày này, scope nào thật sự bắt buộc, scope nào tùy chọn, và evidence nào sẽ khiến mình replan? Cuộc trò chuyện đó ít căng hơn khi diễn ra sớm.
Buffer không phải lười, mà là thiết kế cho bất định
Phần buffer trong sách rất thực tế. Sự bất định không biến mất chỉ vì plan nhìn tự tin. Team có thể giấu uncertainty trong từng estimate nhỏ, hoặc thiết kế một buffer nhìn thấy được ở cấp release. Cách thứ hai thường khỏe hơn.
Feature buffer khá đơn giản: đừng biến 100% scope release thành must-have. Nếu toàn bộ plan đều bắt buộc, team không còn chỗ để học. Schedule buffer cũng tương tự, nhưng bảo vệ ngày. Mục tiêu không phải cho team thời gian rảnh. Mục tiêu là tránh việc mỗi story phải mang một worst-case estimate riêng tư và vô hình.
Hãy tưởng tượng một release 12 tuần. Nếu team lấp đầy cả 12 tuần bằng must-have work, bất kỳ bất ngờ nào cũng thành khủng hoảng. Nếu team plan core must-have quanh 8 hoặc 9 tuần và giữ scope ưu tiên thấp làm buffer, trade-off trở nên khả thi. Bản plan có khớp nối. Nó có thể uốn mà không gãy.
Trong thực tế, buffer có thể rất cụ thể. Với release 12 tuần cho checkout mới, must-have có thể là chọn sản phẩm, áp mã giảm giá, thanh toán, nhận email xác nhận và support tra cứu đơn. Should-have có thể là lưu thẻ, đề xuất voucher và trang lịch sử giao dịch đẹp hơn. Could-have là animation, theme theo campaign hoặc filter nâng cao. Nếu integration thanh toán mất thêm 2 tuần, team cắt should/could mà vẫn giữ được release có giá trị, thay vì cắt vào phần thanh toán lõi.
Mình thích làm cut line hiện rõ ngay trong release note. Ví dụ: “Release 1 bắt buộc có chọn sản phẩm, mã giảm giá, thanh toán, email xác nhận và support lookup. Saved cards nằm dưới cut line. Advanced filters là optional rõ ràng.” Một câu như vậy ngăn kỳ vọng âm thầm biến thành xung đột bất ngờ ở tuần thứ mười.
Theo dõi plan mà không biến reporting thành sân khấu
Tracking nên giúp ra quyết định. Release burndown có thể cho thấy work remaining đang giảm hay không, nhưng bar-style burndown của Cohn thêm một chi tiết quan trọng: scope mới có thể hiện xuống dưới đường baseline. Điều này quan trọng vì team có thể làm rất chăm mà vẫn không hội tụ nếu scope cứ tiếp tục phình ra.
Ví dụ sau ba iteration, team hoàn thành 42 points nhưng PO thêm 28 points vì feedback beta phát hiện thiếu export và audit log. Nếu chỉ nói “team đã burn được 42 points”, nghe có vẻ tốt. Nếu chart cho thấy phần scope mới mọc xuống dưới baseline, mọi người thấy câu chuyện thật hơn: team đang chạy tốt, nhưng release scope đang phình. Quyết định lúc này không phải ép team nhanh hơn, mà là chọn scope nào đổi lấy scope nào.
Trong iteration, task board có giá trị vì nó gần với công việc. Nó cho thấy task bị block, việc chưa verify, và story tưởng gần xong nhưng chưa được accept. Nó nên mời gọi phối hợp, không phải đổ lỗi. Khi board trở thành màn hình performance của từng cá nhân, nó mất phần lớn giá trị.
Giao tiếp về plan nên thường xuyên, trung thực và hai chiều. Một update tốt không chỉ nói “đang đúng tiến độ”. Nó nói điều gì đã thay đổi, risk nào còn lại, team tự tin ở mức nào, và quyết định nào có thể cần đưa ra. Một end-of-iteration summary ngắn có thể hữu ích hơn một report dày nếu nó có đúng context: cái gì đã accept, cái gì đổi, data nói gì, và team học được gì.
Một update tốt có thể chỉ cần vài dòng: “Iteration này accept 5/6 story. Story export CSV trượt vì data permission phức tạp hơn assumption ban đầu. Velocity ba iteration gần nhất đang quanh 28-31 points. Nếu giữ ngày release, đề xuất đưa advanced filter ra khỏi scope. Nếu giữ advanced filter, ngày release cần mở lại.” Cách viết này không né vấn đề, nhưng cũng không tạo căng thẳng thừa. Nó đặt quyết định vào đúng chỗ.
Những điều đọng lại
- Release planning là công việc về value. Team đang quyết định điều gì đáng xây trước, không chỉ đoán ngày.
- Risk có thể kéo việc lên sớm. Item vừa value cao vừa risk cao nên được học sớm.
- Story slice nên nhìn thấy được với user. Tránh tách backlog item thành các lớp kỹ thuật không tạo accepted value.
- Gọi tên constraint. Date-driven và feature-driven release cần trade-off khác nhau.
- Buffer làm uncertainty nhìn thấy được. Nó bảo vệ plan khỏi việc giả vờ mọi story đã được biết hoàn hảo.
- Tracking nên dẫn tới quyết định. Chart và board chỉ hữu ích khi chúng giúp team hành động.
Lý do Agile planning hoạt động không phải vì nó dự đoán tương lai giỏi hơn mọi cách khác. Nó hoạt động vì nó chấp nhận rằng team sẽ học thêm. Team viết plan, học từ công việc thật, cập nhật plan, và giao tiếp điều đã đổi. Vòng lặp đó lặng lẽ, lặp đi lặp lại, đôi khi hơi khó chịu. Nhưng đó cũng là cách một release giữ liên hệ với thực tế thay vì chỉ giữ liên hệ với một spreadsheet cũ.