Trong bài trước (http://www.hanoiscrum.net/hnscrum/learning/102) tôi đã giới thiệu “User Story là gì”. Hiểu được và thao tác được với user story thì mới mong lập kế hoạch hiệu quả được .
Lập kế hoạch tức là phải phác thảo ra được lượng nỗ lực và nguồn lực cần thiết bỏ ra trong khoảng thời gian nhất định để đạt được mục đích. Để làm được việc lập kế hoạch thì chắc chắn phải ước lượng. Nhưng ước lượng là một bài toán khó, vì đòi hỏi đoán trước tương lai. Bản chất từ “ước lượng” đã hàm ý việc không thể đòi hỏi tính chính xác 100% trong các giá trị được đưa ra. Tuy vậy, về tính “hữu ích” và thực tế, chúng ta luôn phải tìm kiếm một phương pháp ước lượng đáng tin cậy.
Trong bài “Tại sao point lại tốt hơn giờ?” (http://www.hanoiscrum.net/hnscrum/resource/109), Jeff Sutherland đã chỉ ra ưu điểm của user story point. Bài này muốn đóng góp thêm vài ý.
1. User Story point là gì?
Đó là đại lượng chỉ độ lớn tương đối của các user story trong cùng một dự án. Trong một phiên hoạch định trước Sprint, nhóm phát triển dùng Scrum Poker để đánh giá độ lớn bé các story này, và ghi các giá trị đó lên mỗi user story card.
Ví dụ ta phải làm một hệ thống có ba user story như sau:
u1. là khách hàng, tôi muốn đăng nhập vào hệ thống để xem trạng thái cua đơn hàng đã đặt.
u2. là khách hàng, tôi muốn lựa chọn các sản phẩm mong muốn vào giỏ hàng để đặt mua
u3. là khách hàng, tôi muốn hủy một đơn hàng khi đã đặt
u1 được gán là 3 điểm (point), u2 là 8, u3 là 4 tức là độ lớn của toàn bộ dự án là 15 điểm. Nỗ lực cần bỏ ra để thực hiện u3 tương đương u1, u2 gấp đôi u1. Ở đây dấu “=” có nghĩa là “khoảng ấy”, cỡ ấy chứ không hàm ý là “bằng”.
2. Độ lớn của các story có thể thay đổi theo thời gian
Do nhóm đã trưởng thành qua thời gian, hiểu biếu về hệ thống thay đổi, và có thể PO thay đổi yêu cầu v.v., nên phải tái ước lượng. Vì thế u3 có thể được đánh giá lại sau sprint 1 là 6 thay vì 4 như cũ vì có vẻ việc hủy một đơn hàng không đơn giản là nhấn nút “Hủy” mà còn phải tính tới các chính sách khác chưa được tính tới tại thời điểm ước lượng lần một. Vì thế sau phiên “làm mịn” các story, thì độ lớn của từng story thay đổi.
Nhưng ..
3. Story point là đơn vị cố định. Nó là atomic.
Không có chuyện một point ở Sprint 2 thì bằng một nửa point ở Sprint 1. Chỉ có việc u3 ở Sprint 2 có thể được ước lượng lại ở Sprint 2 là tăng lên 6 points.
Tất cả các point đều phải quy chiếu về cái gì đó làm mẫu. Ví dụ, lúc đầu, tất cả các story u2, u3, .. đều được mang ra so sánh với u1. Thì đến Sprint 3,story Un cũng phải đem ra so sánh với u1. Nếu không tham chiếu đến “tiêu chuẩn”, thì khái niệm “point” không có giá trị gì trong hoạch định dài hạn cả.
Agile Estimation (Ước lượng Linh hoạt):
1. Lấy ra một cặp story (ví dụ: u1 và u3) tương đối dễ hiểu đối với cả nhóm (hiểu cả nghiệp vụ lẫn các công việc để thực hiện hai story này); story thứ hai có độ lớn gấp đôi story kia.
2. Gán u1 số điểm là 3, u3 là 8. Hai story này để tham chiếu cho toàn bộ quá trình ước lượng các story còn lại.
3. Chơi Scrum Poker để đánh giá độ lớn các story còn lại.
Việc so sánh độ lớn của một story u3 ở Sprint 1 với Sprint 2 là không có ý nghĩa gì cả. Cái này nó biến động liên tục. Vì nó không có nghĩa nên không nên đem ra so sánh để làm gì.
4. Velocity (tốc độ) là gì?
Là số point burn được trong một Sprint.
Velocity có thể thay đổi theo thời gian. Thường là tăng.
Với giả định là các ước lượng user story point ban đầu là đáng tin thì có vẻ như velocity sẽ tăng dần do nhóm ngày càng làm việc tốt hơn, hiểu sản phẩm hơn, nắm vững công nghệ đặc thù của bài toán đó hơn v.v.
Khái niệm gia tốc có thể được tính đến khi nhóm scrum ở mức trưởng thành cao. Khi đó tốc độ tăng tiến đều và đoán được thông qua một đại lượng cố định. V2=aV1. Tuy vậy, giá trị này không phải lúc nào cũng có nghĩa.
5. Velocity có giá trị đối với việc hoạch định sản phẩm và phát hành
Giả sử nhóm là cố định. Hiệu suất của nhóm được đo bằng velocity. Giá trị này hoàn toàn tiên lượng được trong ngắn hạn.
Giả sử Sprint 1 burn được 30 point, Sprint 2 được 35 point, thì có vẻ như Sprint 3 nhóm sẽ burn được ít nhất là 35 point. Điều này là tin được, vì theo (4), nhóm sẽ làm việc ở Sprint 3 không kém hơn so với Sprint trước.
Chuyện tiên lượng này không hề bị ảnh hưởng của sự ước lượng lại tại đầu Sprint (khi đó u3 có thể đã có độ lớn bằng gấp đôi so với ước lượng lần trước). Vì sau khi làm mịn, độ lớn lại được quy ra point, và point này là lại quy về point so với thời điểm ban đầu (so với u1).
Do vậỵ Product Owner hoàn toàn có thể đoán được thời điểm một feature nào đó sẽ có (để quảng cáo, bán hàng, v.v.) cũng như phác ra một kế hoạch release khả thi.
6. Velocity không phải là công cụ đo performance của các nhân
Mặc dù ta có thể làm như vậy, và thực tế nhiều người làm như thế. Trong một nhóm có thể có quy ước “ghi công” cho ai đó khi hoàn thành một feature. Khi đó cuối Sprint ta biết được ai burn được bao nhiêu để lập “bảng thành tích” rồi “tính lương” 
.
Một số dự án đặc thù có thể cho phép cách làm như vậy. Nhưng đại thể, agile không khuyến khích cách làm như vậy. Agile vốn khuyến khích tương tác, cộng tác, sở hữu tập thể thì không có lí gì lại đi đo thành tích cá nhân dựa trên số point burn được của từng cá nhân. Cái này là scrumbut.
7. Quy đổi ra giờ
Cuối cùng thì ai cũng hỏi vậy tương đương Point-Giờ thế nào? Vì cái làm việc theo giờ thì dễ hình dung hơn về độ lớn của dự án. Chứ point “ảo” quá! Quy ra person-month hộ tôi cái!!! 
Chỉ có mối tương quan point-giờ trong phạm vi dự án mà thôi do point là chỉ là đơn vị có giá trị trong nội bộ một dự án. Point trong dự án này không bằng point trong dự án khác (do quy chiếu khác nhau).
Cách quy đổi khá dễ: nếu nhóm năm người burn được 30 point trong 1 sprint 1 tháng, thì rõ ràng là một point bằng năm person-month rồi. Tuy nhiên bản thân độ đo user story point đã đủ tốt rồi, nếu không phải trường hợp vạn bất đắc dĩ, không việc gì phải dùng thêm một độ đo khác vốn cực kì bất ổn là person-month (cái này thì sách nói nhiều rồi).
8. Dùng point cho story, nhưng dùng “giờ” cho task
Khi PO quyết định nhóm phải burn 30 point trong Sprint tới với các story được chọn lựa thì việc của nhóm là phải break down các Story kia thành ra các task với ước lượng ra “giờ” để điền vào Sprint Backlog. Trong trường hợp này, nhóm lại quên khái niệm point đi (thực ra khái niệm này có nghĩa với PO hơn là với dev), để tập trung việc burn được bao nhiêu productive hours.
Sự nhầm lẫn hay xảy ra khi nhóm vẫn dùng Scrum Poker để ước lượng các task nhưng lại nghĩ là mình ước lượng các story. Để tránh nhầm lẫn nầy, không nên để hai phiên làm việc release planning (đánh giá story) liền với Sprint Planning (chẻ nhỏ story).
