Story Point là gì?

Story Point trong Jira là một phương pháp ước lượng sử dụng trong phát triển phần mềm Agile để đo lường độ phức tạp và công sức cần thiết để hoàn thành một công việc hoặc một tính năng cụ thể. Điểm của Story Point không phản ánh thời gian thực tế cần thiết để hoàn thành công việc, mà thay vào đó, nó đo lường độ khó khăn và công sức cần thiết so với các công việc khác trong dự án.

Story point được sử dụng để xác định khối lượng công việc mà team có thể hoàn thành trong 1 sprint.

Vì sao không sử dụng tham số thời gian để ước lượng (Ngày/giờ)?

Không sử dụng giờ hoặc ngày để ước lượng là vì chúng không phản ánh đúng độ khó của công việc. Những công việc phức tạp thường yêu cầu nhiều hơn thời gian và nỗ lực để hoàn thành, và việc sử dụng thời gian làm chuẩn đo lường có thể dẫn đến ước lượng không chính xác. Hơn nữa, mỗi thành viên trong nhóm có tốc độ làm việc khác nhau, do đó việc sử dụng thời gian cố định không phản ánh đúng khả năng làm việc của mỗi người.

Khi dự toán thời gian bằng giờ cho một nhiệm vụ mà công việc cụ thể chưa được xác định rõ ràng, nó tạo ra một áp lực không cần thiết như một deadline. Điều này có thể gây ra stress liên tục nếu có sự cố đột xuất mà bạn không thể giải quyết kịp thời.

Đánh giá hoặc xác định số lượng Story Point cho một công việc thường dựa trên các tiêu chuẩn sau:

1. Độ phức tạp của công việc: công việc càng phức tạp, càng yêu cầu nhiều kiến thức và kỹ năng, thì số Story Point sẽ càng cao.
2. Số lượng công việc cần hoàn thành: nếu một công việc bao gồm nhiều tác vụ nhỏ, thì nó sẽ có nhiều Story Point hơn.
3. Rủi ro và sự không chắc chắn: những công việc có nhiều biến số hoặc yếu tố không chắc chắn sẽ có nhiều Story Point hơn để phản ánh rủi ro và công sức cần thiết để giải quyết những vấn đề không lường trước được.
4. Yêu cầu về thời gian: một công việc cần hoàn thành trong thời gian ngắn hơn sẽ yêu cầu nhiều Story Point hơn, do nó đòi hỏi một lượng lớn công sức trong một khoảng thời gian ngắn.

Ví dụ, nếu có một task liên quan đến việc tạo ra một chức năng mới trên website, developer có thể ước tính rằng nó sẽ mất 3 Story Points dựa trên độ phức tạp của code và thời gian cần thiết để lập trình. Tuy nhiên, tester có thể ước tính rằng task sẽ mất 8 Story Points dựa trên nhu cầu kiểm thử toàn diện, rủi ro liên quan đến lỗi và thời gian cần thiết để thử nghiệm và kiểm tra chức năng mới.

Vì sự khác biệt trong quan điểm và trách nhiệm giữa developer và tester, họ có thể đánh giá số lượng Story Point cần thiết cho cùng một công việc một cách khác nhau. Điều này không phải là một vấn đề lớn, miễn là mỗi người trong nhóm hiểu rõ về cách thức ước lượng và đánh giá Story Point. Mục đích chính của việc ước lượng Story Point không phải là để đạt được một con số chính xác, mà là để đưa ra một ước lượng tương đối về độ khó và công sức cần thiết để hoàn thành công việc.

Trong ví dụ trên, developer có thể cho rằng việc tạo ra một chức năng mới trên website không quá phức tạp và chỉ cần 3 Story Points. Tuy nhiên, tester có thể thấy rằng việc kiểm thử toàn diện, xử lý rủi ro liên quan đến lỗi, và thời gian cần thiết để thử nghiệm và kiểm tra chức năng mới đòi hỏi nhiều công sức hơn, tính năng này quan trọng có thể gây ảnh hưởng nhiều đến các tính năng khác hoặc rủi ro đến hệ thống do đó cần đến 8 Story Points.

Cách ước tính Story point phổ biến

Thành viên tham gia ước lượng Story Point thường là các thành viên của nhóm phát triển như developer & tester. Scrum Master & Product Owner không tham gia. Quá trình này thường diễn ra trong suốt Sprint Planning Meeting.

