Bài 42 — Roadmap vs Backlog

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

Có một câu hỏi trong PSPO I mà rất nhiều học viên Việt Nam trả lời sai một cách "tự tin": "Scrum Guide định nghĩa artifact nào để thể hiện kế hoạch dài hạn của sản phẩm?" Nhiều người chọn ngay "Product Roadmap" — vì trong công ty họ, roadmap là thứ được dán đầy tường, được sếp review hàng quý, được khách hàng hỏi liên tục. Nó hiện diện khắp nơi, nên cảm giác nó "phải là" một phần của Scrum.

Câu trả lời đúng làm nhiều người ngỡ ngàng: Scrum Guide không hề có Roadmap. Artifact duy nhất chứa công việc cần làm cho sản phẩm là Product Backlog. Roadmap là một công cụ rất phổ biến, rất hữu ích, được hầu hết Product Owner sử dụng — nhưng nó nằm ngoài Scrum framework.

Sự phân biệt này không phải để bắt bẻ chữ nghĩa. Nó phản ánh một hiểu lầm sâu hơn về cách một Product Owner giỏi tư duy: Roadmap và Backlog phục vụ hai mục đích khác nhau, ở hai tầng trừu tượng khác nhau, cho hai nhóm người nghe khác nhau. Khi bạn lẫn lộn chúng — biến roadmap thành một danh sách tính năng có deadline cứng, hoặc biến backlog thành nơi nhồi nhét mọi ý tưởng chiến lược — bạn sẽ vừa thi rớt PSPO I, vừa quản lý sản phẩm tệ trong thực tế.

Bài này giúp bạn nắm chắc ranh giới đó: cái gì thuộc Scrum, cái gì là good practice bổ trợ, và làm sao để hai công cụ này hỗ trợ nhau thay vì giẫm chân nhau.

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

Scrum Guide có Roadmap không? — KHÔNG

Hãy nói thẳng và rõ để bạn ghi nhớ cho phần thi: Scrum Guide 2020 chỉ định nghĩa ba artifacts — Product Backlog, Sprint Backlog, và Increment. Mỗi artifact gắn với một commitment tương ứng: Product Goal, Sprint Goal, và Definition of Done. Không có "Roadmap", không có "Release Plan", không có "Gantt chart". Nếu một câu hỏi PSPO I gợi ý rằng roadmap là một artifact bắt buộc của Scrum, đó là bẫy.

Điều này KHÔNG có nghĩa Scrum cấm dùng roadmap. Scrum là một framework có chủ đích "incomplete" (chưa hoàn chỉnh) — nó chỉ định nghĩa phần khung tối thiểu, còn lại để các nhóm tự bổ sung công cụ phù hợp. Roadmap chính là một trong những bổ sung phổ biến nhất.

Product Backlog là gì — nhắc lại nhanh

Product Backlog là danh sách duy nhất, có thứ tự của mọi thứ cần thiết để cải thiện sản phẩm. Nó là nguồn công việc duy nhất cho Scrum Team. Đặc tính cốt lõi: nó emergent (luôn tiến hóa), được ordered (xếp thứ tự theo giá trị/ưu tiên), và các mục ở trên cùng được refine đủ chi tiết để "ready" đưa vào Sprint, còn các mục dưới thì thô và lớn hơn.

Backlog trả lời câu hỏi: "Cụ thể đội sẽ làm những việc gì tiếp theo, theo thứ tự nào?" Nó là tầng thực thi (execution).

Roadmap là gì

Roadmap là một công cụ giao tiếp (communication tool) thể hiện hướng đi và ý định của sản phẩm theo thời gian. Nó trả lời câu hỏi: "Chúng ta đang đi về đâu, vì sao, và (đại khái) khi nào?" Nó là tầng chiến lược/định hướng (strategic intent).

Một roadmap tốt thường được tổ chức theo outcomes (kết quả) hoặc themes (chủ đề) — ví dụ "Quý 3: Tăng tỉ lệ giữ chân người dùng mới", chứ không phải một danh sách tính năng có ngày tháng cứng nhắc kiểu "15/8: ra mắt tính năng chat". Roadmap nói về vì sao và ưu tiên chiến lược; Backlog nói về làm gì cụ thể.

So sánh trực diện

Mối quan hệ giữa hai cái

