Mở đầu — vì sao bài này quan trọng
Nếu bạn từng bước vào một phòng họp của team Scrum, rất có thể bạn đã thấy một tấm bảng treo trên tường với một đường cong đi xuống dần — đó là Burndown chart. Đây có lẽ là hình ảnh "biểu tượng" nhất gắn liền với Scrum trong tâm trí nhiều người. Và chính vì quá quen thuộc, nó cũng trở thành một trong những điểm gây ngộ nhận nhiều nhất khi bạn ôn thi PSM I.
Điều bạn cần khắc cốt ghi tâm ngay từ đầu bài: Burndown chart và Burnup chart KHÔNG phải là thành phần bắt buộc của Scrum. Scrum Guide 2020 hoàn toàn không nhắc đến hai loại biểu đồ này. Chúng là những công cụ trực quan hóa tiến độ (progress visualization) — hữu ích, phổ biến, nhưng mang tính tùy chọn (optional). Trong đề thi PSM I, nếu một câu hỏi ngụ ý rằng "team phải duy trì burndown chart" hay "Scrum Master bắt buộc cập nhật burndown mỗi ngày", thì đó gần như chắc chắn là một bẫy.
Vậy tại sao vẫn dành nguyên một bài cho chủ đề "không bắt buộc" này? Bởi vì với tư cách Scrum Master tương lai, bạn cần hiểu rõ ba điều: (1) hai loại biểu đồ này đo cái gì và đọc chúng ra sao, (2) chúng phục vụ trụ cột nào của empiricism — tức tính minh bạch (transparency) để phục vụ inspection và adaptation, và (3) ranh giới giữa "công cụ hỗ trợ" và "mandate của Scrum" — vì đề thi rất thích kiểm tra đúng ranh giới này. Hiểu đúng, bạn vừa ghi điểm trong phòng thi, vừa dùng được công cụ một cách thông minh ngoài đời thực.
Khái niệm cốt lõi
Burndown chart — đếm ngược phần việc còn lại
Burndown chart trả lời câu hỏi: "Chúng ta còn lại bao nhiêu việc, và với tốc độ hiện tại liệu có kịp không?"
- Trục tung (Y-axis): lượng công việc còn lại (remaining work). Đơn vị thường là story points hoặc số giờ (hours), đôi khi là số lượng item.
- Trục hoành (X-axis): thời gian — thường là từng ngày trong Sprint.
- Đường lý tưởng (ideal line): một đường thẳng đi từ tổng lượng việc ở ngày đầu xuống tới 0 ở ngày cuối Sprint. Đây là "đường tham chiếu" giả định team hoàn thành công việc đều đặn mỗi ngày.
- Đường thực tế (actual line): đường gồ ghề phản ánh lượng việc còn lại thực sự sau mỗi ngày.
Có hai biến thể phổ biến:
- Sprint Burndown: đo phần việc còn lại của Sprint Backlog trong một Sprint. Đây là loại bạn hay thấy nhất.
- Product/Release Burndown: đo phần việc còn lại để đạt một mục tiêu lớn hơn (ví dụ một release), tính theo nhiều Sprint.
Burnup chart — vẽ phần việc đã hoàn thành
Burnup chart giải quyết một nhược điểm lớn của burndown: nó tách bạch giữa "tiến độ hoàn thành" và "thay đổi phạm vi".
- Trục tung: lượng công việc đã hoàn thành (completed work), tích lũy tăng dần.
- Trục hoành: thời gian.
- Đường tiến độ (progress line): đi từ 0 lên, thể hiện công việc đã xong cộng dồn.
- Đường phạm vi (scope line): một đường nằm ngang ở phía trên thể hiện tổng khối lượng công việc. Điểm mấu chốt: khi phạm vi thay đổi (thêm/bớt việc), đường scope này dịch lên hoặc xuống — và bạn nhìn thấy được sự thay đổi đó.
Vì sao có cả hai? Sự khác biệt then chốt
Hãy tưởng tượng đường burndown của bạn đang đi ngang (không giảm) suốt ba ngày. Có hai khả năng hoàn toàn khác nhau: (a) team không làm xong việc gì, hoặc (b) team làm xong việc nhưng đồng thời có việc mới được thêm vào, nên phần còn lại không đổi. Burndown không phân biệt được hai trường hợp này — đường đi ngang trông y hệt nhau. Đây gọi là "scope hiding".
Burnup thì hiển thị hai biến độc lập: đường progress vẫn leo lên cho thấy team có làm việc, đồng thời đường scope nhảy lên cho thấy phạm vi đã phình. Nhờ vậy, burnup minh bạch hơn về scope creep (phạm vi phình to). Đổi lại, burndown đơn giản hơn, dễ đọc "còn lại bao nhiêu" trong nháy mắt.
Kết nối với empiricism
Cả hai biểu đồ đều là công cụ tạo transparency — trụ cột đầu tiên trong ba trụ cột của empiricism. Khi tiến độ minh bạch, team có thể inspect (thanh tra) nó tại Daily Scrum hoặc Sprint Review, rồi adapt (thích nghi) — điều chỉnh kế hoạch cho phần còn lại của Sprint. Nhưng hãy nhớ: biểu đồ chỉ là một cách tạo transparency, không phải yêu cầu. Một sticky note dán tường, một bảng task đơn giản, hay thậm chí một cuộc trao đổi thẳng thắn cũng có thể tạo transparency tương đương.
Cảnh báo "by the book" cho PSM I
Ghi nhớ những điểm sau, vì đề thi rất hay xoáy vào:
- Scrum Guide không yêu cầu burndown/burnup.
- Scrum Master không có nghĩa vụ "sở hữu" hay "cập nhật" burndown. Sprint Backlog (gồm cả tiến độ) thuộc về Developers.
- Tiến độ tốt hay xấu không tự nó quyết định Sprint thành công; Sprint Goal mới là thước đo giá trị, không phải việc đường có chạm 0 hay không.
- Burndown đi xuống đúng đường lý tưởng không đảm bảo Increment "Done" theo Definition of Done.
Tình huống thực tế
Ví dụ 1 — Tiki và đường burndown "phẳng lì" đầu Sprint
Một team Developers tại một công ty thương mại điện tử lớn ở TP.HCM (gọi là team "Checkout") bắt đầu Sprint hai tuần (10 ngày làm việc) với Sprint Backlog ước tính 40 story points. Sprint Master mới vào nghề treo burndown chart lên bảng và mỗi sáng đều lo lắng nhìn nó.
Suốt bốn ngày đầu, đường thực tế gần như nằm ngang ở mức 38–40 points, cao hẳn so với đường lý tưởng. Sprint Master bắt đầu hoang mang, định báo cáo với quản lý rằng "team đang trễ tiến độ nghiêm trọng".
Nhưng tại Daily Scrum ngày thứ 5, các Developers giải thích: họ đang dồn sức xây một module thanh toán nền tảng mà nhiều Product Backlog Item khác phụ thuộc vào. Module này gần xong nhưng chưa "Done", nên chưa có point nào được trừ. Đúng như dự đoán, từ ngày 6 đến ngày 9, đường burndown lao dốc thẳng đứng khi hàng loạt item hoàn tất liên tiếp, và Sprint kết thúc với Sprint Goal đạt được.
Bài học: Burndown chart đo kết quả hoàn thành, không đo nỗ lực đang diễn ra. Một đường phẳng đầu Sprith có thể hoàn toàn bình thường khi team làm việc trên nền tảng dùng chung. Đừng quản trị theo hình dạng đường biểu đồ; hãy dùng Daily Scrum để hiểu câu chuyện đằng sau con số. Và quan trọng cho phòng thi: Sprint thành công vì đạt Sprint Goal, không phải vì đường khớp lý tưởng.
Ví dụ 2 — Startup fintech ở Singapore và cái bẫy "scope hiding" của burndown
Một startup fintech tại Singapore có team "Lending" dùng Sprint Burndown suốt sáu Sprint. Quản lý sản phẩm liên tục thấy đường burndown "trông ổn" — luôn giảm về gần 0 cuối mỗi Sprint — nên yên tâm. Nhưng thực tế, Product Goal cứ lùi xa mãi, release bị trễ ba tháng.
Khi mời một Agile Coach vào rà soát, vấn đề lộ ra: trong mỗi Sprint, Product Owner âm thầm thêm các item "nhỏ khẩn cấp" vào giữa chừng. Vì burndown chỉ vẽ "phần còn lại", việc team hoàn thành item cũ và item mới được thêm vào cứ bù trừ cho nhau, khiến đường vẫn giảm đẹp đẽ. Phạm vi thực sự phình to mà không ai nhìn thấy.
Coach chuyển team sang Burnup chart ở cấp release. Ngay Sprint sau, đường scope (phạm vi) nhảy vọt lên hai lần một cách lộ liễu, còn đường progress leo chậm hơn nhiều. Lần đầu tiên, cả Product Owner và stakeholder nhìn thấy bằng mắt rằng họ đang liên tục bơm thêm việc. Cuộc trò chuyện chuyển từ "tại sao team chậm" sang "chúng ta có thật sự cần thêm những item này không".
Bài học: Burndown ẩn giấu thay đổi phạm vi; burnup phơi bày nó. Khi bạn nghi ngờ có scope creep hoặc cần minh bạch về phạm vi với stakeholder, burnup là lựa chọn vượt trội. Đây cũng là một ý cốt lõi của bài: chọn công cụ theo câu hỏi bạn cần trả lời, đừng dùng theo quán tính.
Ví dụ 3 — Câu hỏi bẫy kiểu PSM I tại một buổi ôn thi ở Hà Nội
Trong một lớp ôn PSM I ở Hà Nội, giảng viên đưa ra tình huống: "Cuối Sprint, đường burndown đã chạm 0 từ ngày thứ 8. Điều này có nghĩa là Increment chắc chắn 'Done' và Sprint đã thành công, đúng không?"
Phần lớn học viên gật đầu. Nhưng câu trả lời "by the book" là không. Đường chạm 0 chỉ nói rằng các item trong Sprint Backlog được team đánh dấu đã xử lý theo cách họ tính toán — nó không tự động đảm bảo từng phần đạt Definition of Done, cũng không đảm bảo Sprint Goal (giá trị thực sự) đã đạt. Một item có thể bị đánh dấu "xong" trong khi vẫn còn nợ kỹ thuật, chưa kiểm thử đầy đủ, hay không thực sự đáp ứng DoD.
Bài học: Trong đề thi, đừng để hình ảnh trực quan của biểu đồ thay thế cho định nghĩa nghiêm ngặt của Scrum. "Done" được định nghĩa bởi Definition of Done, "thành công" được đo bằng Sprint Goal và giá trị giao cho khách hàng — không phải bởi việc một đường có chạm trục hoành hay không.
Hướng dẫn từng bước
Dưới đây là cách dựng và sử dụng cả hai biểu đồ một cách thực dụng.
Dựng Sprint Burndown:
- Xác định đơn vị đo: story points (phổ biến, ổn định) hoặc remaining hours (chi tiết hơn nhưng dao động mạnh).
- Ghi tổng lượng việc đầu Sprint lên trục tung tại ngày 0.
- Vẽ đường lý tưởng: nối điểm tổng việc ở ngày 0 tới điểm 0 ở ngày cuối Sprint.
- Cuối mỗi ngày, để Developers cập nhật lượng việc còn lại (không phải lượng đã làm). Chấm điểm và nối đường thực tế.
- Tại Daily Scrum, dùng đường này như một dữ liệu hỗ trợ cho cuộc trao đổi về kế hoạch tiến tới Sprint Goal — không để nó thay thế cuộc trao đổi.
- Trục tung: lượng việc đã hoàn thành (cộng dồn). Trục hoành: thời gian.
- Vẽ đường scope nằm ngang ở mức tổng phạm vi hiện tại.
- Mỗi khi phạm vi thay đổi, dịch đường scope lên/xuống ngay tại thời điểm đó — đây chính là giá trị minh bạch của burnup.
- Cuối mỗi mốc, cộng dồn việc đã "Done" và nối đường progress.
- Khoảng cách giữa progress và scope chính là phần việc còn lại; khoảng cách đó co lại do progress leo lên hoặc scope hạ xuống.
- Cần biết nhanh "còn lại bao nhiêu trong Sprint này" → Burndown.
- Cần minh bạch về thay đổi phạm vi, làm việc với stakeholder ở cấp release → Burnup.
- Cần dự báo (forecast) thô về ngày hoàn thành → cả hai đều có thể ngoại suy xu hướng, nhưng hãy nhớ đây chỉ là forecast, không phải cam kết.
Lỗi thường gặp & mẹo
- Coi burndown/burnup là bắt buộc. Sai. Chúng tùy chọn và không nằm trong Scrum Guide. Mẹo thi: thấy chữ "must/required" gắn với burndown là cảnh giác.
- Gán cho Scrum Master nghĩa vụ cập nhật biểu đồ. Sprint Backlog và tiến độ thuộc về Developers. Scrum Master phục vụ tính hiệu quả, không phải người "thư ký biểu đồ".
- Quản trị theo hình dạng đường. Đường đi ngang đầu Sprint chưa chắc xấu (xem ví dụ Tiki). Hãy đọc câu chuyện qua Daily Scrum, đừng phản ứng máy móc với hình vẽ.
- Dùng burndown khi phạm vi hay thay đổi. Nó che giấu scope creep. Khi nghi ngờ, chuyển sang burnup.
- Nhầm "chạm 0" với "Done" hay "thành công". Done do Definition of Done quyết định; thành công do Sprint Goal và giá trị quyết định.
- Đo bằng remaining hours rồi hoảng vì đường gồ ghề. Giờ ước tính dao động tự nhiên trong ngày; điều đó bình thường. Nhiều team thích points vì ổn định hơn.
- Mẹo ghi nhớ: Burndown = đếm xuống phần còn lại. Burnup = vẽ lên phần đã xong + thấy được scope. "Up cho thấy scope, down giấu scope."
Bài tập thực hành
- Phân biệt mandate: Viết ra một câu trả lời ngắn cho câu hỏi: "Trong Scrum Guide 2020, burndown chart có bắt buộc không, và ai chịu trách nhiệm về tiến độ trong Sprint Backlog?"
- Đọc đường phẳng: Team của bạn có burndown phẳng trong 3 ngày đầu một Sprint 10 ngày. Liệt kê ít nhất hai cách giải thích hợp lý mà không kết luận ngay là team đang trễ.
- Chọn công cụ: Stakeholder phàn nàn "team làm hoài không xong release". Bạn nghi có scope creep. Giải thích vì sao bạn chọn burnup thay vì burndown, và mô tả bạn sẽ chỉ cho họ thấy điều gì trên biểu đồ.
- Bắt bẫy thi: Phản biện phát biểu sau theo đúng tinh thần Scrum: "Đường burndown chạm 0 sớm nghĩa là Sprint chắc chắn thành công." Dùng khái niệm Definition of Done và Sprint Goal trong câu trả lời.
- Tự dựng: Lấy một Sprint giả định 40 points, 10 ngày. Vẽ tay đường lý tưởng. Sau đó giả lập một thay đổi phạm vi ở ngày 5 (thêm 10 points) và vẽ điều đó trên cả hai loại biểu đồ. Quan sát xem burndown che giấu thay đổi đó như thế nào còn burnup thì hiển thị ra sao.
Tóm tắt
Burndown và Burnup là hai công cụ trực quan hóa tiến độ — phổ biến, hữu ích, nhưng hoàn toàn tùy chọn và không nằm trong Scrum Guide 2020. Burndown đếm ngược phần việc còn lại (trục tung là remaining work, trục hoành là thời gian, đường giảm dần về 0), đơn giản và dễ đọc nhưng che giấu thay đổi phạm vi. Burnup vẽ phần việc đã hoàn thành leo lên cùng một đường scope riêng biệt, nhờ đó phơi bày scope creep và minh bạch hơn về phạm vi.
Cả hai phục vụ trụ cột transparency của empiricism, giúp team inspect và adapt — nhưng chúng chỉ là một cách tạo minh bạch, không phải yêu cầu. Cho PSM I, hãy khắc ghi bốn ranh giới: biểu đồ không bắt buộc; tiến độ trong Sprint Backlog thuộc về Developers (không phải nghĩa vụ của Scrum Master); "chạm 0" không đồng nghĩa với "Done"; và thành công của Sprint được đo bằng Sprint Goal cùng giá trị giao đi, chứ không bằng hình dạng của một đường cong. Hiểu đúng điều này, bạn vừa tránh được bẫy trong phòng thi, vừa dùng công cụ một cách thông minh khi đứng lớp ngoài đời thực.