Một cách phổ biến để ước lượng Story Point là sử dụng một công việc cơ bản nhất trong dự án như một chuẩn đo lường. Công việc này sẽ được gán 1 Story Point. Sau đó, tất cả các công việc khác sẽ được so sánh với công việc cơ bản này để xác định số Story Point. Ví dụ, nếu một công việc được đánh giá là phức tạp gấp đôi công việc cơ bản, nó sẽ được gán 2 Story Points. Cách tiếp cận này giúp đơn giản hóa quá trình ước lượng và tạo ra một chuẩn đo lường nhất quán cho toàn bộ dự án.

Để ước lượng Story Point cách thường được áp dụng là là sử dụng dãy Fibonacci, một chuỗi số trong đó mỗi số là tổng của hai số trước đó (1, 2, 3, 5, 8, 13, 21,…). Đơn vị đo lường này giúp phản ánh độ phức tạp tăng lên của công việc khi bạn đi sâu vào dự án.

Khi sử dụng dãy Fibonacci để ước lượng Story Point, mỗi công việc sẽ được gán một số từ chuỗi tương ứng với độ phức tạp của công việc đó. Ví dụ, nếu một công việc được đánh giá là khá đơn giản và chỉ yêu cầu ít công sức hơn so với các công việc khác, nó có thể được gán 1 Story Point. Một công việc phức tạp hơn có thể được gán 2 Story Points, và một công việc rất phức tạp hoặc chưa rõ ràng có thể được gán 8 Story Points.

Trong một nhóm, việc các thành viên đánh giá số lượng Story Point cần thiết cho cùng một công việc một cách khác nhau là điều thường xảy ra. Điều này không phải là một vấn đề lớn, miễn là mỗi người trong nhóm hiểu rõ về cách thức ước lượng và đánh giá Story Point.

Mục đích chính của việc ước lượng Story Point không phải là để đạt được một con số chính xác, mà là để đưa ra một ước lượng tương đối về độ khó và công sức cần thiết để hoàn thành công việc.

Nếu có sự khác biệt trong việc ước lượng Story Point, nhóm nên thảo luận để hiểu lý do tại sao mỗi người đánh giá khác nhau và cùng đưa ra quyết định cuối cùng. Việc này cũng giúp tăng khả năng hiểu biết và tương tác trong nhóm.

Theo kinh nghiệm dãy số Fibonanci 1, 2, 3, 5, 8, 13, 21, 40, 100… có thể được chia thành 2 nhóm như sau:

• 1, 2, 3, 5, 8, 13: Thể hiện team đã rõ ràng về cách làm, không phức tạp hoặc ít phức tạp, team quen thuộc với item…
• 21, 40, 100: Thể hiện item cần phải chia ra nhỏ hơn nữa, item với mức độ phức tạp cao, rủi ro, team mơ hồ chưa biết về item…

Cách planning sử dụng estimate storypoint bằng Planning Poker

Planning Poker là một kỹ thuật được sử dụng để ước lượng Story Point trong Scrum. Quy trình này đòi hỏi tất cả các thành viên của nhóm tham gia vào việc ước lượng. Mỗi người chọn một lá bài từ bộ poker (thường bao gồm các số từ dãy Fibonacci) tương ứng với số Story Point mà họ nghĩ rằng công việc đó sẽ mất. Sau khi mọi người đều chọn một lá bài, tất cả các lá bài sẽ được úp xuống & lật lên cùng lúc và người chọn số cao nhất và thấp nhất sẽ phải giải thích lý do cho lựa chọn của họ. Sau đó, nhóm sẽ thảo luận và quyết định chung số Story Point cuối cùng cho công việc đó.

Quy trình sử dụng Planning Poker được tiếp tục như sau:

Sau khi mọi người đã giải thích lý do cho số điểm mà họ chọn và thảo luận về các khía cạnh khác nhau của nhiệm vụ, một vòng mới của Planning Poker được bắt đầu. Mọi người chọn một lá bài mới, dựa trên thông tin đã được thảo luận và sau đó tiếp tục quá trình như trên.

Việc lặp lại quá trình này giúp đảm bảo rằng tất cả các thành viên trong nhóm đều hiểu rõ về công việc và đồng ý với ước lượng Story Point. Điều này cũng giúp cải thiện sự hiểu biết chung về dự án và công việc, tăng khả năng hợp tác và đồng lòng trong nhóm.

