Cách tính giá trị trong Burn Down Chart trong Scrum

Sau khi công bố với bạn bè bài viết đầu tiên về Burn Down Chart, trong phần bình luận câu hỏi thứ hai được đặt ra: "Không rõ các giá trị này được tính như thế nào". Vì vậy, trong bài viết này tôi sẽ cố gắng giải thích cách chúng tôi tính các giá trị hàng ngày trên Burn Down Chart. Như thường lệ, tôi sẽ vui mừng với mọi bình luận của đồng nghiệp nếu chẳng may tôi nói điều gì không đúng, nhưng vẫn muốn tin rằng chủ đề này đủ rõ ràng đối với tôi.

Hãy nhớ lại một lần nữa biểu đồ này trông như thế nào.

Trong ví dụ này xem xét một sprint 10 ngày. Trong đó chúng ta thấy đã qua 2 ngày (vì chỉ có 2 phân đoạn đầu tiên được tô bằng biểu đồ màu xanh lá).

Chúng ta cũng thấy tổng khối lượng sprint - đây là đường nét đứt cho thấy tổng khối lượng sprint vào thứ Hai lúc 10:00, thứ Ba lúc 10:00 và thứ Tư lúc 10:00 không thay đổi và bằng 17 SP (Story Points).

Theo phương pháp luận Scrum, tổng khối lượng công việc trong sprint không thay đổi trong suốt sprint, vì vậy đường này thường được vẽ ngay cho toàn bộ sprint (cả 10 ngày). Nó cũng giúp đánh giá còn lại bao nhiêu việc phải làm một cách trực quan hơn so với nếu nó kết thúc vào ngày thứ ba như trong phương án hiện tại.

Đường cháy thực tế (biểu đồ màu xanh lá) cho thấy công việc thực tế còn lại. Tức là hiện tại đội đã hoàn thành 1 Story Point trong số 17 cần hoàn thành để kết thúc sprint thành công. Thường được coi là hoàn thành là task ở trạng thái "Done" (Done là gì đối với mỗi đội, đội tự xác định. Thậm chí có một artifact đặc biệt gọi là DOD - Definition Of Done - nó riêng cho mỗi đội và mô tả rất chính xác ý nghĩa của việc task đã hoàn thành và có thể chuyển sang trạng thái "Done". Thường nhất là "Đã triển khai lên prod", nhưng có thể có các sắc thái. Tóm lại, theo biểu đồ hiện tại chúng ta hiểu rằng chỉ có một story được đội đánh giá 1 SP là đã hoàn thành DOD.

Đường cháy lý tưởng cho thấy biểu đồ cháy thực tế phải nằm ở điểm nào trong trường hợp công việc hoàn toàn đồng đều. Tức là tại thời điểm này phải hoàn thành 3 SP nếu công việc hoàn toàn đồng đều.

Tôi nghi ngờ rằng có thể thú vị khi hiểu Story Pointlà gì. Về bản chất, 1 SP ở một đội và 1 SP ở đội khác có thể ẩn chứa khối lượng công việc khác nhau. Ví dụ, chúng tôi có các đội có cùng số người, nhưng một đội có năng lực sprint là 17 SP, còn đội kia là 35 SP. Và điều đó là bình thường. Vấn đề là đội tự chọn cho mình một task chuẩn để so sánh đánh giá tất cả các task trong các buổi grooming (tên cũ - đây là cuộc họp hàng tuần, nơi PO mang User Stories đến để đánh giá, và đội đánh giá chúng thông qua planning poker) (Trong SAFe đây là PBR - Product Backlog Refinement).

Như vậy, chúng ta có thể có một User Story chuẩn "Tôi, với vai trò người lái xe ô tô, muốn sau khi đổ xăng cho xe, có thể khi cần nhận được hóa đơn in trên giấy". Thống nhất rằng nó đối với đội chúng tôi là 8SP. Và khi PO kể một User Story mới mà chúng tôi phải đánh giá, chúng tôi đánh giá nó so với task chuẩn. Theo đó, story mới có thể được đội đánh giá là 5 SP, ví dụ, v.v. tất cả các story trong backlog đều nhận được đánh giá của mình.

Năng lực của đội được tính dựa trên thống kê. Trong 1-2 sprint đầu tiên đo số lượng SP mà đội đóng được và tính giá trị trung bình, việc lập kế hoạch dựa trên giá trị này (khi PO chọn các task vào sprint từ backlog theo một năng lực nhất định).

Hy vọng tôi đã mô tả đủ rõ ràng cách các giá trị trên Burn Down Chart được tạo ra.