Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Scrum Master của một team 6 người trong một sprint kéo dài 2 tuần. Đến ngày thứ 7, có người hỏi bạn: "Sprint này liệu có kịp không?" Nếu câu trả lời của bạn chỉ là cảm giác — "chắc là ổn" hoặc "hơi lo lo" — thì bạn đang lái xe mà không nhìn đồng hồ tốc độ. Trong quản lý dự án Agile, burn-down chart và các công cụ sprint tracking chính là bảng đồng hồ đó: chúng biến cảm giác mơ hồ thành dữ liệu trực quan, giúp bạn phát hiện vấn đề trước khi nó trở thành khủng hoảng.
Ở các bài trước bạn đã học về Scrum, về story points và velocity (Bài 40). Bài này đi sâu vào một câu hỏi rất cụ thể và thực dụng: trong lúc sprint đang chạy, làm sao để biết team đang đi đúng hướng hay đã lệch nhịp? Burn-down chart trả lời chính xác câu hỏi này. Nó không chỉ là một biểu đồ đẹp để dán lên tường hay chèn vào báo cáo — nó là công cụ chẩn đoán sức khỏe của sprint, là chất liệu để bạn ra quyết định kịp thời: cắt scope, xin thêm nguồn lực, hay cảnh báo Product Owner sớm.
Với người làm PM tại Việt Nam — nơi nhiều team vừa chuyển từ Waterfall sang Agile, nơi khách hàng hoặc sếp vẫn quen hỏi "bao giờ xong?" — khả năng đọc và diễn giải burn-down một cách sắc bén là một kỹ năng cực kỳ đắt giá. Nó giúp bạn giao tiếp bằng dữ liệu thay vì bằng lời hứa suông.
Khái niệm cốt lõi
Burn-down chart là gì?
Burn-down chart là biểu đồ thể hiện lượng công việc còn lại giảm dần theo thời gian trong một sprint. "Burn down" nghĩa là "đốt cháy dần" — mỗi ngày team hoàn thành công việc, lượng việc còn lại "cháy" bớt đi cho đến khi về 0 vào cuối sprint.
Cấu trúc của biểu đồ 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 hoặc giờ (hours). Ở đầu sprint, giá trị này bằng tổng công việc đã cam kết (sprint commitment).
- Trục hoành (X-axis): Thời gian (time), tính theo ngày làm việc của sprint. Ví dụ sprint 2 tuần thường có 10 ngày làm việc.
- Đường mục tiêu (target line / ideal line): một đường thẳng đi từ tổng công việc ban đầu (góc trên bên trái) tuột thẳng xuống 0 vào cuối sprint (góc dưới bên phải). Đây là nhịp độ lý tưởng — nếu mỗi ngày team đốt đều lượng việc như nhau thì đường thực tế sẽ trùng với đường này.
- Đường thực tế (actual line): đường nối các điểm dữ liệu thật mỗi ngày, phản ánh lượng việc thực sự còn lại. Đây là đường quan trọng nhất — vị trí của nó so với đường mục tiêu cho bạn biết tình hình.
Đọc đường thực tế so với đường mục tiêu
Đây là phần cốt lõi cần nắm thật vững, vì mọi giá trị của burn-down nằm ở đây:
- Đường thực tế nằm TRÊN đường mục tiêu: team đang chậm hơn kế hoạch. Việc còn lại nhiều hơn mức đáng ra phải có ở thời điểm đó. Cảnh báo nguy cơ không hoàn thành sprint.
- Đường thực tế nằm DƯỚI đường mục tiêu: team đang nhanh hơn kế hoạch. Có thể sẽ xong sớm, hoặc dấu hiệu team đã ước lượng quá cao (over-estimate).
- Đường thực tế đi ngang (flat line): không có việc nào được hoàn thành trong khoảng đó — dấu hiệu team bị kẹt (blocked): chờ phê duyệt, chờ API bên thứ ba, thiếu thông tin, hoặc một task quá lớn chưa "Done" được.
- Đường thực tế đi LÊN: scope tăng — có story mới được thêm vào giữa sprint, hoặc một task tưởng xong hóa ra bị mở lại. Đây là dấu hiệu của scope creep trong sprint.
Points hay Hours?
Một câu hỏi thực tế nhiều team tranh cãi. Burn-down theo story points phản ánh giá trị hoàn thành (một story chỉ được "đốt" khi thật sự Done theo Definition of Done). Nó cho bức tranh trung thực về tiến độ giao được giá trị, nhưng có nhược điểm là biểu đồ trông "giật cục" — cả sprint không đổi rồi rơi mạnh khi một story lớn xong.
Burn-down theo giờ (dựa trên task hours còn lại) mượt hơn, cập nhật hằng ngày khi thành viên log giờ, hữu ích cho team muốn thấy nhịp độ mịn. Nhược điểm: giờ log không đồng nghĩa với giá trị giao được — bạn có thể "cày" nhiều giờ mà story vẫn chưa Done.
Lời khuyên của tôi: dùng story points để giao tiếp với Product Owner và stakeholder (họ quan tâm giá trị), dùng giờ trong nội bộ team nếu muốn theo dõi nhịp mịn hằng ngày. Không cần dùng cả hai nếu team còn non — chọn một và làm cho tốt.
Burn-down vs Burn-up
Bạn cũng sẽ gặp burn-up chart — biểu đồ "đi lên", thể hiện lượng công việc đã hoàn thành tăng dần cùng một đường thể hiện tổng scope. Ưu điểm lớn của burn-up là nó tách bạch được "làm được bao nhiêu" và "scope thay đổi thế nào" — khi scope tăng, đường tổng scope đi lên rõ ràng, không lẫn với tiến độ. Trong sprint tracking hằng ngày, burn-down phổ biến hơn vì gọn; burn-up thường dùng ở cấp release để theo dõi scope creep. Bài này tập trung vào burn-down cấp sprint.
Tình huống thực tế
Ví dụ 1 — Team "phẳng rồi rơi" tại một startup fintech ở TP.HCM
Team Payments của một startup fintech tại Quận 1 chạy sprint 10 ngày, cam kết 40 story points. Scrum Master là chị Ngân theo dõi burn-down theo points. Đến ngày thứ 6, đường thực tế vẫn nằm ở mức 38 điểm — gần như phẳng, trong khi đường mục tiêu đã tụt xuống khoảng 16.
Nhìn qua thì đáng báo động: 6 ngày mới đốt được 2 điểm. Nhưng chị Ngân không hoảng. Chị biết team đang làm chung một story lớn 21 điểm (tích hợp cổng thanh toán VNPay) — story này cần xong cả cụm mới "Done" được, nên trong lúc làm dở, điểm chưa "cháy". Chị kiểm tra task-level burn-down (theo giờ) và thấy đường giờ vẫn tụt đều, chứng tỏ team vẫn tiến. Đúng như dự đoán, ngày 7 story VNPay Done, đường points rơi mạnh từ 38 xuống 17.
Bài học: Burn-down theo points sẽ "phẳng rồi rơi" nếu sprint chứa story lớn. Đừng vội kết luận team lười khi thấy đường phẳng — hãy chẻ nhỏ story và, nếu cần, soi thêm burn-down theo giờ để thấy nhịp thực. Bài học sâu hơn: story quá lớn làm burn-down mất khả năng cảnh báo sớm — nên chia story dưới 8 điểm để biểu đồ "biết nói".
Ví dụ 2 — Đường đi lên tại một team outsourcing của FPT Software
Một team 8 người tại FPT Software làm dự án cho khách hàng Nhật, sprint 2 tuần, cam kết 55 points. Đầu sprint mọi thứ ổn, đường thực tế bám sát đường mục tiêu đến ngày 5. Nhưng sang ngày 6, đường thực tế đi lên từ 30 lên 38 điểm.
Nguyên nhân: khách hàng Nhật gửi thêm 3 yêu cầu "nhỏ" giữa sprint, và Product Owner phía Việt Nam — vì ngại từ chối khách — đã âm thầm thêm chúng vào sprint đang chạy. Team Lead anh Dũng phát hiện đúng nhờ nhìn đường burn-down bật lên. Trong daily stand-up, anh chỉ vào biểu đồ và nói: "Scope đã tăng 8 điểm giữa sprint. Với velocity hiện tại, ta sẽ thiếu khoảng 1.5 ngày. Cần quyết định: bỏ story nào ra, hay dời 8 điểm này sang sprint sau?"
Nhờ có bằng chứng trực quan, cuộc trao đổi với khách trở nên dễ dàng — không phải "team làm chậm" mà là "scope đã đổi". Cuối cùng 8 điểm mới được đẩy sang sprint kế tiếp.
Bài học: Đường burn-down đi lên là còi báo động của mid-sprint scope creep. Burn-down không chỉ đo tốc độ, nó còn phơi bày sự thay đổi cam kết. Và nó là công cụ giao tiếp cực mạnh: một biểu đồ bật lên thuyết phục hơn mười câu giải thích.
Ví dụ 3 — Đường "về đích quá sớm" tại một team sản phẩm ở Đà Nẵng
Team của một công ty SaaS ở Đà Nẵng liên tục hoàn thành sprint sớm 2-3 ngày, đường thực tế luôn nằm sâu dưới đường mục tiêu. Thoạt nhìn ai cũng khen team giỏi. Nhưng Scrum Master chị Linh nhận ra vấn đề: team đang ước lượng quá cao (over-commit về estimate, under-commit về khối lượng) — nhận quá ít việc so với năng lực thật.
Chị theo dõi 4 sprint liên tiếp, thấy trung bình team hoàn thành 100% cam kết vào ngày 8/10 và 2 ngày cuối gần như rảnh. Chị điều chỉnh: tăng dần commitment mỗi sprint thêm khoảng 15% cho tới khi burn-down bám sát đường mục tiêu và về 0 đúng ngày cuối. Velocity thật của team tăng từ 32 lên 45 điểm/sprint mà không hề bị quá tải.
Bài học: Đường về đích quá sớm không phải lúc nào cũng là tin vui — nó có thể nghĩa là team đang lãng phí năng lực hoặc thổi phồng estimate. Burn-down đọc qua nhiều sprint (trend) giúp bạn hiệu chỉnh commitment để dùng hết năng lực đội mà không burnout.
Hướng dẫn từng bước
Đây là quy trình dựng và dùng burn-down chart trong một sprint thực tế:
Bước 1 — Xác định điểm khởi đầu. Sau buổi Sprint Planning, chốt tổng công việc cam kết. Ví dụ 40 story points hoặc 320 giờ task. Đây là giá trị đầu của trục Y ở ngày 0.
Bước 2 — Vẽ đường mục tiêu. Nối điểm (ngày 0, tổng công việc) tới điểm (ngày cuối, 0) bằng một đường thẳng. Với 40 điểm trong 10 ngày, mỗi ngày lý tưởng đốt 4 điểm. Đây chỉ là tham chiếu, đừng kỳ vọng đường thực tế trùng khít.
Bước 3 — Cập nhật dữ liệu mỗi ngày. Cuối mỗi ngày (hoặc ngay trước daily stand-up), ghi lại lượng công việc còn lại — không phải lượng đã làm. Nếu dùng points: cộng điểm của các story CHƯA Done. Nếu dùng giờ: cộng số giờ ước tính còn lại của các task chưa xong. Lưu ý: chỉ trừ điểm khi story đạt Definition of Done, không trừ nửa vời.
Bước 4 — Chấm điểm lên biểu đồ và nối đường thực tế. Mỗi ngày một điểm; nối lại thành đường thực tế.
Bước 5 — Diễn giải trong daily stand-up. Đặt câu hỏi mỗi ngày: Đường thực tế đang trên, dưới hay bám đường mục tiêu? Có đoạn phẳng không (blocker)? Có đoạn đi lên không (scope tăng)? Với đà này, ngày cuối đường sẽ ở đâu?
Bước 6 — Ra quyết định sớm. Nếu đến giữa sprint đường thực tế nằm cao hơn mục tiêu đáng kể, hành động ngay: gỡ blocker, tái phân bổ người, hoặc thương lượng cắt story ưu tiên thấp với Product Owner. Đừng đợi đến ngày cuối mới báo.
Bước 7 — Dùng công cụ tự động khi có thể. Jira, Azure DevOps, hay ClickUp đều tự sinh burn-down từ trạng thái task. Nhưng nếu mới bắt đầu, một bảng tính Google Sheets vẽ tay lại giúp team hiểu bản chất tốt hơn nhiều so với biểu đồ tự động mà không ai đọc.
Lỗi thường gặp & mẹo
Lỗi 1 — Log "công việc đã làm" thay vì "công việc còn lại". Burn-down đo remaining work. Nếu team log giờ đã bỏ ra, biểu đồ sẽ sai hoàn toàn. Luôn hỏi: "còn bao nhiêu?" chứ không phải "đã làm bao nhiêu?".
Lỗi 2 — Cập nhật không đều. Burn-down bỏ quên 3 ngày rồi cập nhật một lần thì mất hết giá trị cảnh báo sớm. Biến việc cập nhật thành thói quen gắn với daily stand-up.
Lỗi 3 — Story quá lớn làm biểu đồ vô dụng. Như ví dụ 1, story 21 điểm khiến đường phẳng suốt tuần. Mẹo: chia story để không story nào vượt quá một nửa velocity ngày, lý tưởng dưới 8 điểm.
Lỗi 4 — Coi burn-down như công cụ đánh giá cá nhân. Đừng bao giờ dùng burn-down để chỉ trích ai đó "làm chậm". Nó là công cụ của team, phục vụ cải tiến, không phải để soi mói. Khi biến nó thành công cụ trừng phạt, team sẽ log số liệu đẹp giả tạo và bạn mất luôn dữ liệu thật.
Lỗi 5 — Hoảng loạn vì một ngày phẳng. Một đường phẳng một ngày là bình thường (họp nhiều, đầu sprint khởi động). Chỉ lo khi xu hướng kéo dài nhiều ngày.
Mẹo hay: Kết hợp burn-down với velocity trung bình để dự báo. Nếu đến ngày 6 còn 24 điểm mà velocity ~4 điểm/ngày, bạn còn 4 ngày nhưng cần 6 ngày — thiếu 8 điểm. Con số cụ thể như vậy khiến quyết định cắt scope trở nên khách quan, không cảm tính.
Mẹo giao tiếp: Chụp burn-down đưa vào báo cáo tuần cho stakeholder. Một hình ảnh đường đi bám sát mục tiêu tạo niềm tin mạnh hơn mọi lời cam kết bằng miệng — điều rất quan trọng khi làm việc với sếp hoặc khách quen tư duy Waterfall.
Bài tập thực hành
Bài tập 1 — Vẽ và diễn giải. Một sprint 10 ngày cam kết 50 story points. Dữ liệu remaining work cuối mỗi ngày: Ngày 0: 50, Ngày 1: 47, Ngày 2: 45, Ngày 3: 45, Ngày 4: 44, Ngày 5: 40, Ngày 6: 40, Ngày 7: 46, Ngày 8: 30, Ngày 9: 15, Ngày 10: 4. Hãy: (a) vẽ đường mục tiêu và đường thực tế trên giấy hoặc Google Sheets; (b) chỉ ra đoạn nào cho thấy blocker; (c) giải thích tại sao ngày 7 con số tăng lên 46; (d) team có hoàn thành sprint không, và điều gì đáng đưa ra retrospective?
Bài tập 2 — Dự báo. Đến ngày 6 của sprint 10 ngày, remaining là 28 điểm. Velocity trung bình 3 điểm/ngày. Hỏi: với đà hiện tại, cuối sprint còn lại bao nhiêu điểm? Team cần làm gì ngay hôm nay? Nếu Product Owner đồng ý cắt scope, cần cắt tối thiểu bao nhiêu điểm để về đích đúng hạn?
Bài tập 3 — Chọn đơn vị. Team của bạn có nhiều story lớn và stakeholder liên tục hỏi tiến độ. Bạn nên dùng burn-down theo points, theo giờ, hay cả hai? Viết 4-5 câu lập luận cho lựa chọn của mình dựa trên bối cảnh cụ thể.
Bài tập 4 — Áp dụng thật. Trong sprint tiếp theo của bạn (hoặc một dự án cá nhân chia thành các task nhỏ), tự tay cập nhật burn-down mỗi ngày trong ít nhất 5 ngày liên tục. Cuối cùng viết một đoạn ngắn: biểu đồ đã giúp bạn phát hiện điều gì mà trước đây bạn không thấy?
Tóm tắt
Burn-down chart là "đồng hồ tốc độ" của sprint: trục Y là công việc còn lại (points hoặc giờ), trục X là thời gian, đường mục tiêu là nhịp lý tưởng tuột thẳng về 0, và đường thực tế là sự thật bạn cần đọc mỗi ngày. Nằm trên mục tiêu là chậm, nằm dưới là nhanh hoặc over-estimate, phẳng là blocker, đi lên là scope creep.
Giá trị lớn nhất của burn-down không nằm ở việc vẽ đẹp mà ở việc ra quyết định sớm: gỡ blocker, cắt scope, hay báo động cho Product Owner khi còn kịp. Ba tình huống thực tế — team fintech "phẳng rồi rơi", team FPT gặp scope creep giữa sprint, và team Đà Nẵng về đích quá sớm — cho thấy burn-down là công cụ chẩn đoán đa năng, không chỉ đo tiến độ mà còn phơi bày cách team ước lượng và cách scope thay đổi.
Hãy nhớ ba nguyên tắc vàng: đo công việc còn lại chứ không phải đã làm, cập nhật mỗi ngày gắn với stand-up, và dùng nó để cải tiến team, không để trừng phạt cá nhân. Nắm vững burn-down, bạn sẽ không bao giờ phải trả lời câu "sprint có kịp không?" bằng cảm giác nữa — mà bằng dữ liệu.