Burndown Chart
Đồ thị cho thấy khối lượng công việc còn lại giảm dần theo thời gian trong sprint hoặc release. Công cụ để team tự soi mình, không phải bảng chấm điểm cho quản lý.
Định nghĩa
Trục ngang là ngày trong sprint. Trục dọc là khối lượng còn lại, thường tính bằng story point hoặc số giờ ước tính. Vẽ thêm một đường thẳng lý tưởng từ góc trên trái xuống góc dưới phải, rồi mỗi ngày chấm một điểm thực tế. Hết.
Giá trị của biểu đồ này nằm ở chỗ nó biến một câu hỏi mơ hồ ("mình có kịp không") thành một hình vẽ mà cả team nhìn phát biết ngay.
Đường thực tế nằm trên đường lý tưởng ba ngày liền là lúc phải bàn cắt bớt phạm vi, không phải lúc bảo nhau cố lên.
Đọc hình dạng đường cong
- Phẳng lì rồi rơi thẳng đứng ở ngày cuối. Kiểu hay gặp nhất, và đáng lo nhất. Team làm cả sprint mà không đóng nổi item nào cho tới hôm chót — thường vì item quá to, hoặc phần test dồn hết về cuối.
- Đi lên. Có việc được nhét thêm giữa sprint. Không xấu nếu có lý do, miễn là nhìn thấy nó.
- Bậc thang to. Story quá to, mỗi lần đóng tụt một cục. Chẻ nhỏ đi.
- Trùng khít đường lý tưởng. Đẹp quá thành đáng ngờ. Việc phần mềm hiếm khi mượt vậy; thường là có người sửa số cho vừa mắt.
- Về 0 sớm hai ngày. Nhận quá ít việc. Cũng là ước lượng sai, chỉ là sai theo chiều dễ chịu hơn.
Ví dụ thực tế
Ba sprint liền, burndown của một team làm ứng dụng đặt sân thể thao đều phẳng lì tới ngày thứ 7 rồi rơi dốc. Sáu người, sprint 2 tuần, mỗi sprint nhận 38 điểm.
Nhìn kỹ thì thấy nguyên nhân: team chỉ có một QC, và mọi story đều dồn về chờ kiểm thử từ ngày thứ 6 trở đi. Trước ngày đó, số điểm còn lại không giảm được vì chưa story nào đạt Definition of Done.
Cách xử lý sau retro: chẻ story nhỏ hơn để có thứ hoàn thành từ ngày thứ 3, và dev viết sẵn dữ liệu test để QC vào việc nhanh. Sprint kế tiếp đường cong bắt đầu giảm từ ngày thứ 4. Vẫn 38 điểm, nhưng rủi ro trượt sprint giảm hẳn vì vấn đề lộ ra sớm hơn ba ngày.
So sánh Burndown và Burnup
| Tiêu chí | Burndown | Burnup |
|---|---|---|
| Đường chính | Việc còn lại, giảm dần về 0 | Việc đã xong, tăng dần |
| Phạm vi tổng | Không hiện rõ | Có đường riêng, thấy ngay khi scope tăng |
| Dễ đọc | Rất dễ, hợp dán tường | Cần giải thích một chút |
| Hợp dùng cho | Trong một sprint | Theo dõi release nhiều sprint |
Với dự án hay bị thêm phạm vi giữa chừng — nghĩa là gần như mọi dự án ở Việt Nam — burnup nói được nhiều hơn. Nó tách hai chuyện ra: team làm được bao nhiêu, và cái đích bị đẩy xa thêm bao nhiêu. Burndown gộp cả hai vào một đường nên khi đường đi ngang, bạn không biết lỗi tại ai.
Lỗi hay gặp
- Dùng burndown để đánh giá team. Quản lý in ra rồi hỏi vì sao đường không đẹp. Sau lần đó, số liệu sẽ luôn đẹp và luôn vô dụng.
- Không cập nhật hằng ngày. Cập nhật một lần vào thứ Sáu thì biểu đồ chẳng còn tác dụng cảnh báo sớm.
- Đếm cả item làm dở. Chỉ trừ điểm khi item đạt Definition of Done.
- Vẽ burndown theo giờ còn lại rồi bắt dev khai giờ mỗi ngày. Tốn công, và dev sẽ khai số cho tròn.
- Coi biểu đồ là mục tiêu. Mục tiêu là Sprint Goal. Biểu đồ chỉ là cái đèn báo.
Nếu team đang chạy tốt, không có gì bắt buộc phải dùng burndown. Nhiều team chỉ nhìn bảng công việc và đếm số thẻ chưa xong cũng đủ. Scrum Guide không yêu cầu biểu đồ nào cả, chỉ yêu cầu team nhìn thấy được tiến độ so với Sprint Goal.
