Story Point
Đơn vị ước lượng tương đối cho một hạng mục backlog, gộp cả độ phức tạp, khối lượng và mức rủi ro. So sánh việc này với việc kia, chứ không quy ra giờ công.
Định nghĩa
Con người ước lượng thời gian tuyệt đối rất tệ, nhưng so sánh thì khá ổn. Hỏi "cái này mất mấy giờ" thì mười người mười đáp án lệch nhau ba lần. Hỏi "cái này khó hơn hay dễ hơn cái kia" thì đa số đồng ý nhanh. Story point sống nhờ đúng đặc điểm đó.
Một story point gộp ba thứ: khối lượng công việc, độ phức tạp, và mức không chắc chắn. Story cần đụng vào một hệ thống bên thứ ba mà chưa ai từng gọi thử sẽ điểm cao hơn story nhiều màn hình nhưng làm theo khuôn có sẵn.
Story point không có đơn vị. Nó chỉ có ý nghĩa khi so với các story khác của chính team đó.
Cách một team bắt đầu chấm điểm
- Chọn một story mốc. Lấy một story vừa làm xong, cỡ nhỏ, ai cũng nhớ. Gọi nó là 3 điểm. Đừng chọn story 1 điểm làm mốc, vì mọi thứ sau đó sẽ bị dồn lên trên.
- Dùng dãy Fibonacci rút gọn: 1, 2, 3, 5, 8, 13. Khoảng cách giãn dần vì độ chính xác giảm dần khi story to lên. Không có 4 và 6 là cố ý, để team khỏi cãi nhau chuyện nửa điểm.
- Planning poker. Mỗi người chọn thẻ độc lập rồi lật cùng lúc. Ai để số cao nhất và ai để thấp nhất nói lý do trước. Giá trị nằm ở phần tranh luận, con số chỉ là cái cớ.
- Story trên 13 điểm thì trả về refinement. Đó là tín hiệu chưa hiểu rõ, không phải tín hiệu story khó.
Đó là lý do nhiều người nói ước lượng có ích hơn con số ước lượng. Cuộc cãi 5 phút giữa dev và BA về việc "có phải đối soát ngược không" thường cứu được hai ngày làm sai.
So sánh với ước lượng bằng giờ công
| Tiêu chí | Story point | Giờ công |
|---|---|---|
| Đo cái gì | Độ phức tạp, khối lượng, rủi ro | Thời gian một người bỏ ra |
| Phụ thuộc người làm | Không, cùng team thì cùng thang | Có, senior nhanh hơn junior |
| Dùng để làm gì | Dự báo dung lượng nhiều sprint | Lập lịch chi tiết, tính chi phí |
| Cãi nhau nhiều không | Ít, vì chỉ so tương đối | Nhiều, vì ai cũng thấy mình bị ép |
Ở dự án outsourcing tính tiền theo man-day, bạn vẫn phải có ước lượng giờ cho hợp đồng. Cách xử lý thực dụng: giữ hai lớp riêng biệt. Lớp hợp đồng dùng man-day do team lead ước tính, lớp vận hành sprint dùng story point. Đừng nối hai lớp đó bằng một tỉ lệ quy đổi.
Chuyện lạm dụng, nói thẳng
Bốn kiểu dưới đây, kiểu nào cũng đủ để giết story point trong một quý.
Quy story point ra giờ. "Một điểm bằng 4 tiếng nhé" là câu giết chết story point nhanh nhất. Khi đã có tỉ lệ quy đổi, điểm trở thành cam kết thời gian, và mọi ưu thế của ước lượng tương đối biến mất. Team sẽ tự động cộng thêm đệm vào mọi con số.
Dùng điểm để so team này với team kia. Thang điểm của mỗi team được hình thành từ story mốc riêng và trình độ riêng. Team A 40 điểm mỗi sprint không hề "kém" team B 60 điểm. Bảng xếp hạng kiểu này chỉ dẫn tới một kết quả: cả hai team cùng thổi điểm lên.
Chấm điểm cá nhân rồi ghép vào đánh giá cuối năm. Sau lần đầu tiên, sẽ chẳng ai dám nhận story khó nữa.
Ép team tăng điểm mỗi sprint. Điểm là số do team tự đặt ra, nên team hoàn toàn có thể làm nó tăng mà chẳng cần làm nhanh hơn một giây nào.
Ví dụ thực tế
Trung tâm ngoại ngữ 9 cơ sở, ứng dụng quản lý học viên. Team lấy story mốc là "thêm trường ghi chú vào hồ sơ học viên" và gọi nó 3 điểm.
- "Xuất danh sách điểm danh ra Excel theo lớp": 5 điểm, quen tay nhưng nhiều trường hợp biên.
- "Đồng bộ lịch học sang Google Calendar của giáo viên": 13 điểm, vì chưa ai trong team làm OAuth với Google bao giờ.
- "Đổi màu nút Lưu theo bộ nhận diện mới": 1 điểm.
Sprint sau, story Google Calendar làm mất gần trọn sprint và team nhận ra đáng lẽ nên tách phần thử nghiệm OAuth thành một spike riêng 2 ngày. Đó là bài học đúng để mang vào retro, và nó có được là nhờ con số 13 kia đã cảnh báo từ đầu mà không ai để ý.
Nếu team bạn đang cãi nhau về story point quá nhiều, thử bỏ luôn: đếm số story hoàn thành mỗi sprint và giữ story ở kích cỡ tương đối đều nhau. Nhiều team chạy kiểu đó dự báo còn ổn hơn.