Hãy hình dung một dòng chảy alignment: Product Vision → Product Goal → Roadmap → Product Backlog → Sprint Backlog. Roadmap nằm ở giữa, đóng vai trò "cây cầu" dịch chiến lược (vision, product goal) thành các chủ đề ưu tiên, để từ đó PO derive ra các Product Backlog Item cụ thể. Roadmap không thay thế Backlog; nó thông tin hóa cho việc ordering Backlog. Backlog không thay thế Roadmap; nó là hiện thực hóa chi tiết của roadmap.

Tình huống thực tế

Tình huống 1 — Tiki và cái roadmap "deadline cứng"

Giả định một nhóm sản phẩm tại một sàn thương mại điện tử lớn như Tiki đang phát triển tính năng "TikiNOW giao nhanh 2 giờ" cho khu vực TP.HCM. Ban đầu, Head of Product trình bày với Ban giám đốc một roadmap chi tiết: "Tháng 7: tích hợp bản đồ; Tháng 8: thuật toán phân tuyến; Tháng 9: ra mắt toàn thành phố." Roadmap này thực chất là một danh sách tính năng có deadline cứng — nó trông giống một bản kế hoạch dự án (project plan) hơn là một roadmap sản phẩm.

Vấn đề bộc lộ ở Sprint thứ tư: đội phát hiện dữ liệu địa chỉ của khách hàng ở các quận ngoại thành quá nhiễu, khiến thuật toán phân tuyến giao trong 2 giờ là bất khả thi nếu không làm sạch dữ liệu trước. Nhưng vì roadmap đã "hứa tháng 9 ra mắt toàn thành phố" với cả phòng marketing và sales, áp lực buộc đội phải ship một phiên bản nửa vời, dẫn đến tỉ lệ giao trễ 23% trong tuần đầu và làn sóng phàn nàn.

Diễn giải: Roadmap ở đây đã bị nhầm thành commitment cứng. Họ đặt output (ra mắt tính năng X vào ngày Y) lên trên outcome (khách hàng nhận hàng nhanh và tin cậy). Khi thực tế thay đổi (dữ liệu xấu), roadmap đáng lẽ phải được điều chỉnh nhờ tinh thần empiricism, nhưng nó lại trở thành một lời hứa không thể rút lại.

Bài học: Roadmap nên diễn đạt bằng outcome và themes ("Quý 3: rút ngắn thời gian giao hàng nội thành xuống dưới 2 giờ với độ tin cậy >95%"), kèm khoảng thời gian linh hoạt (now / next / later) thay vì ngày cứng. Backlog mới là nơi chứa các item cụ thể, và nó có quyền — thậm chí có nghĩa vụ — thay đổi khi đội học được điều mới.

Tình huống 2 — Startup fintech và cái backlog "nuốt trọn" chiến lược

Một startup fintech ở Singapore (gọi là PayLah-clone, ~25 người) không hề có roadmap. Triết lý của founder là "agile thì chỉ cần backlog thôi". Toàn bộ định hướng sản phẩm nằm trong một Product Backlog dài 600 items trên Jira. PO mới — một bạn người Việt vừa lên vai trò — kế thừa mớ này và nhanh chóng phát hiện vấn đề.

Khi CEO hỏi "Sáu tháng tới chúng ta tập trung vào điều gì?", PO không có câu trả lời gọn. Anh chỉ có thể mở Jira và cuộn qua hàng trăm ticket. Bộ phận sales muốn biết "khi nào có tính năng thanh toán QR xuyên biên giới?" để chốt hợp đồng — không ai trả lời được vì câu trả lời chôn đâu đó giữa 600 items. Tệ hơn, vì không có tầng chiến lược nào ở trên, việc ordering backlog trở nên tùy hứng: ai la to nhất thì item của người đó được kéo lên đầu.

PO quyết định xây một roadmap đơn giản theo định dạng now/next/later, chỉ gồm 5 themes lớn cho 2 quý tới, mỗi theme gắn với một outcome đo được. Sau hai tuần, các cuộc họp với stakeholder ngắn lại đáng kể; sales tự định vị được kỳ vọng; và quan trọng nhất, mỗi khi refine backlog, đội có một "ngọn hải đăng" để hỏi: "Item này có phục vụ theme nào trên roadmap không? Nếu không, vì sao nó ở top?"

