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 đội phát triển ứng dụng giao đồ ăn ở TP.HCM. Giữa Sprint, sếp hỏi: "Liệu Sprint này có kịp ra mắt tính năng đặt món theo nhóm không?" Nếu bạn chỉ trả lời "Em nghĩ là... chắc kịp", bạn đang đoán mò. Nhưng nếu bạn mở ra một biểu đồ, chỉ vào đường dốc và nói "Theo tốc độ hiện tại, chúng ta đang trễ khoảng 1.5 ngày so với kế hoạch, em đề xuất bỏ phần lọc theo món chay ra khỏi phạm vi Sprint này", thì bạn vừa biến cảm tính thành dữ liệu.
Đó chính là sức mạnh của Burn-down và Burn-up charts — hai công cụ trực quan giúp cả đội và stakeholder nhìn thấy tiến độ thật sự, thay vì tin vào những lời hứa lạc quan trong cuộc họp. Trong Scrum, minh bạch (transparency) là một trong ba trụ cột nền tảng, và không có gì minh bạch hơn một biểu đồ mà ai nhìn vào cũng hiểu ngay đội đang đứng ở đâu.
Với vai trò Product Owner, bạn không phải là người vẽ biểu đồ này mỗi ngày (đó thường là việc của Scrum Master hoặc đội tự cập nhật), nhưng bạn bắt buộc phải đọc hiểu chúng. Vì burn-down và burn-up là ngôn ngữ chung khi bạn thương lượng phạm vi, dự báo ngày ra mắt, và quản lý kỳ vọng của stakeholder. Bài này sẽ giúp bạn đọc, hiểu và sử dụng hai loại biểu đồ này một cách tự tin.
Khái niệm cốt lõi
Burn-down chart là gì
Burn-down chart (biểu đồ "đốt cháy giảm dần") là biểu đồ thể hiện lượng công việc còn lại theo thời gian. Cấu trúc rất đơn giản:
- Trục tung (Y-axis): lượng công việc còn lại (remaining work). Đơn vị có thể là Story Points, số giờ ước lượng, hoặc số lượng hạng mục (item) chưa hoàn thành.
- Trục hoành (X-axis): thời gian — thường là từng ngày trong Sprint, hoặc từng Sprint trong một Release.
- Đường dốc xuống (line slope): mỗi khi đội hoàn thành công việc, đường này tụt xuống. Mục tiêu lý tưởng là đường này chạm về 0 đúng vào ngày cuối của Sprint.
Sprint Burn-down
Đây là loại burn-down phổ biến nhất. Trong một Sprint kéo dài 2 tuần (10 ngày làm việc), mỗi cuối ngày đội sẽ cập nhật lại lượng Story Points (hoặc giờ) còn lại của các hạng mục chưa hoàn thành.
Một điểm quan trọng dễ gây hiểu lầm: burn-down chỉ tính công việc xuống khi một hạng mục thật sự xong (đạt Definition of Done). Một User Story đang làm dở 90% vẫn được tính là còn nguyên trên biểu đồ điểm. Lý do là Scrum đề cao giá trị "hoàn thành" — 90% xong nghĩa là chưa giao được gì cho khách hàng. Điều này khiến đường burn-down thường có dạng bậc thang (giật cục) chứ không mượt mà.
Burn-up chart là gì
Burn-up chart (biểu đồ "đốt cháy tăng dần") nhìn vấn đề từ chiều ngược lại. Thay vì đo công việc còn lại, nó đo lượng công việc đã hoàn thành tích lũy theo thời gian. Đường này đi lên chứ không đi xuống.
Điểm mạnh đặc biệt của burn-up là nó có hai đường:
- Đường công việc đã hoàn thành (completed work): đi lên dần.
- Đường tổng phạm vi (total scope line): thể hiện tổng khối lượng công việc cần làm.
Vì sao burn-up quan trọng với Product Owner
Đây là điểm mấu chốt mà nhiều PO bỏ qua. Trong burn-down, khi phạm vi thay đổi (stakeholder thêm yêu cầu mới giữa chừng), đường biểu đồ bị "méo" mà bạn không phân biệt được: đường đi lên là do đội làm chậm, hay do có thêm việc mới? Hai nguyên nhân hoàn toàn khác nhau nhưng nhìn trên burn-down lại giống y hệt.
Burn-up giải quyết triệt để vấn đề này. Khi phạm vi tăng, đường tổng phạm vi nhảy lên — bạn thấy rõ "à, scope vừa phình ra". Khi đội làm chậm, đường hoàn thành đi ngang hoặc thoai thoải. Hai biến số được tách bạch rõ ràng. Đây là lý do burn-up đặc biệt hữu ích cho Release-level — nơi phạm vi thường biến động qua nhiều Sprint, và là nơi PO cần dự báo cho stakeholder.
Tình huống thực tế
Ví dụ 1: Đội "Tiki Mini-App" và cú trượt dốc bị che giấu
Một đội 6 người tại một công ty thương mại điện tử (gọi là đội Tiki Mini-App) bắt đầu Sprint 2 tuần với 40 Story Points. Đường lý tưởng yêu cầu mỗi ngày "đốt" khoảng 4 điểm.
Đến ngày thứ 5, burn-down cho thấy còn 38 điểm — gần như chưa giảm. Nhìn vào, anh Scrum Master tưởng đội lười. Nhưng sự thật là đội đã hoàn thành 70-80% của ba User Story lớn, chỉ là chưa story nào đạt Definition of Done vì còn chờ review code và viết test. Đường burn-down phẳng lì khiến PO hoảng, báo cáo lên trên rằng "Sprint có nguy cơ thất bại".
Đến ngày 6 và 7, ba story đồng loạt xong, đường tụt thẳng từ 38 xuống 12. Cuối cùng Sprint vẫn về đích.
Bài học rút ra: Đừng hoảng loạn vì burn-down phẳng trong nửa đầu Sprint — dạng bậc thang là bình thường. Vấn đề thật sự cần lo là khi story quá lớn, dồn cục về cuối. PO nên phối hợp với đội để chẻ nhỏ User Story (bài 30 nói kỹ về decomposing) sao cho mỗi story xong trong 1-2 ngày, giúp burn-down mượt và đáng tin hơn.
Ví dụ 2: Startup fintech ở Singapore và "scope creep" lộ diện nhờ burn-up
Một startup fintech tại Singapore phát triển ví điện tử, lên kế hoạch ra mắt phiên bản 1.0 trong 5 Sprint với tổng 200 Story Points. Họ dùng burn-up chart ở cấp Release.
Sau Sprint 3, đội đã hoàn thành 120 điểm — đúng tiến độ. Nhưng nếu chỉ nhìn burn-down Release, đội thấy "còn 80 điểm, ổn". Vấn đề là PO liên tục nhận yêu cầu mới từ phòng Compliance: thêm xác thực KYC, thêm giới hạn giao dịch theo quy định. Trên burn-up, đường tổng phạm vi đã âm thầm nhảy từ 200 lên 260 điểm.
Khi đặt hai đường cạnh nhau, PO nhìn ra ngay: với tốc độ ~40 điểm/Sprint, để hoàn thành 260 điểm họ cần thêm 3.5 Sprint nữa, không phải 2 Sprint như kế hoạch. Nhờ phát hiện sớm, PO mở cuộc họp với stakeholder và quyết định: hoãn tính năng KYC nâng cao sang phiên bản 1.1, giữ nguyên ngày ra mắt 1.0.
Bài học rút ra: Burn-up tách bạch "đội làm chậm" và "scope phình to". Nếu họ chỉ dùng burn-down, có thể đến sát ngày ra mắt mới phát hiện trễ. Với PO, burn-up chính là vũ khí để kiểm soát scope creep một cách định lượng và thương lượng có cơ sở.
Ví dụ 3: Đội outsourcing tại Đà Nẵng và đường dự báo (forecast)
Một công ty phần mềm outsourcing ở Đà Nẵng làm dự án cho khách hàng Nhật. Khách hàng liên tục hỏi: "Bao giờ xong?" PO vẽ burn-up chart và kéo dài đường xu hướng (trend line) dựa trên tốc độ trung bình 4 Sprint gần nhất (velocity trung bình 35 điểm/Sprint).
Đường xu hướng giao với đường tổng phạm vi tại Sprint thứ 9. PO chuyển thành ngày dương lịch cụ thể và báo: "Dự kiến hoàn thành khoảng tuần thứ 18, với giả định phạm vi không đổi và đội ổn định." Cách trình bày này thuyết phục khách Nhật hơn hẳn lời hứa chung chung, và quan trọng là nó có kèm giả định rõ ràng để bảo vệ đội khi điều kiện thay đổi.
Bài học rút ra: Burn-up không chỉ kể chuyện quá khứ mà còn dự báo tương lai. Nhưng dự báo phải đi kèm giả định và biên độ (ví dụ "tuần 17 đến 19"), không bao giờ là một con số tuyệt đối cứng nhắc.
Hướng dẫn từng bước
Dưới đây là cách bạn — với vai trò PO — đọc và sử dụng hai loại biểu đồ này trong thực tế.
Bước 1 — Xác định đơn vị đo. Quyết định cùng đội xem dùng Story Points hay số hạng mục. Ở cấp Sprint, nhiều đội dùng giờ ước lượng; ở cấp Release, hầu như luôn dùng Story Points vì nó ổn định hơn.
Bước 2 — Vẽ đường lý tưởng trước. Lấy tổng công việc đầu Sprint chia đều cho số ngày làm việc. Đây là tham chiếu để so sánh. Không có đường lý tưởng thì biểu đồ thực tế chẳng nói lên điều gì.
Bước 3 — Cập nhật mỗi ngày. Sau Daily Scrum, đội cập nhật lượng công việc còn lại (cho burn-down) hoặc đã hoàn thành (cho burn-up). Chỉ tính những gì đạt Definition of Done.
Bước 4 — Đọc khoảng cách giữa đường thực tế và đường tham chiếu. Trên burn-down: đường thực tế nằm trên đường lý tưởng = chậm. Trên burn-up: đường hoàn thành còn cách xa đường tổng phạm vi và dốc thoai thoải = cần hành động.
Bước 5 — Với burn-up, luôn theo dõi đường tổng phạm vi. Mỗi khi nó nhảy lên, hãy hỏi: "Việc gì vừa được thêm vào, ai yêu cầu, có thật sự cần trong Release này không?" Đây là khoảnh khắc PO thực thi quyền quản trị backlog.
Bước 6 — Dự báo có trách nhiệm. Kéo dài đường xu hướng dựa trên velocity gần nhất, đổi ra ngày cụ thể, và luôn kèm giả định. Trình bày dạng khoảng thời gian thay vì một mốc cứng.
Bước 7 — Dùng biểu đồ trong giao tiếp, không để nó nằm im. Mang burn-down vào Sprint Review để minh họa tiến độ, mang burn-up vào họp stakeholder để thương lượng phạm vi. Biểu đồ chỉ có giá trị khi nó dẫn dắt một quyết định.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi burn-down như công cụ giám sát năng suất cá nhân. Một số quản lý dùng đường burn-down phẳng để trách móc đội "làm chậm". Đây là cách nhanh nhất phá hỏng tinh thần Scrum. Burn-down là công cụ để đội tự điều chỉnh, không phải roi vọt của sếp. PO nên bảo vệ đội khỏi cách diễn giải độc hại này.
Lỗi 2 — Nhầm tiến độ "đang làm" với "đã xong". Tính điểm cho story làm dở khiến biểu đồ đẹp giả tạo, rồi cuối Sprint vỡ trận. Kỷ luật: chỉ đốt điểm khi đạt Definition of Done.
Lỗi 3 — Dùng burn-down ở cấp Release mà bỏ qua scope creep. Như ví dụ fintech Singapore, ở cấp Release phạm vi luôn biến động. Hãy ưu tiên burn-up vì nó tách bạch được hai biến số.
Lỗi 4 — Vẽ biểu đồ rồi để đó. Biểu đồ không tự ra quyết định. Nếu thấy chậm mà không ai làm gì, biểu đồ chỉ là trang trí.
Mẹo: Để burn-down mượt và đáng tin, hãy chẻ User Story đủ nhỏ (lý tưởng là mỗi story 1-3 điểm). Story càng nhỏ, đường biểu đồ càng phản ánh tiến độ thật.
Mẹo: Đừng tô vẽ biểu đồ quá đẹp để báo cáo cấp trên. Một burn-down "xấu" nhưng trung thực còn hữu ích gấp nhiều lần một biểu đồ đẹp nhưng dối. Minh bạch là trụ cột của Scrum.
Mẹo: Hầu hết công cụ như Jira, Azure DevOps đều tự sinh burn-down. Nhưng burn-up đôi khi phải tự dựng. Đừng ngại bắt đầu bằng một bảng tính Google Sheets đơn giản — quan trọng là dữ liệu trung thực, không phải công cụ hào nhoáng.
Bài tập thực hành
- Đọc biểu đồ: Sprint của bạn bắt đầu với 50 Story Points trong 10 ngày. Đến cuối ngày 6, đường burn-down còn ở mức 40 điểm. Hãy tính: đường lý tưởng tại ngày 6 lẽ ra ở mức bao nhiêu? Đội đang nhanh hay chậm, và chênh lệch bao nhiêu điểm?
- Tự vẽ burn-up: Lấy một dự án giả định 5 Sprint, tổng phạm vi 100 điểm. Giả sử velocity mỗi Sprint lần lượt là 18, 22, 20, và đến đầu Sprint 4 stakeholder thêm 30 điểm. Vẽ đường hoàn thành và đường tổng phạm vi trên giấy hoặc Google Sheets. Dự báo: với velocity ~20 điểm/Sprint, dự án thực tế cần bao nhiêu Sprint?
- Tình huống PO: Burn-up Release của bạn cho thấy đường tổng phạm vi đã nhảy từ 200 lên 250 điểm trong khi đội vẫn giữ velocity ổn định. Hãy soạn 3-4 câu bạn sẽ nói với stakeholder để thương lượng: hoặc dời ngày ra mắt, hoặc cắt phạm vi. Viết ra như thể bạn đang đứng trong cuộc họp thật.
- Phản biện: Tìm một lập luận thuyết phục để giải thích cho một quản lý đang muốn dùng burn-down để đánh giá từng cá nhân vì sao điều đó sai và phản tác dụng.
Tóm tắt
Burn-down và burn-up là hai mặt của cùng một câu chuyện về tiến độ. Burn-down đo công việc còn lại, đường dốc xuống về 0, đơn giản và phù hợp ở cấp Sprint. Burn-up đo công việc đã hoàn thành, đi lên gặp đường tổng phạm vi, và đặc biệt mạnh ở cấp Release vì nó tách bạch được "đội làm chậm" với "phạm vi phình to" — đúng vấn đề mà PO cần kiểm soát.
Là Product Owner, bạn không cần là người vẽ biểu đồ, nhưng phải đọc thông thạo cả hai. Hãy dùng burn-down để cùng đội theo dõi nhịp Sprint, dùng burn-up để dự báo ngày ra mắt và thương lượng phạm vi với stakeholder bằng dữ liệu thay vì cảm tính. Ba nguyên tắc cốt lõi cần khắc cốt ghi tâm: chỉ đốt điểm khi thật sự xong (Definition of Done), luôn theo dõi đường tổng phạm vi để chặn scope creep, và mọi dự báo phải đi kèm giả định rõ ràng. Khi làm được điều đó, bạn biến hai đường kẻ đơn giản thành công cụ quản trị sản phẩm mạnh mẽ nhất trong tay mình.