Story Point là gì?
Bộ não con người giỏi so sánh hơn là đưa ra những đánh giá mang quan điểm cá nhân. Bạn thường có thể xác định được trong 2 cuốn sách, cái nào dài hơn, nhưng ước tính chính xác có bao nhiêu trang là cực kỳ khó. Nguyên tắc này dựa trên cơ sở lý thuyết đơn giản nhưng rất thành công được gọi là Story Points (số point, số điểm).
Story Points là một thước đo trừu tượng,không có đơn vị.
Story Point nên được ước lượng được theo dải Fibonacci
Khi ước lượng kích thước user story đa số các agile team sử dụng một bộ số không liên tiếp. Ví dụ dãy các bội số của 2 (1, 2, 4, 8, 16,…), hoặc dãy số Fibonacci (1, 2, 3, 5, 8, 13, …). Không dùng dãy số liên tiếp sẽ giúp team tránh được việc phải cân nhắc chọn ví dụ 15 hay 16. Ước lượng đến độ chính xác từng đơn vị point kiểu như vậy là tốn thời gian, không có ý nghĩa thực tế và thậm chí là không thể.
Các Agile Practioners từ lâu đã nhận ra giá trị của việc định cỡ các Story bằng cách sử dụng cách định cỡ tương đối. Story Point là đơn vị đo lường phổ biến nhất cho các Agile Team đo đạc định cỡ tương đối (relative sizing). Thang điểm phổ biến nhất được sử dụng cho các điểm câu chuyện là dãy Fibonacci (1, 2, 3, 5, 8, 13, v.v.).
Chuỗi Fibonacci cho Story Point: Một khi nhóm quyết định lập kế hoạch theo thang điểm, nhóm cần thống nhất và quyết định sẽ áp dụng theo cách tính điểm nào. Một số nhóm sử dụng chuỗi Fibonacci hoặc một số biến thể của chuỗi này (1, 2, 3, 5, 8, 13, 21...) cho story point vì cho rằng chuỗi Fibonacci cung cấp cái nhìn thực tế hơn về độ lớn của một story, về tính tương đối của độ lớn của một story này so với một story khác. Nếu như bạn đang sử dụng thang đo một cách nhất quán, thì đó không phải là vấn đề khi sử dụng.
Ước tính Fibonacci nằm giữa phương pháp tuyến tính (linear) và cấp số nhân (exponential)
Các ước tính thường có thể không chính xác - điều này xảy ra bởi vì mọi người có xu hướng lạc quan quá mức.
Ví dụ: thay vì đưa ra ước tính dựa trên một dự án tương tự mà chúng ta đã hoàn thành trước đây, chúng ta có xu hướng tin rằng chúng ta có thể hoàn thành nó nhanh hơn vì chúng ta có nhiều kinh nghiệm hơn và chắc chắn rằng lần này sẽ không có bất kỳ sự cố nào gây ra sự chậm trễ.
Vì thang đo Fibonacci Agile là cách tiếp cận gần với cấp số nhân thay vì tuyến tính, điều này sẽ giúp các team tính toán thực tế hơn khi xem xét các nhiệm vụ lớn, phức tạp hơn.
Sử dụng Planning Poker để Estimate các dự án trong Agile
Planning Poker được sử dụng trong agile dựa trên sự đồng thuận trong việc ước tính. Để bắt đầu một lần ước tính, Product Owner hoặc khách hàng đọc một User Story hoặc mô tả một tính năng của sản phẩm với những người tham gia ước tính, thường là tất cả các thành viên của một Nhóm. Mỗi người tham gia ước tính cầm một bộ bài (Poker) gồm các giá trị như 0, 1, 2, 3, 5, 8, 13, 20, 40, và 100 (dãy Fibonacci).
Các giá trị đó thể hiện số điểm (story point), lý tưởng là theo số ngày, hoặc bất cứ đơn vị nào mà nhóm dự tính. Các thành viên của nhóm cùng thảo luận về tính năng đó, đặt các câu hỏi với Product Owner nếu cần thiết. Khi tính năng này đã được thảo luận kỹ lưỡng, mỗi thành viên sẽ tự chọn một lá bài để đưa ra ước tính của mình. Tất cả các là bài sẽ được lật lên cùng nhau. Nếu tất cả các lá bài đó có giá trị như nhau thì giá trị đó được chấp nhận là ước tính của tính năng vừa thảo luận. Nếu không, các thành viên của nhóm cùng thảo luận về các ước tính mà mình đưa ra.
Trò chơi diễn ra như sau:
- Bước 1: User Story (câu chuyện của người dùng) được thông báo cho toàn bộ nhóm, trong đó mỗi thành viên trong nhóm ước tính số điểm Story Points và không tiết lộ lựa chọn của mình cho người khác,
- Bước 2: Tất cả các ước tính được công bố cùng một lúc,
- Bước 3: Ước tính cao và thấp được giải thích bởi những người chọn và sau đó sẽ được đưa ra thảo luận
- Sau một hồi thảo luận, mỗi thành viên chọn một lá bài để ước tính lại và các lá bài của họ lại đồng thời được lật lên. Quy trình này sẽ lặp đi lặp lại cho tới khi đạt được sự đồng thuận của các thành viên hoặc họ quyết định rằng ước tính về tính năng này cần hoãn lại cho tới khi có thêm các thông tin bổ sung.
Thí dụ: Áp dụng Story Point cho các User Story.
Estimate các task
Sau khi đã có danh sách chi tiết các task, một số team tiến hành estimate các task theo số giờ cần để hoàn thành task nhắm giúp team xác định rõ hơn khối lượng công việc cho sprint sắp tới đã phù hợp chưa. Tới đây thì team đã có danh sách các task và thời gian cần thiết để hoàn thành các task đó, do đó kế hoạch sprint đã đủ chi tiết để có thể bắt đầu sprint mới.
Estimation trong các dự án Scrum
Trong các dự án Scrum, Estimation được thực hiện bởi toàn bộ nhóm trong cuộc họp lập kế hoạch Sprint- Sprint planning meeting. Mục tiêu của Estimation sẽ là xem xét các User story sẽ làm trong Sprint theo mức độ ưu tiên và theo khả năng của nhóm để bàn giao trong khoảng thời gian Timebox của Sprint.
Chủ sở hữu sản phẩm (Product Owner) đảm bảo rằng User story rõ ràng, có khả năng ước lượng và chúng sẽ được xếp lên trên đầu của Product Backlog.
Vì nhóm Scrum hoàn toàn chịu trách nhiệm bàn giao sản phẩm, nên họ cần cẩn thận khi chọn User story cho Sprint dựa trên khối lượng công việc cần bàn giao - Product Increment và nỗ lực để đạt được.
Kích thước của Product Increment được ước tính theo User Story Point. Khi kích thước được xác định, nỗ lực cần bỏ ra (effort) sẽ được ước tính bằng các dữ liệu trong quá khứ. Effort trên User Story point được gọi là Productivity.
Nguồn: TIGO