Bài học: Backlog không thể gánh vai trò giao tiếp chiến lược. Một danh sách dài, chi tiết, đúng-thứ-tự rất tuyệt cho đội thực thi, nhưng vô dụng khi cần truyền tải direction cho người ngoài đội. Roadmap lấp đúng khoảng trống đó. Lưu ý: roadmap này nằm ngoài Scrum Guide, nhưng nó hoàn toàn tương thích và bổ trợ cho Scrum.

Tình huống 3 — Câu hỏi kiểu PSPO I

Trong một buổi luyện đề, học viên gặp câu: "Một stakeholder yêu cầu Product Owner cam kết roadmap 12 tháng với ngày ra mắt cụ thể cho từng tính năng. PO nên làm gì?" Bốn lựa chọn: (A) Cam kết và đưa vào Product Backlog như các item bắt buộc theo ngày; (B) Từ chối hoàn toàn vì Scrum không có roadmap; (C) Cung cấp một roadmap thể hiện direction và outcomes, đồng thời giải thích rằng do bản chất empirical, các chi tiết và thời điểm sẽ được điều chỉnh khi đội học hỏi; (D) Chuyển yêu cầu cho Scrum Master xử lý.

Đáp án đúng là (C).

Diễn giải: (A) sai vì biến roadmap thành cam kết cứng, đi ngược empiricism và biến forecast thành commitment. (B) sai vì cực đoan — roadmap không cấm, nó hữu ích, từ chối hoàn toàn là quản lý sản phẩm tồi. (D) sai vì đây là trách nhiệm về giá trị và stakeholder của PO, không "đẩy" cho Scrum Master. (C) cân bằng đúng: PO vẫn giao tiếp direction (đáp ứng nhu cầu chính đáng của stakeholder) nhưng giữ tính linh hoạt thực nghiệm.

Bài học: PSPO I rất thích thử bạn ở vùng xám giữa "Scrum không định nghĩa X" và "vậy thì X bị cấm". Hai mệnh đề đó hoàn toàn khác nhau. Roadmap là ví dụ kinh điển: không thuộc Scrum, nhưng được khuyến khích như good practice.

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

Đây là quy trình thực tế để PO vận hành Roadmap và Backlog song song một cách lành mạnh.

• Bắt đầu từ Product Goal. Trước khi vẽ bất cứ thứ gì, xác định Product Goal hiện tại — mục tiêu dài hạn mà sản phẩm đang hướng tới. Roadmap phải phục vụ Product Goal, không được mâu thuẫn.

• Vẽ roadmap theo outcomes, không theo features. Chia thành 3 khung thời gian mềm: Now (đang/sắp làm, rõ ràng nhất), Next (kế tiếp, còn linh hoạt), Later (xa, chỉ là ý định). Mỗi mục là một outcome hoặc theme, kèm chỉ số thành công nếu có. Tránh ngày tháng cứng.

• Derive backlog items từ roadmap. Với theme đang ở "Now", PO bẻ nhỏ thành các Product Backlog Item cụ thể, đưa vào Product Backlog và ordered theo giá trị. Đây là điểm roadmap "đổ" vào backlog.

• Giữ một liên kết hai chiều. Mỗi PBI quan trọng nên truy được về một theme trên roadmap (giúp giải thích "vì sao làm cái này"). Ngược lại, khi đội học được điều mới từ Sprint Review, thông tin đó cập nhật lại roadmap.

• Cập nhật roadmap định kỳ. Roadmap không phải tài liệu "vẽ một lần rồi treo tường". Sau mỗi vài Sprint hoặc khi có dữ liệu thị trường mới, review và điều chỉnh. Đây chính là inspect & adapt áp dụng cho tầng chiến lược.

• Giao tiếp đúng công cụ cho đúng người. Khi nói với stakeholder/lãnh đạo/sales → dùng roadmap. Khi nói với Developers trong Sprint Planning/Refinement → dùng backlog. Đừng mang một backlog 600-dòng ra trình bày trước Ban giám đốc, và đừng bắt Developers planning từ một roadmap mơ hồ.

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

Lỗi 1 — Tin rằng Roadmap là artifact của Scrum. Đây là lỗi thi cử kinh điển. Ghi nhớ: chỉ có 3 artifacts (Product Backlog, Sprint Backlog, Increment). Roadmap, release plan, burndown chart… đều nằm ngoài.

