Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Product Owner của một team đang chạy Scrum. Mỗi sáng Daily Scrum, team báo cáo "đang làm việc bình thường", velocity nhìn vào báo cáo cuối Sprint vẫn ổn định khoảng 30 điểm. Nhưng có một cảm giác mơ hồ rằng có gì đó không ổn: feature mất quá lâu để ra mắt, stakeholder bắt đầu sốt ruột, còn bạn thì không giải thích nổi vì sao. Velocity nói "mọi thứ ổn", nhưng thực tế thì không.
Đây chính là khoảng trống mà Cumulative Flow Diagram (CFD) — Biểu đồ Tích lũy Dòng chảy — lấp đầy. Trong khi velocity chỉ cho bạn biết team hoàn thành được bao nhiêu mỗi Sprint, CFD cho bạn thấy toàn bộ hệ thống làm việc như một dòng chảy: công việc đi vào đâu, mắc kẹt ở chỗ nào, và mất bao lâu để đi từ ý tưởng đến giao hàng. Nó là một trong số ít công cụ trực quan giúp bạn phát hiện vấn đề về flow (dòng chảy công việc) trước khi nó biến thành một cuộc khủng hoảng tiến độ.
Với một Product Owner ở cấp độ nâng cao, biết đọc CFD không phải là kỹ năng "nice-to-have". Nó là khác biệt giữa một PO chỉ biết hỏi "khi nào xong?" và một PO có thể nhìn vào biểu đồ, chỉ vào một band đang phình ra, và nói: "Bottleneck của chúng ta đang nằm ở khâu Review, không phải ở khâu code. Chúng ta cần thêm reviewer chứ không phải thêm developer." Bài học này sẽ trang bị cho bạn đúng khả năng đó.
Khái niệm cốt lõi
CFD là gì?
Cumulative Flow Diagram là một biểu đồ vùng (area chart) thể hiện số lượng công việc tích lũy ở từng trạng thái (status) trong quy trình của bạn, theo thời gian. Mỗi ngày (hoặc mỗi Sprint), bạn đếm xem có bao nhiêu work item đang nằm ở mỗi cột trên bảng Kanban/Scrum board, rồi vẽ chúng chồng lên nhau dưới dạng các "dải màu" (bands).
- Trục X (trục hoành): Thời gian — thường tính theo ngày, đôi khi theo tuần hoặc Sprint.
- Trục Y (trục tung): Số lượng work item tích lũy (cumulative count). Tích lũy nghĩa là số đếm chỉ tăng dần, không bao giờ giảm — vì một item đã từng "đi vào" hệ thống thì luôn được tính.
- Bands (các dải màu): Mỗi band tương ứng với một trạng thái trong workflow, ví dụ: Backlog → To Do → In Progress → Review → Done. Band trên cùng (Done) thể hiện công việc đã hoàn thành; các band ở dưới thể hiện công việc còn đang chảy trong hệ thống.
Đọc ba thông số vàng từ CFD
Sức mạnh thật sự của CFD nằm ở chỗ chỉ cần liếc nhìn, bạn đọc ra được ba thước đo của flow:
1. WIP (Work In Progress) — Khối lượng việc đang dở. Tại bất kỳ thời điểm nào trên trục X, khoảng cách theo chiều dọc giữa đường trên cùng (tổng việc đã đi vào hệ thống) và đường "Done" chính là tổng số việc đang nằm dở dang. Nếu khoảng cách này phình to ra theo thời gian, hệ thống đang nhận việc vào nhanh hơn tốc độ hoàn thành — một dấu hiệu nguy hiểm.
2. Approximate Lead Time / Cycle Time — Thời gian chờ. Khoảng cách theo chiều ngang giữa đường "đi vào" và đường "đi ra (Done)" tại cùng một mức tích lũy cho bạn ước lượng trung bình một item mất bao lâu để đi qua hệ thống. Khoảng cách ngang càng rộng, công việc càng "ngâm" lâu trong quy trình.
3. Throughput — Tốc độ giao hàng. Độ dốc (slope) của đường "Done" cho biết tốc độ hoàn thành công việc. Đường Done dốc lên đều đặn = team giao hàng ổn định. Đường Done nằm ngang (phẳng) = team đã ngừng hoàn thành bất cứ thứ gì — báo động đỏ.
Hình dạng lý tưởng của một CFD khỏe mạnh
Một CFD "khỏe" có các band gần như song song với nhau, cùng dốc lên một góc đều đặn. Điều đó nghĩa là: việc đi vào, đi qua từng trạng thái, và đi ra với tốc độ cân bằng. Các dải màu giữ độ dày tương đối ổn định.
Ngược lại, khi một band phình to dần (widening), đó là nơi công việc đang chồng chất nhanh hơn tốc độ nó được xử lý — chính là bottleneck (điểm nghẽn). Khi một band co lại thành đường mỏng hoặc biến mất, trạng thái đó đang "đói việc" (starvation) — công việc chảy qua quá nhanh, có thể vì khâu trước không cấp đủ đầu vào.
Tình huống thực tế
Tình huống 1 — Tiki: bottleneck ẩn nằm ở khâu QA
Một squad phát triển tính năng thanh toán tại một sàn thương mại điện tử lớn ở TP.HCM (tạm gọi theo mô hình Tiki) có velocity rất ổn định: 28–32 story point mỗi Sprint suốt 6 Sprint liền. PO khá hài lòng cho đến khi phòng kinh doanh phàn nàn rằng feature "trả góp 0%" đã được cam kết từ 2 tháng trước mà vẫn chưa lên production.
Khi PO dựng CFD cho squad này, bức tranh hiện ra rõ ràng: band "In Progress" (code) khá mỏng và ổn định, nhưng band "In Review/QA" thì phình to liên tục suốt 8 tuần. Developer hoàn thành code nhanh, đẩy sang QA, rồi QA chỉ có một tester duy nhất phải kiểm thử thủ công cho cả squad. Công việc dồn ứ ở đó như xe cộ kẹt trước một trạm thu phí.
Bài học rút ra: Velocity vẫn đẹp vì story point cuối cùng vẫn được tính là Done (chỉ là muộn). Nhưng CFD phơi bày rằng lead time đã âm thầm kéo dài từ 5 ngày lên 19 ngày. Giải pháp không phải là tuyển thêm developer (band In Progress vốn đã ổn), mà là bổ sung năng lực QA hoặc đầu tư automation test. PO đã dùng chính tấm CFD này để thuyết phục ban lãnh đạo cấp ngân sách cho một QA automation engineer — một lập luận bằng dữ liệu mạnh hơn nhiều so với "team em thấy hơi chậm".
Tình huống 2 — Một fintech ở Singapore: WIP phình to vì nhận quá nhiều việc
Một startup fintech ở Singapore có hai team chung một Product Backlog. Để "tận dụng tối đa con người", PO liên tục cho phép team bắt đầu nhiều story cùng lúc — cứ ai rảnh tay là kéo việc mới vào. Nhìn Daily Scrum thì ai cũng bận rộn, không ai ngồi chơi.
CFD theo dõi trong 10 tuần cho thấy đường "To Do + In Progress" phình ra ngày càng rộng so với đường Done — khoảng cách dọc (WIP) tăng từ 12 item lên 41 item. Đường Done thì độ dốc gần như không đổi. Nói cách khác: nhận việc vào nhiều gấp đôi nhưng giao ra vẫn y nguyên. Việc dở dang chất đống, context-switching khiến mọi thứ chậm lại, và lead time tăng vọt.
Bài học rút ra: Bận rộn không đồng nghĩa với hiệu quả. Khi team áp dụng WIP limit (giới hạn số việc làm song song) — buộc phải "stop starting, start finishing" (ngừng bắt đầu, tập trung hoàn thành) — chỉ sau 4 tuần, band WIP co lại, đường Done bắt đầu dốc hơn rõ rệt, và lead time trung bình giảm 35%. CFD chính là công cụ giúp PO nhìn thấy được tác hại của việc nhồi nhét WIP, thứ mà mắt thường ở Daily Scrum không thể thấy.
Tình huống 3 — Đường Done nằm phẳng cuối Sprint tại một agency ở Hà Nội
Một software agency tại Hà Nội nhận thấy CFD của một dự án outsourcing có một hình dạng kỳ lạ lặp đi lặp lại: trong 7 ngày đầu mỗi Sprint hai tuần, đường Done nằm phẳng hoàn toàn — không có gì được hoàn thành. Tất cả các band dưới (To Do, In Progress) đều phình lên. Rồi đến 3 ngày cuối Sprint, đường Done đột ngột dốc đứng lên khi mọi thứ được "đẩy" sang Done cùng lúc.
Đây là hiện tượng "water-Scrum-fall" kinh điển: team bắt đầu tất cả mọi story cùng lúc đầu Sprint, làm dở dang song song, rồi dồn toàn bộ vào QA và đóng việc vào phút chót.
Bài học rút ra: Một dòng chảy lành mạnh phải có đường Done dốc lên đều đặn xuyên suốt Sprint, chứ không phải dồn cục vào cuối. Hình dạng "bậc thang dốc đứng cuối Sprint" cảnh báo rủi ro cực lớn: nếu có bất kỳ trục trặc nào ở 3 ngày cuối, cả Sprint sẽ trượt mục tiêu. PO đã làm việc với team để chia nhỏ story và áp dụng nguyên tắc hoàn thành từng item một, giúp đường Done trở nên mượt mà và giảm rủi ro "vỡ Sprint".
Hướng dẫn từng bước
Dưới đây là quy trình để bạn tự dựng và đọc một CFD:
Bước 1 — Xác định các trạng thái (workflow states). Liệt kê các cột trên board của team theo đúng thứ tự dòng chảy, ví dụ: Backlog → To Do → In Progress → Review → Done. Mỗi trạng thái sẽ là một band. Đừng tạo quá nhiều band (trên 6–7 sẽ rối); gộp các trạng thái phụ nếu cần.
Bước 2 — Đếm tích lũy mỗi ngày. Vào cuối mỗi ngày làm việc, đếm tổng số item đã đi qua hoặc đang ở mỗi trạng thái. Nhớ nguyên tắc: con số tích lũy chỉ tăng. Một item ở "Done" hôm nay thì mãi mãi được tính vào tổng Done.
Bước 3 — Vẽ biểu đồ vùng chồng (stacked area chart). Trục X là ngày, trục Y là số đếm tích lũy. Vẽ band Done dưới cùng (hoặc trên cùng tùy quy ước, miễn nhất quán), rồi chồng các band còn lại lên. Hầu hết công cụ như Jira, Azure DevOps, hay thậm chí Google Sheets đều dựng được.
Bước 4 — Đọc ba thông số. Đo khoảng cách dọc (WIP), khoảng cách ngang (lead time gần đúng), và độ dốc của đường Done (throughput). Ghi lại xu hướng theo thời gian, đừng chỉ nhìn một thời điểm.
Bước 5 — Săn tìm band phình to. Quét từ trái sang phải xem band nào dày lên dần. Đó là ứng viên bottleneck số một. Đặt câu hỏi: vì sao công việc dồn lại ở đây? Thiếu người? Phụ thuộc bên ngoài? Tiêu chí chuyển trạng thái không rõ?
Bước 6 — Hành động và theo dõi lại. Sau khi can thiệp (thêm WIP limit, bổ sung năng lực, gỡ phụ thuộc), tiếp tục theo dõi CFD để xác nhận band đó co lại và đường Done dốc hơn. CFD là vòng lặp cải tiến, không phải báo cáo một lần.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm CFD với Burndown/Burnup. Burndown cho bạn biết còn lại bao nhiêu trong Sprint hiện tại; CFD cho bạn thấy dòng chảy của cả hệ thống qua nhiều trạng thái và nhiều Sprint. Đừng kỳ vọng CFD trả lời câu hỏi "Sprint này có xong không" — đó là việc của burndown. CFD trả lời "hệ thống của tôi có khỏe không, và nghẽn ở đâu".
Lỗi 2 — Bỏ sót band Backlog/To Do nên không thấy WIP thật. Nếu chỉ vẽ band In Progress và Done, bạn bỏ lỡ việc đang chất đống ở hàng chờ. Hãy đưa cả các trạng thái chờ vào để thấy bức tranh đầy đủ.
Lỗi 3 — Diễn giải một thời điểm thay vì xu hướng. Một band phình ra trong một ngày có thể chỉ là nhiễu. Hãy nhìn xu hướng qua nhiều tuần. Bottleneck thật sự là thứ phình liên tục, không phải một cú gồ ghề nhất thời.
Lỗi 4 — Định nghĩa trạng thái không nhất quán. Nếu team không thống nhất "thế nào là In Review", item sẽ bị đếm lung tung và CFD vô nghĩa. Hãy gắn CFD với một Definition of Done rõ ràng và quy ước chuyển cột minh bạch.
Mẹo: Đừng tự đọc CFD một mình rồi đi "kết tội" team. Hãy mang CFD vào Sprint Retrospective như một tấm gương khách quan để cả team cùng nhìn và cùng tìm nguyên nhân. CFD mạnh nhất khi là công cụ đối thoại, không phải công cụ giám sát.
Mẹo: Khi trình bày cho stakeholder, hãy "dịch" CFD sang ngôn ngữ kinh doanh: thay vì "band Review phình to", hãy nói "feature mất trung bình 19 ngày để ra mắt thay vì 5 ngày, và đây là điểm nghẽn".
Bài tập thực hành
- Dựng CFD đầu tiên của bạn. Lấy dữ liệu một Sprint vừa qua của team (hoặc dữ liệu giả định với 5 trạng thái). Trong Google Sheets, tạo bảng đếm tích lũy theo ngày cho từng trạng thái, rồi vẽ stacked area chart. Quan sát hình dạng tổng thể.
- Đo ba thông số. Trên CFD vừa dựng, hãy đo: (a) khoảng cách dọc WIP ở ngày giữa Sprint, (b) khoảng cách ngang ước lượng lead time, (c) độ dốc đường Done ở nửa đầu so với nửa sau Sprint. So sánh và ghi nhận xét.
- Săn bottleneck. Nhìn lại CFD của một dự án thực tế bạn từng tham gia (hoặc dùng ví dụ Tiki ở trên). Band nào phình to nhất? Đề xuất một giả thuyết về nguyên nhân và một hành động cụ thể để gỡ nghẽn.
- Kịch bản kể chuyện. Viết một đoạn 5–7 câu trình bày với một stakeholder không chuyên kỹ thuật về vấn đề mà CFD của bạn phát hiện, kèm khuyến nghị. Mục tiêu: luyện kỹ năng "dịch" dữ liệu flow sang quyết định kinh doanh.
Tóm tắt
Cumulative Flow Diagram là tấm bản đồ giúp Product Owner nhìn xuyên qua bề mặt "team đang bận rộn" để thấy dòng chảy thật sự của công việc. Với trục X là thời gian, trục Y là số item tích lũy, và các band thể hiện từng trạng thái, CFD cho bạn đọc ngay ba thước đo cốt lõi: WIP (khoảng cách dọc), lead time gần đúng (khoảng cách ngang), và throughput (độ dốc đường Done).
Một CFD khỏe mạnh có các band song song, dốc đều. Band phình to là bottleneck cần gỡ; band co mỏng là dấu hiệu đói việc; đường Done nằm phẳng là báo động đỏ. Như ba tình huống Tiki, fintech Singapore và agency Hà Nội cho thấy, CFD thường phơi bày những vấn đề mà velocity và Daily Scrum che giấu — bottleneck ở QA, WIP phình to vì nhận quá nhiều việc, và thói quen dồn việc cuối Sprint.
Là một PO, hãy biến CFD thành công cụ đối thoại trong Retrospective và ngôn ngữ thuyết phục với stakeholder. Khi bạn có thể chỉ vào một band và nói chính xác công việc đang nghẽn ở đâu và vì sao, bạn đã chuyển từ vai trò "người hỏi tiến độ" sang "người dẫn dắt cải tiến dòng chảy" — đúng tầm của một Product Owner chuyên nghiệp.