Một điểm quan trọng cần lưu ý là Planning Poker không nhằm mục đích đưa ra một con số chính xác cho Story Point. Thay vào đó, nó nhằm mục đích đưa ra một ước lượng tương đối về độ khó và công sức cần thiết để hoàn thành công việc. Điều này phản ánh tinh thần của Agile, là tập trung vào việc cung cấp giá trị thực tế cho khách hàng hơn là tuân thủ một số liệu cụ thể.

Các kỹ thuật estimate khác trong jira

Ngoài việc ước lượng bằng Planning Poker, còn có nhiều kỹ thuật ước lượng khác mà bạn có thể sử dụng.

T-Shirt Sizes

Phương pháp “T-Shirt Sizes” là một kỹ thuật ước lượng phổ biến khác sử dụng trong Jira. Thay vì sử dụng Story Points, nhóm sử dụng các kích thước áo phổ biến (XS, S, M, L, XL) để biểu thị độ phức tạp và công sức cần thiết để hoàn thành công việc. Phương pháp này đơn giản và dễ hiểu, nhưng không chính xác như Story Points.

Dot Voting

“Dot Voting” hoặc “Multi-voting” là một kỹ thuật ước lượng khác trong Jira. Mỗi thành viên trong nhóm được cấp một số lượng điểm để “bầu chọn” cho các công việc khác nhau. Công việc nhận được nhiều điểm nhất được ưu tiên cao nhất. Phương pháp này thường được sử dụng cho các quyết định dựa trên nhóm và đảm bảo rằng mọi người đều có tiếng nói.

Bucket System

Bucket System là một kỹ thuật ước lượng khác sử dụng trong Jira. Trong hệ thống này, mỗi “bucket” hoặc “giỏ” tượng trưng cho một lượng công việc nhất định. Mỗi giỏ được gán một số Story Point, và mỗi công việc sẽ được đặt vào một giỏ tương ứng với độ phức tạp và công sức làm việc. Bucket System giúp nhóm dễ dàng phân loại công việc và ước lượng tổng thể mà không cần phải tính toán từng công việc một cách chi tiết.

Affinity Estimating

Affinity Estimating là một phương pháp ước lượng nhanh chóng và hiệu quả, đặc biệt hữu ích khi cần ước lượng một lượng lớn công việc. Trong phương pháp này, mỗi công việc sẽ được viết ra trên một tờ giấy hoặc một card. Nhóm sẽ thảo luận về mỗi công việc và sau đó sắp xếp chúng trên một bảng theo mức độ phức tạp, từ thấp đến cao. Sau cùng, nhóm sẽ gán Story Point cho từng nhóm công việc dựa trên vị trí của chúng trên bảng. Affinity Estimating giúp nhóm có cái nhìn tổng quát về lượng công việc và ước lượng nhanh chóng.

Tìm hiểu Scrum framework và các khóa học trong Scrum

Story point là một kỹ thuật ước lượng trong Agile và cụ thể là Scrum framework. Nếu bạn có nhu cầu tìm hiểu về Scrum framework, bạn có thể tham khảo các khóa học & ôn thi của chứng chỉ này.

Khóa học tại ScrumPass cung cấp cho bạn bộ đề thi trực tuyến cho các chứng chỉ Scrum như PSPO,PSM… cho phép bạn ôn tập và chuẩn bị một cách toàn diện. Bạn sẽ có cơ hội làm quen với cấu trúc và loại câu hỏi bạn sẽ gặp trong bài thi thực tế. Điều này giúp bạn tự tin hơn khi đối mặt với kỳ thi chứng chỉ.

Không chỉ vậy, ScrumPass còn cung cấp hướng dẫn và tài liệu ôn tập chi tiết, giúp bạn hiểu rõ hơn về các khái niệm và quy tắc quan trọng của Scrum và các vai trò trong Scrum. Bạn sẽ được học cách áp dụng Scrum trong thực tế và làm việc với các tình huống phức tạp.

Với công cụ luyện đề thi tại ScrumPass, bạn có thể học tập theo lịch của riêng mình và ôn tập mọi lúc, mọi nơi. Điều này giúp bạn tận dụng thời gian một cách hiệu quả và nhanh chóng.

Hãy bắt đầu hành trình của bạn và đạt được những mục tiêu mới với khóa học tại ScrumPass. Chúng tôi tin rằng bạn có khả năng làm được điều này trong vòng 2-4 tuần.
Nếu cần thêm thông tin, xin đừng ngại ngần liên hệ chúng tôi tại:
Fanpage: https://www.facebook.com/scrumpassvn
Group cộng đồng học tập:https://www.facebook.com/groups/270691597973187
Trang chủ Scrumpass: https://scrumpass.com/