Lỗi 2 — Roadmap thành danh sách tính năng có deadline cứng. Đây là cái bẫy phổ biến nhất ngoài đời. Khi roadmap chỉ là Gantt chart các feature với ngày ra mắt, nó giết chết tính linh hoạt và biến forecast thành lời hứa không thể đổi. Mẹo: ép bản thân diễn đạt mỗi mục roadmap bằng câu "Chúng ta muốn đạt được [outcome] để [lý do]", thay vì "Ra mắt [feature] vào [ngày]".

Lỗi 3 — Không có roadmap, nhồi mọi thứ vào backlog. Backlog phình to thành nơi chứa cả chiến lược lẫn chi tiết, khiến cả đội lẫn stakeholder mất phương hướng. Mẹo: nếu một stakeholder không-thuộc-đội cần hiểu định hướng, đó là tín hiệu bạn cần roadmap.

Lỗi 4 — Lẫn lộn người nghe. Trình bày backlog chi tiết cho lãnh đạo (họ ngộp), hoặc trình bày roadmap mơ hồ cho Developers (họ không planning được). Mẹo: luôn tự hỏi "Ai đang nghe? Họ cần direction hay cần execution detail?"

Lỗi 5 — Để roadmap đóng băng. Vẽ một lần đầu năm rồi không động tới. Mẹo: gắn việc review roadmap vào một nhịp cố định (ví dụ mỗi 2–4 Sprint hoặc sau mỗi Product Goal milestone).

Mẹo tổng: Hãy nhớ một câu thần chú phân biệt — "Roadmap là lời hứa về hướng đi (direction), không phải lời hứa về tính năng (features). Backlog là kế hoạch cho việc tiếp theo, không phải kho lưu trữ mọi ý tưởng."

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

• Phân loại nhanh. Với mỗi mục sau, ghi "Roadmap" hay "Backlog": (a) "As a user, I want to reset my password via OTP"; (b) "Quý 4: Mở rộng thanh toán sang thị trường Thái Lan"; (c) "Fix bug crash khi upload ảnh >10MB"; (d) "Now: Tăng tỉ lệ chuyển đổi onboarding lên 40%". (Gợi ý: a và c là backlog items; b và d là roadmap themes/outcomes.)

• Sửa roadmap xấu. Cho roadmap sau: "T7: ra mắt chat; T8: ra mắt video call; T9: ra mắt nhóm chat". Hãy viết lại theo định dạng now/next/later dựa trên outcome. Tự hỏi: outcome thực sự đứng sau ba feature này là gì?

• Tình huống PSPO I. Tự ra một câu hỏi trắc nghiệm 4 đáp án về chủ đề "stakeholder đòi cam kết roadmap cứng", trong đó có 1 đáp án đúng và 3 distractor hợp lý. So sánh với Tình huống 3 ở trên.

• Áp dụng vào công việc của bạn. Nếu bạn đang làm PO/PM: sản phẩm của bạn hiện có roadmap không? Nó đang được diễn đạt bằng outcome hay feature-with-deadline? Viết lại 3 mục roadmap gần nhất theo outcome và kiểm tra xem có truy được xuống các backlog item tương ứng không.

Tóm tắt

• Scrum Guide KHÔNG có Roadmap. Chỉ có 3 artifacts: Product Backlog, Sprint Backlog, Increment. Đây là điểm thi quan trọng.
• Nhưng Roadmap rất hữu ích và hoàn toàn tương thích với Scrum — nó là một good practice phổ biến để giao tiếp direction tới stakeholder, lãnh đạo, sales và khách hàng.
• Roadmap = tầng chiến lược, trả lời "đi về đâu, vì sao", tổ chức theo outcomes/themes và khung now/next/later. Backlog = tầng thực thi, trả lời "làm gì tiếp theo, theo thứ tự nào", chứa các item cụ thể đã ordered.
• Mối quan hệ: Vision → Product Goal → Roadmap → Product Backlog → Sprint Backlog. Roadmap thông tin hóa cho việc ordering backlog; backlog hiện thực hóa roadmap.
• Hai cái bẫy lớn: biến roadmap thành danh sách feature có deadline cứng (giết empiricism), và nhồi cả chiến lược lẫn chi tiết vào backlog (mất phương hướng).
• Phân biệt then chốt cho PSPO I: "Scrum không định nghĩa X" KHÁC với "Scrum cấm X". Roadmap không thuộc Scrum, nhưng được khuyến khích. Một PO giỏi dùng cả hai, đúng công cụ cho đúng người nghe.