Story point là gì? Cách chấm điểm công việc trong Scrum, có ví dụ

Định nghĩaStory point là đơn vị đo độ lớn tương đối của một việc trong Scrum, gộp cả khối lượng, độ phức tạp và độ không chắc chắn. Nó không phải giờ: “việc này 5 điểm” không có nghĩa là 5 giờ, mà là “to hơn việc 3 điểm, nhỏ hơn việc 8 điểm”. Đội tự chấm điểm cho từng việc trước khi đưa vào sprint, rồi dùng tổng điểm làm được mỗi sprint (velocity) để lập kế hoạch.

Cách chấm thường dùng dãy Fibonacci rút gọn 1, 2, 3, 5, 8, 13, và cả đội cùng chấm bằng Planning Poker. Đây là khái niệm gây tranh cãi nhiều nhất khi đội Việt Nam mới chạy Scrum, thường vì bị hiểu thành một cách đo giờ khác.

Con người ước lượng tuyệt đối rất kém nhưng so sánh tương đối khá tốt. Hỏi “tòa nhà kia cao bao nhiêu mét” thì mỗi người một đáp án; hỏi “tòa nào cao hơn” thì mọi người trả lời giống nhau và đúng. Ước lượng giờ là câu hỏi thứ nhất; story point là câu hỏi thứ hai.

Giờ còn có ba rắc rối riêng. Giờ của người giỏi khác giờ của người mới, nên một con số không có nghĩa chung cho cả đội. Giờ hay bị đem ra so với giờ thực tế để hỏi “sao chậm thế”, nên mọi người sẽ khai cao lên cho an toàn. Và giờ đổi khi đổi người làm, còn độ lớn của việc thì không. Điểm tránh được cả ba: nó là con số của đội, không của cá nhân, và chỉ có nghĩa khi so với các việc khác trong cùng đội.

Hai việc cùng tốn một ngày có thể khác điểm: một việc dài nhưng dễ (nhiều màn hình giống nhau) và một việc ngắn nhưng chưa ai biết cách làm. Điểm phản ánh cả rủi ro, không chỉ thời gian.

Khoảng cách giữa các số tăng dần: 1 và 2 cách nhau một điểm, 8 và 13 cách nhau năm điểm. Đó là chủ ý. Việc càng to thì ước lượng càng mù mờ, nên bắt đội chọn giữa 8 và 9 là giả vờ chính xác. Dãy thưa dần buộc đội nói “việc này cỡ 8” hoặc “cỡ 13” thay vì cãi nhau về 10 hay 11.

Bước đầu tiên là chọn việc mốc: một việc cả đội đã làm, hiểu rõ, nhỏ nhưng không tầm thường, gán cho nó 1 hoặc 2 điểm. Mọi việc khác chấm bằng cách so với mốc: gấp đôi, gấp ba, gấp năm.

Planning Poker là cách cả đội chấm cùng lúc mà không bị người nói trước dẫn dắt: PM đọc việc, mọi người hỏi cho rõ, mỗi người chọn kín một con số, lật cùng lúc. Người chọn cao nhất và thấp nhất giải thích, rồi chấm lại, tối đa hai, ba vòng. Mục đích thật của buổi chấm không phải con số mà là câu giải thích: đó là lúc cả đội phát hiện việc có phần chưa ai nghĩ tới. Chi tiết từng bước ở chương Ước lượng.

Bản thân con số 5 hay 8 không cho biết bao giờ xong. Điểm trở nên hữu ích khi đội đo velocity: tổng điểm của việc đã xong trong mỗi sprint, lấy trung bình ba sprint gần nhất. Velocity trả lời hai câu hỏi PM hay bị hỏi: sprint này nhận được bao nhiêu việc, và phần backlog còn lại mất mấy sprint. Cách đọc velocity ở chương Đo lường; biểu đồ theo ngày trong sprint xem Burndown chart là gì?.

Danh sách đầy đủ hơn ở Lỗi thường gặp và cách tránh.

1 story point bằng bao nhiêu giờ?

Không có quy đổi cố định, và không nên đặt ra. Điểm chỉ có nghĩa khi so với các việc khác của cùng một đội; 3 điểm của đội này không bằng 3 điểm của đội kia. Nếu cần ước lượng thời gian, dùng velocity: đội làm được khoảng 25 điểm mỗi sprint 2 tuần thì backlog 100 điểm cần chừng 4 sprint.

Bug có chấm story point không?

Bug phát hiện trong sprint cho việc đang làm thì không chấm, vì nó thuộc về việc đó. Bug từ bản đã phát hành mà đưa vào sprint như một việc riêng thì chấm như việc thường, để velocity phản ánh đúng chi phí bảo trì. Đội thống nhất một cách và giữ nhất quán.

Ai chấm điểm: PM hay cả đội?

Những người trực tiếp làm, tức dev, tester, BA. PM (hoặc Product Owner) đọc việc, trả lời câu hỏi, nhưng không bỏ phiếu: người không làm không thấy chỗ khó, và người làm không cam kết với con số do người khác đặt.

Đội mới bắt đầu nên chọn việc mốc thế nào?

Chọn một việc cả đội đã làm gần đây, hiểu rõ, nhỏ nhưng không tầm thường, gán 1 hoặc 2 điểm. Chọn thêm một việc cỡ trung bình gán 5 để có hai mốc so sánh. Sau ba sprint xem lại: việc nào lệch nhiều so với thực tế thì đổi mốc.