Lỗi thường gặp và cách tránh

✖Quy đổi story point ra giờ, giao chỉ tiêu điểm cho từng người

Vì sao có hại

Mọi người chấm điểm “cho đẹp”, velocity mất ý nghĩa, không lập kế hoạch được nữa.

Cách tránh

Điểm là của team; đánh giá cá nhân bằng chất lượng, hợp tác, kết quả sản phẩm.

✖Sprint bị kéo dài thêm vài ngày “cho xong”

Vì sao có hại

Velocity không so sánh được; mất kỷ luật time-box.

Cách tránh

Hết hạn thì hoàn thành sprint, việc dở dang về backlog; hạ cam kết sprint sau.

✖Thêm việc giữa sprint liên tục

Vì sao có hại

Team không đạt mục tiêu, burndown đi lên, mất động lực.

Cách tránh

Đổi việc tương đương; việc gấp thật sự thì ghi nhận để bàn ở Retro; giữ 10–15% dự phòng.

✖Board không cập nhật, cuối sprint kéo Done hàng loạt

Vì sao có hại

Burndown và báo cáo vô dụng, phát hiện chậm trễ quá muộn.

Cách tránh

Cập nhật trong ngày; daily đứng trước Board; nhắc khi thẻ nằm im quá 2 ngày.

✖Việc quá to (từ 13 điểm, nhiều ngày không xong)

Vì sao có hại

Khó ước lượng, khó review, burndown đi ngang.

Cách tránh

Tách task con theo kết quả kiểm tra được; mỗi việc không quá 3 ngày công.

✖Daily thành buổi báo cáo cho PM, kéo dài 40 phút

Vì sao có hại

Mất thời gian, mọi người ngại nói thật.

Cách tránh

3 câu hỏi, 15 phút; vấn đề phức tạp hẹn riêng.

✖Không có Definition of Done, “xong” mỗi người một kiểu

Vì sao có hại

Bug lọt, việc Done bị mở lại, tiến độ ảo.

Cách tránh

Viết DoD, Review bắt buộc, QA là người kéo Done.

✖Retro không có hành động, hoặc không ai theo dõi

Vì sao có hại

Cùng một vấn đề lặp lại sprint này qua sprint khác.

Cách tránh

Mỗi Retro 1–2 hành động, tạo Task trên Pentara, kiểm tra lại đầu buổi Retro sau.

✖Yêu cầu khách hàng nhảy thẳng vào Board, không qua tiếp nhận

Vì sao có hại

Làm trùng, bỏ sót yêu cầu, không đo được SLA.

Cách tránh

Tiếp nhận ở tab Yêu cầu KH → phân loại → chuyển thành task có phân hệ và ưu tiên.