Spike trong agile là gì, có nên tính story point cho spike không?

Spike bắt nguồn từ Lập trình cực hạn (Extreme Programming — XP): một "spike solution" là chương trình rất đơn giản để khám phá giải pháp tiềm năng cho một vấn đề kỹ thuật khó hoặc để giảm rủi ro ước lượng, thường bị bỏ đi sau khi đã học xong. Hiện nay spike được hiểu rộng là một hạng mục có giới hạn thời gian nhằm thu thập kiến thức, không nhằm giao tính năng.

Một spike tốt cần có

1. Câu hỏi cụ thể cần trả lời, ví dụ (giả định): "API định danh của đối tác có hỗ trợ xác thực hai bước trong luồng của chúng ta không, độ trễ bao nhiêu?"
2. Hộp thời gian (timebox) rõ — thường vài ngày, hiếm khi cả sprint. Hết giờ thì dừng và báo cáo những gì đã biết.
3. Đầu ra: quyết định hoặc thông tin đủ để ước lượng và tách story thật — một bản ghi ngắn, một prototype bỏ đi, hoặc demo cho PO.

Với PO, spike chính là giảm rủi ro có kiểm soát: bỏ ra vài ngày để tránh cam kết sai cả tháng.

Có tính point cho spike? Hai trường phái:

• Không tính: velocity chỉ phản ánh giá trị giao được; spike chiếm năng lực nên đội đơn giản là nhận ít story hơn trong sprint đó.
• Có tính (hoặc gán theo timebox): để kế hoạch sprint phản ánh đúng năng lực bị chiếm dụng.

Cả hai đều chấp nhận được nếu đội nhất quán. Điều cần tránh: spike chiếm phần lớn sprint liên tục — đó là dấu hiệu backlog thiếu refinement hoặc rủi ro kỹ thuật lớn cần nêu với bên liên quan.

Nguồn:

• extremeprogramming.org — Spike Solution
• Mountain Goat Software — Agile Spikes