Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua các bài trước về Sprint Planning, Backlog Refinement hay JQL, bạn đã biết cách thao tác trên backlog. Nhưng có một sự thật phũ phàng mà rất nhiều PM Việt Nam gặp phải sau 6-12 tháng vận hành: backlog của họ phình to thành một "bãi rác kỹ thuật số" với hàng trăm, thậm chí cả nghìn issue nằm im lìm. Không ai đọc, không ai đóng, không ai dám xóa vì sợ "biết đâu sau này cần".
Backlog là tài sản chiến lược của sản phẩm, không phải là nơi để "lưu trữ ý tưởng cho đỡ quên". Một backlog khỏe mạnh giúp team biết chính xác việc gì sắp làm, tại sao làm, và làm trong bao lâu nữa. Một backlog bệnh tật khiến mỗi buổi refinement trở thành cực hình, mỗi buổi planning phải "đào bới" lại từ đầu, và tệ nhất là làm PM mất niềm tin của stakeholder vì "hỏi gì cũng không tìm thấy".
Bài này không dạy lại cách refine (bạn đã học ở Bài 11 và Bài 48 là phần best practices) — mà tập trung vào cách giữ cho backlog luôn khỏe mạnh về lâu dài: đo sức khỏe backlog bằng chỉ số cụ thể, quy trình dọn dẹp định kỳ, và kỷ luật quản lý để backlog không bao giờ trở thành gánh nặng. Đây là kỹ năng phân biệt một PM "biết dùng Jira" với một PM "quản trị được sản phẩm".
Khái niệm cốt lõi
Backlog health là gì?
Backlog health (sức khỏe backlog) là một tập hợp các chỉ số phản ánh backlog của bạn có đang phục vụ tốt cho việc ra quyết định và lập kế hoạch hay không. Một backlog khỏe mạnh không phải là backlog ngắn nhất, cũng không phải backlog đầy đủ nhất — mà là backlog đúng độ sâu, đúng độ tươi, và đúng tỷ lệ thành phần.
Hãy tưởng tượng backlog như một kim tự tháp có ba tầng:
- Tầng đỉnh (Ready): những item đã được refine kỹ, có acceptance criteria rõ ràng, đã estimate, sẵn sàng để kéo vào sprint bất cứ lúc nào.
- Tầng giữa (Refining): những item đã có hình hài, đang được thảo luận, cần thêm thông tin trước khi ready.
- Tầng đáy (Raw / Ideas): ý tưởng thô, request mới nhận, chưa được đánh giá.
Chỉ số 1 — Refined items: đủ 2-3 sprint việc đã sẵn sàng
Đây là chỉ số quan trọng nhất. Ở đỉnh kim tự tháp, bạn cần luôn có đủ lượng công việc đã refine tương đương 2-3 sprint để team có thể pull vào bất cứ lúc nào.
Tại sao lại là 2-3 sprint mà không nhiều hơn hay ít hơn?
- Ít hơn 1 sprint: nguy hiểm. Nếu buổi planning tới mà chưa có gì ready, team sẽ phải refine ngay tại chỗ — dẫn đến estimate vội vàng, story kém chất lượng, và sprint dễ trượt.
- Nhiều hơn 3 sprint: lãng phí. Bạn đang refine cho những thứ mà 6-8 tuần nữa mới làm — và trong khoảng thời gian đó, ưu tiên rất có thể đã thay đổi, thị trường đã khác, khiến công sức refine đổ sông đổ biển. Đây chính là biểu hiện của "over-planning".
Chỉ số 2 — Stale items: dọn dẹp định kỳ hàng quý
Stale item (item cũ, "ôi thiu") là những issue nằm trong backlog quá lâu mà không có động tĩnh gì — không được cập nhật, không được đưa vào sprint, không ai bình luận. Theo kinh nghiệm chung, nếu một item nằm im hơn 3-6 tháng, xác suất nó thực sự được làm gần như bằng không.
Nguyên tắc: rà soát và xóa/lưu trữ (archive) các stale item mỗi quý một lần. Đừng để chúng tích tụ. Một backlog có 500 item mà 350 trong đó là stale thì thực chất bạn chỉ có 150 item hữu ích — nhưng bạn phải "lội" qua 500 item mỗi lần tìm kiếm.
Lưu ý về mặt tâm lý: nhiều PM sợ xóa vì "biết đâu cần". Nhưng thực tế, nếu một request thực sự quan trọng, nó sẽ quay lại. Stakeholder sẽ nhắc lại, khách hàng sẽ phàn nàn tiếp. Còn nếu suốt 6 tháng không ai nhắc, đó là bằng chứng mạnh mẽ rằng nó không quan trọng.
Chỉ số 3 — Bug ratio: lý tưởng dưới 20% backlog
Bug ratio là tỷ lệ số lượng bug trên tổng số item trong backlog. Lý tưởng là dưới 20%.
Vì sao chỉ số này quan trọng? Vì tỷ lệ bug cao trong backlog là "nhiệt kế" đo sức khỏe chất lượng sản phẩm và quy trình:
- Bug ratio 10-20%: bình thường, chấp nhận được với hầu hết sản phẩm.
- Bug ratio 20-35%: cảnh báo. Có thể do Definition of Done lỏng lẻo (xem Bài 15), test không đủ, hoặc team đang gánh nợ kỹ thuật (technical debt).
- Bug ratio trên 35%: báo động đỏ. Backlog của bạn đang biến thành "danh sách sửa lỗi" thay vì "danh sách xây dựng giá trị". Team sẽ bị cuốn vào vòng xoáy vá lỗi mà không còn năng lực làm feature mới.
Các chỉ số bổ trợ khác
Ngoài ba chỉ số cốt lõi trên, một PM giỏi còn theo dõi:
- Backlog size total: tổng số item. Nếu vượt quá vài trăm và tăng đều, đó là dấu hiệu backlog đang mất kiểm soát.
- Age distribution: phân bố tuổi của item — bao nhiêu % dưới 1 tháng, 1-3 tháng, trên 3 tháng.
- Prioritization coverage: bao nhiêu % item đã được gán priority thực sự (không phải để mặc định Medium cho tất cả).
Tình huống thực tế
Tình huống 1 — Startup fintech Sài Gòn với backlog 800 item
Một startup fintech tại TP.HCM (khoảng 25 người, sản phẩm ví điện tử) mời tôi review quy trình sau khi team liên tục miss deadline. Điều đầu tiên tôi thấy khi mở Jira: backlog có 812 item. PM tự hào nói "chúng em ghi lại mọi ý tưởng, không bỏ sót gì".
Khi phân tích bằng JQL (updated <= -180d), tôi phát hiện 487 item — tức 60% — chưa được cập nhật trong hơn 6 tháng. Nhiều item là ý tưởng từ thời sản phẩm còn ở giai đoạn MVP, giờ đã hoàn toàn không còn phù hợp. Bug ratio cũng đáng lo: 210 bug trên 812 item, tức khoảng 26%.
Hệ quả cụ thể: mỗi buổi backlog refinement kéo dài gần 2 tiếng vì team phải scroll qua hàng trăm item mới tìm được thứ đáng bàn. Buổi planning thì luôn thiếu item ready, phải refine tại chỗ.
Chúng tôi làm ba việc: (1) chạy một buổi "backlog bankruptcy" — archive toàn bộ item stale hơn 6 tháng sau khi PM rà soát nhanh, đưa backlog từ 812 xuống 190 item; (2) lập bộ lọc bug riêng và cam kết dành 20% capacity mỗi sprint để hạ bug ratio; (3) thiết lập quy trình giữ luôn 2 sprint việc ready.
Sau 2 tháng, thời gian refinement giảm còn 45 phút, và tỷ lệ hoàn thành sprint (sprint completion) tăng từ 62% lên 88%.
Bài học rút ra: "Ghi lại mọi thứ" nghe có vẻ chăm chỉ nhưng thực chất là trốn tránh việc ra quyết định. Backlog càng lớn thì chi phí điều hướng càng cao, và giá trị thực tế lại càng thấp.
Tình huống 2 — Công ty gia công phần mềm và cái bẫy bug ratio
Một công ty outsourcing ở Đà Nẵng làm dự án cho khách hàng Nhật. Team dev rất giỏi về tốc độ, nhưng sau 4 sprint, PM nhận ra tốc độ làm feature chậm dần. Khi tôi nhìn vào backlog, bug ratio lên tới 41% — gần một nửa backlog là bug.
Nguyên nhân sâu xa không phải do dev kém, mà do Definition of Done chỉ dừng ở "code chạy được", không bao gồm test case và review. Mỗi feature đẩy đi lại sinh ra 2-3 bug quay về, và những bug này chất đống trong backlog, kéo capacity của sprint sau.
Giải pháp: chúng tôi siết DoD (bắt buộc unit test + code review + QA pass), đồng thời đặt một "bug budget" — nếu bug ratio vượt 25%, sprint tiếp theo sẽ ưu tiên trả nợ trước khi nhận feature mới. Sau 6 tuần, bug ratio về 18%, và velocity feature phục hồi rõ rệt.
Bài học rút ra: Bug ratio không phải chỉ số để báo cáo cho đẹp — nó là cơ chế phản hồi (feedback loop) buộc PM phải điều chỉnh quy trình phía trước (DoD, testing) chứ không chỉ dọn dẹp phía sau.
Tình huống 3 — Team quá "cẩn thận" khiến refine dư thừa
Ngược lại với hai ví dụ trên, một team product ở một công ty e-commerce Singapore lại mắc lỗi trái ngược: họ refine quá nhiều. Vào thời điểm tôi quan sát, họ có tới 6 sprint việc đã ready (khoảng 180 điểm cho velocity 30 điểm/sprint).
Nghe thì có vẻ tốt, nhưng vấn đề nảy sinh khi công ty đổi chiến lược sản phẩm giữa quý. Toàn bộ 4 sprint việc đã refine kỹ ở phía cuối trở nên vô nghĩa — hàng chục giờ họp refinement, viết acceptance criteria, estimate... đổ đi hết. Đó là lãng phí thuần túy theo tư duy Lean.
Chúng tôi điều chỉnh: chỉ giữ ready 2-3 sprint, còn lại để ở trạng thái "refining nhẹ" — đủ hiểu để ước lượng thô, chưa đi sâu chi tiết. Nhờ đó khi chiến lược đổi, chi phí "vứt đi" nhỏ hơn nhiều.
Bài học rút ra: Refine là đầu tư, và mọi đầu tư đều có rủi ro lỗi thời. Refine đúng lúc — vừa đủ 2-3 sprint — là điểm cân bằng giữa "sẵn sàng" và "linh hoạt".
Hướng dẫn từng bước
Dưới đây là quy trình vận hành backlog health mà bạn có thể áp dụng ngay:
Bước 1 — Thiết lập bộ chỉ số nền tảng. Chốt ba con số mục tiêu cho team của bạn: lượng item ready (2-3 sprint tính theo điểm), ngưỡng stale (3 hoặc 6 tháng tùy tốc độ sản phẩm), và ngưỡng bug ratio (thường là dưới 20%).
Bước 2 — Xây các JQL filter theo dõi. Tạo sẵn các bộ lọc để đo lường nhanh:
- Item ready:
project = ABC AND status = "Ready for Dev" AND sprint is EMPTY - Stale item:
project = ABC AND updated <= -180d AND status not in (Done, Closed) - Bug ratio: đếm
type = Bugso với tổng item của backlog.
Bước 3 — Chốt nhịp refinement giữ tầng ready. Trong mỗi buổi refinement định kỳ, mục tiêu số một là bổ sung đủ item ready để luôn duy trì 2-3 sprint. Đừng refine tràn lan quá xa.
Bước 4 — Lập lịch dọn dẹp hàng quý. Đặt một sự kiện lặp lại mỗi quý gọi là "Backlog Grooming Day". Trong buổi này, dùng filter stale để rà từng item cũ và quyết định: giữ (và nâng ưu tiên), archive, hay xóa hẳn.
Bước 5 — Giám sát bug ratio hàng sprint. Cuối mỗi sprint, kiểm tra bug ratio. Nếu vượt ngưỡng, kích hoạt cơ chế "bug budget" cho sprint sau.
Bước 6 — Báo cáo minh bạch cho stakeholder. Đưa các chỉ số backlog health vào báo cáo định kỳ. Điều này giúp stakeholder hiểu vì sao bạn từ chối/hoãn một số request, và xây dựng niềm tin rằng backlog đang được quản trị nghiêm túc.
Lỗi thường gặp & mẹo
Lỗi 1 — Xem backlog là nơi lưu trữ vĩnh viễn. Nhiều PM coi việc xóa item là "mất mát". Thực tế, backlog là hàng đợi công việc, không phải kho lưu trữ. Mẹo: nếu ngại xóa, hãy dùng archive (lưu trữ) — item vẫn tìm lại được qua JQL nhưng không còn làm rối backlog chính.
Lỗi 2 — Để tất cả item ở priority Medium. Khi mọi thứ đều "trung bình" thì thực chất chẳng có gì được ưu tiên. Mẹo: ép buộc phân bố ưu tiên — chỉ tối đa 20% item được gán High/Critical.
Lỗi 3 — Refine quá xa tương lai. Đừng biến buổi refinement thành cuộc thi "chuẩn bị được nhiều nhất". Mẹo: đặt luật rõ — chỉ refine chi tiết cho tối đa 3 sprint tới.
Lỗi 4 — Không tách bug ra khỏi dòng chảy chính. Khi bug lẫn với feature, bạn khó thấy được bug ratio thực. Mẹo: dùng label hoặc component riêng cho bug để lọc nhanh, và review tỷ lệ này mỗi cuối sprint.
Lỗi 5 — Dọn dẹp một mình. Nếu chỉ PM tự xóa, bạn sẽ do dự và sợ sai. Mẹo: biến "Backlog Grooming Day" thành hoạt động nhóm, có mặt tech lead và đại diện QA để quyết định nhanh và có đồng thuận.
Mẹo vàng — "Nếu nghi ngờ, hãy đóng lại". Nguyên tắc của nhiều PM giỏi: một item đáng làm thật sự sẽ luôn quay lại. Đóng một item cũ không phải là xóa bỏ ý tưởng — mà là ép thực tế kiểm chứng độ quan trọng của nó.
Bài tập thực hành
- Đo sức khỏe backlog hiện tại. Vào project Jira của bạn (hoặc dùng project mẫu). Viết ba JQL filter: item ready, stale item (updated <= -180d), và đếm số bug. Tính ra: bạn đang có bao nhiêu sprint việc ready? Bao nhiêu % là stale? Bug ratio là bao nhiêu?
- Chẩn đoán. Đối chiếu ba con số với ngưỡng lý tưởng (2-3 sprint ready, dọn stale hàng quý, bug ratio dưới 20%). Backlog của bạn đang lệch ở đâu? Viết 3 câu chẩn đoán ngắn gọn.
- Lập kế hoạch dọn dẹp. Lọc ra 20 item stale nhất. Với mỗi item, ra quyết định: giữ / archive / xóa. Ghi lý do một dòng cho mỗi quyết định.
- Thiết kế cơ chế bug budget. Nếu bug ratio của bạn vượt ngưỡng, hãy viết một quy tắc cụ thể cho team: "Nếu bug ratio > X% cuối sprint thì sprint sau dành Y% capacity cho bug." Chọn X và Y phù hợp với sản phẩm của bạn và giải thích lý do.
- Tạo dashboard. Gắn ba filter ở bài 1 lên một dashboard PM để theo dõi backlog health hàng tuần mà không phải đo thủ công.
Tóm tắt
Backlog không phải là kho chứa ý tưởng mà là một tài sản sống cần được chăm sóc. Sức khỏe backlog được đo bằng ba chỉ số cốt lõi:
- Refined items: luôn giữ đủ 2-3 sprint việc đã ready — không ít hơn (rủi ro thiếu việc), không nhiều hơn (lãng phí vì ưu tiên đổi).
- Stale items: rà soát và archive/xóa các item cũ hơn 3-6 tháng, thực hiện định kỳ mỗi quý. Item quan trọng sẽ tự quay lại.
- Bug ratio: giữ dưới 20% backlog. Tỷ lệ cao là tín hiệu cần siết Definition of Done và tăng cường testing, không phải để đổ lỗi.