Mở đầu — vì sao bài này quan trọng
Nếu bạn đã thi đậu PSM I, gần như chắc chắn bạn từng vẽ một đường Sprint Burndown và tự hào khoe với team rằng "chúng ta đang đi đúng tiến độ". Nhưng khi bước lên cấp độ PSM II, một câu hỏi sắc bén hơn sẽ xuất hiện: Cái biểu đồ đó thực sự nói cho bạn biết điều gì về cách team đang làm việc — hay nó chỉ đang che giấu vấn đề?
Đây là một trong những điểm khác biệt lớn nhất giữa một Scrum Master mới và một Scrum Master trưởng thành. Người mới nhìn vào đường Burndown đi xuống đẹp đẽ và yên tâm. Người có kinh nghiệm nhìn vào đó và hỏi: "Tại sao công việc lại đứng yên trong ba ngày đầu? Tại sao tới ngày cuối mới tụt một phát? Có phải team đang nhận quá nhiều việc cùng lúc không?" Burndown trả lời câu hỏi "còn bao nhiêu việc?", còn Cumulative Flow Diagram (CFD) trả lời câu hỏi sâu hơn nhiều: "công việc của chúng ta đang chảy như thế nào?"
Trong bài này, tôi muốn bạn không chỉ biết vẽ hai loại biểu đồ này, mà còn biết đọc chúng như một bác sĩ đọc phim X-quang — nhìn ra bottleneck, nhìn ra work-in-progress (WIP) đang phình to, nhìn ra lúc nào team đang bị "kẹt hàng". Khi nắm được điều này, bạn sẽ dùng dữ liệu để coaching team thay vì chỉ báo cáo tiến độ. Đó chính là tư duy của một Scrum Master ở tầm PSM II.
Khái niệm cốt lõi
Sprint Burndown — đo phần việc còn lại
Sprint Burndown là biểu đồ đơn giản nhất trong Scrum. Nó theo dõi lượng công việc còn lại (remaining work) trong một Sprint theo thời gian.
- Trục tung (Y): số việc còn lại — có thể tính bằng story points, số task, hoặc số giờ ước lượng còn lại.
- Trục hoành (X): các ngày trong Sprint.
- Mục tiêu: đường biểu đồ đi xuống và chạm mốc 0 vào ngày cuối Sprint.
Điểm mạnh của Burndown là sự đơn giản: bất kỳ ai nhìn vào cũng hiểu ngay "còn nhiều hay còn ít việc". Nó phù hợp để Developers tự theo dõi trong Daily Scrum, giúp họ tự hỏi: "Với nhịp độ này, liệu chúng ta có đạt Sprint Goal không?"
Giới hạn của Burndown
Đây là phần mà PSM II thực sự quan tâm. Burndown có những điểm mù nguy hiểm:
- Nó chỉ thấy phần còn lại, không thấy dòng chảy. Một đường Burndown đi xuống đều không cho biết công việc đang kẹt ở đâu. Việc có thể "xong code" nhưng tắc ở khâu test cả tuần — Burndown vẫn không tụt vì task chưa được tính là Done.
- Hiện tượng "đường ngang rồi rơi tự do". Rất nhiều team có Burndown phẳng lì suốt nửa đầu Sprint rồi tụt dốc đột ngột ở cuối. Điều này thường nghĩa là team đang ôm quá nhiều việc song song (WIP cao), không có gì thực sự hoàn thành cho đến phút chót — một dấu hiệu rủi ro lớn.
- Scope thay đổi làm méo hình. Khi thêm việc giữa Sprint, đường có thể đi lên, gây nhầm lẫn. Burndown không phân biệt được "chậm vì làm chậm" với "chậm vì thêm việc".
- Nó che giấu bottleneck. Burndown gộp tất cả thành một con số "còn lại", nên bạn không thấy được khâu nào trong quy trình (Analysis → Dev → Test → Done) đang nghẽn.
Cumulative Flow Diagram (CFD) — đo dòng chảy
CFD ra đời để lấp đúng những điểm mù đó. Thay vì một đường, CFD là biểu đồ vùng xếp chồng (stacked area), mỗi vùng màu đại diện cho một trạng thái trên bảng công việc của team.
- Trục tung (Y): tổng số hạng mục công việc (work items).
- Trục hoành (X): thời gian (ngày).
- Mỗi dải màu: số việc đang ở một cột trạng thái — ví dụ To Do, In Progress, Testing, Done.
- WIP (Work in Progress): chính là độ dày theo chiều dọc của các dải đang-làm tại một thời điểm. Dải càng phình to, WIP càng cao — team đang ôm quá nhiều việc cùng lúc.
- Cycle Time: khoảng cách theo chiều ngang giữa lúc một việc bắt đầu vào quy trình và lúc nó chạm Done. Khoảng cách càng rộng, việc đi qua hệ thống càng lâu.
- Throughput: độ dốc của dải Done — tốc độ công việc hoàn thành.
Vậy dùng cái nào?
Đừng coi đây là cuộc đua loại trừ. Burndown trả lời "chúng ta có kịp Sprint Goal không?" — tốt cho việc tự quản lý trong Sprint. CFD trả lời "hệ thống làm việc của chúng ta khỏe hay bệnh?" — tốt cho việc cải tiến quy trình và coaching. Một Scrum Master PSM II dùng Burndown để giữ nhịp Sprint, và dùng CFD để chẩn đoán bệnh hệ thống.
Tình huống thực tế
Ví dụ 1 — Burndown đẹp nhưng team vẫn trượt: Tiki
Một squad 7 người tại một công ty thương mại điện tử lớn ở TP.HCM (gọi là Tiki) nhận 40 story points cho Sprint hai tuần. Mỗi sáng, Scrum Master tự hào trình chiếu Burndown: đường đi xuống khá sát đường lý tưởng. Đến ngày thứ 8, mọi người vẫn lạc quan.
Rồi ngày thứ 9–10, đường Burndown bất ngờ đứng yên, và Sprint kết thúc với 12 points không hoàn thành. Khi tôi ngồi cùng họ vẽ lại dữ liệu dưới dạng CFD, vấn đề lộ ra ngay: dải Testing phình to đều đặn từ ngày thứ 4, trong khi dải Done gần như nằm ngang suốt. Team chỉ có một QA, và mọi việc "code xong" cứ chất đống trước cửa khâu test.
Bài học: Burndown không tụt nhiều ở giữa Sprint không phải vì dev chậm, mà vì việc bị nghẽn ở testing — một bottleneck mà chỉ CFD mới hiện ra. Sau Sprint đó, team áp dụng WIP limit cho cột Testing và để dev hỗ trợ test, cycle time giảm gần một nửa.
Ví dụ 2 — Đọc WIP để cứu một team fintech
Tại một startup fintech ở Hà Nội (gọi là MoMoPay) với team 6 developer, tôi được mời vào vì "team làm việc cật lực mà cứ giao hàng trễ". Burndown của họ trông giống răng cưa: lên xuống thất thường vì scope đổi liên tục, nhìn vào chẳng rút ra được gì.
Tôi dựng CFD từ dữ liệu Jira ba Sprint gần nhất. Hình ảnh rất rõ: dải In Progress lúc nào cũng dày khoảng 9–11 items, trong khi cả team chỉ có 6 người. Nghĩa là trung bình mỗi người đang ôm gần 2 việc song song. WIP cao khiến ai cũng bận nhưng ít việc thực sự về đích — đúng như nguyên lý "stop starting, start finishing".
Chúng tôi đặt WIP limit là 6 cho cột In Progress. Trong hai Sprint kế tiếp, throughput (độ dốc dải Done) tăng lên rõ rệt và cycle time trung bình giảm từ 9 ngày xuống 5 ngày, dù team không thêm một người nào.
Bài học: CFD biến cảm giác mơ hồ "team bận mà chậm" thành một con số đo được — độ dày WIP — để bạn coaching bằng dữ liệu thay vì cảm tính.
Ví dụ 3 — Khi Burndown là đủ: một team agency nhỏ
Không phải lúc nào CFD cũng cần thiết. Một agency phần mềm 4 người ở Đà Nẵng làm các dự án ngắn, quy trình chỉ có hai trạng thái thực chất: Đang làm và Xong. Họ thử áp CFD nhưng biểu đồ gần như chỉ có hai dải, chẳng cho thêm thông tin gì so với Burndown.
Tôi khuyên họ quay lại dùng Burndown đơn giản cho mỗi Sprint, và chỉ thỉnh thoảng nhìn throughput. Với một quy trình ít bước và team nhỏ, sự đơn giản của Burndown là một ưu điểm, không phải khuyết điểm.
Bài học: Công cụ phải phù hợp bối cảnh. CFD phát huy sức mạnh khi quy trình có nhiều trạng thái và team đủ lớn để có rủi ro nghẽn cổ chai. Đừng dùng dao mổ trâu để gọt táo.
Hướng dẫn từng bước
Bước 1 — Vẽ và dùng Sprint Burndown. Đầu Sprint, ghi tổng công việc (points hoặc số item). Cuối mỗi ngày, cập nhật phần còn lại. Vẽ thêm đường lý tưởng để so sánh. Quan trọng: đừng dùng nó để phán xét, hãy dùng nó như câu hỏi gợi mở trong Daily Scrum — "Hình này nói gì với chúng ta về khả năng đạt Sprint Goal?"
Bước 2 — Định nghĩa các trạng thái cho CFD. Liệt kê các cột thực sự trong quy trình của team: ví dụ To Do → Analysis → In Progress → Code Review → Testing → Done. CFD chỉ hữu ích khi các trạng thái phản ánh đúng dòng chảy thật, không phải cột trang trí.
Bước 3 — Thu thập dữ liệu mỗi ngày. Cuối ngày, đếm số item đang nằm ở mỗi cột. Hầu hết công cụ như Jira, Azure DevOps đều có sẵn CFD tự động — hãy bật nó lên thay vì làm thủ công.
Bước 4 — Đọc CFD theo ba câu hỏi. (1) Dải nào đang phình to bất thường? Đó là bottleneck. (2) Khoảng cách ngang giữa lúc vào và lúc Done là bao nhiêu? Đó là cycle time. (3) Dải Done có dốc đều không? Độ dốc là throughput.
Bước 5 — Biến quan sát thành hành động. Nếu thấy bottleneck, đưa vào Retrospective. Nếu WIP cao, thử đặt WIP limit. Nếu cycle time dài, hỏi tại sao việc đi qua hệ thống lâu.
Bước 6 — Kết hợp cả hai trong nhịp làm việc. Burndown cho theo dõi trong Sprint, CFD cho cải tiến hệ thống qua nhiều Sprint. Mang CFD ra Retrospective hằng tháng để nhìn xu hướng dài hạn.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi Burndown đi xuống là bằng chứng team khỏe mạnh. Một đường đẹp vẫn có thể che giấu WIP cao và bottleneck ở khâu cuối. Mẹo: luôn hỏi "tại sao đường có hình dạng này?" thay vì chỉ nhìn nó chạm 0 hay chưa.
Lỗi 2 — Dùng Burndown để ép tiến độ. Khi quản lý dùng Burndown để hỏi tội "sao chưa burn down", team sẽ bắt đầu gian lận bằng cách đánh dấu Done sớm. Mẹo: định vị Burndown là công cụ của team, cho team, không phải báo cáo cho sếp.
Lỗi 3 — Vẽ CFD với các trạng thái giả. Nếu mọi item nhảy thẳng từ To Do sang Done mà không qua trạng thái trung gian thực, CFD chỉ là hai dải vô dụng. Mẹo: đảm bảo bảng công việc phản ánh đúng các bước thật.
Lỗi 4 — Bỏ qua tín hiệu dải phình to. Một dải dày lên liên tục là tiếng chuông báo động sớm nhất về nghẽn cổ chai — nhiều SM lại lờ đi. Mẹo: mỗi tuần nhìn CFD và tìm dải "béo nhất đang béo thêm".
Lỗi 5 — Lẫn lộn mục đích hai biểu đồ. Dùng CFD để theo dõi tiến độ một Sprint cụ thể thì quá nặng; dùng Burndown để chẩn đoán hệ thống thì quá yếu. Mẹo: nhớ Burndown trả lời "còn bao nhiêu?", CFD trả lời "chảy thế nào?".
Mẹo nâng cao: Khi coaching, đừng giải thích biểu đồ cho team — hãy chiếu CFD lên và hỏi "Các bạn thấy gì ở đây?". Để chính họ phát hiện ra dải Testing đang phình. Khi team tự nhìn ra vấn đề, họ sở hữu giải pháp.
Bài tập thực hành
- Đọc một Burndown thật. Lấy Burndown của Sprint gần nhất của bạn. Đường có phẳng ở đầu rồi rơi ở cuối không? Nếu có, viết ra giả thuyết: WIP có đang quá cao không? Mang giả thuyết này ra Retrospective tới.
- Dựng CFD đầu tiên. Trong công cụ team đang dùng (Jira/Azure DevOps), bật CFD cho hai Sprint gần nhất. Khoanh tròn dải dày nhất và đặt tên cho bottleneck bạn thấy.
- Đo WIP của chính team. Đếm trung bình bao nhiêu item đang In Progress mỗi ngày, chia cho số thành viên. Nếu mỗi người đang ôm hơn 1,5 việc song song, hãy thử đề xuất một WIP limit và đo lại cycle time sau hai Sprint.
- So sánh hai góc nhìn. Với cùng một Sprint, viết một đoạn ngắn: Burndown nói gì với bạn, và CFD nói thêm điều gì mà Burndown không thấy được? Đây chính là bài tập rèn tư duy PSM II.
Tóm tắt
Sprint Burndown đo phần việc còn lại và trả lời câu hỏi "chúng ta có kịp Sprint Goal không?" — đơn giản, trực quan, hữu ích cho việc tự theo dõi trong Sprint. Nhưng nó có điểm mù: không thấy dòng chảy, che giấu bottleneck, và dễ bị méo bởi WIP cao hay scope thay đổi.
Cumulative Flow Diagram lấp đúng những điểm mù đó. Bằng các dải trạng thái xếp chồng, CFD cho bạn đọc trực tiếp WIP (độ dày dọc), cycle time (khoảng cách ngang) và throughput (độ dốc dải Done) — biến cảm giác mơ hồ thành con số đo được để coaching bằng dữ liệu.
Một Scrum Master PSM II không chọn một bỏ một. Bạn dùng Burndown để giữ nhịp Sprint, dùng CFD để chẩn đoán sức khỏe hệ thống, và luôn nhớ rằng mọi biểu đồ chỉ là điểm khởi đầu của một câu hỏi tốt — chứ không phải câu trả lời cuối cùng. Khi bạn nhìn vào một đường biểu đồ và hỏi "tại sao nó có hình dạng này?", bạn đã bước qua ranh giới từ người báo cáo tiến độ thành người coaching dòng chảy giá trị.