Scrum là một kỹ thuật quản lý dự án linh hoạt, giúp tối ưu hóa hiệu suất và độ linh hoạt trong quá trình phát triển sản phẩm. Trong môi trường phát triển phần mềm, việc đưa ra ước lượng chính xác về thời gian cần thiết để hoàn thành một công việc là một thách thức lớn. Thay đổi yêu cầu liên tục và sự đa dạng trong cơ cấu đội nhóm khiến cho việc xác định thời gian một cách tuyệt đối trở nên khó khăn. Để giải quyết vấn đề này, phương pháp Agile đã đưa ra một hướng tiếp cận mới, chú trọng vào việc so sánh và ước lượng tương đối, không dựa hoàn toàn vào thời gian.

Pixta item: 88182670

Trong môi trường Agile, đội dự án thường không ước lượng công việc của họ dựa trên đơn vị thời gian như giờ, ngày hay tuần bởi mỗi thành viên sẽ có tốc độ làm việc riêng, phù hợp với vị trí và level của họ. Thay vào đó, họ sử dụng một đơn vị tương đối được gọi là “Story Point”. Sự chuyển đổi từ ước lượng tuyệt đối sang ước lượng tương đối là một bước quan trọng để làm cho quá trình dự án linh hoạt và dễ dàng hơn. 

Vậy story point là gì? 

Story point là một thuật ngữ được sử dụng trong quản lý và phát triển dự án để ước lượng độ lớn, độ khó, độ phức tạp cho công việc triển khai một user story nhất định, là một thước đo trừu tượng về nỗ lực cần thiết để thực hiện nó. Nói một cách dễ hiểu, story point là một con số, một đơn vị đo lường cho cả nhóm biết về độ khó của story, khó khăn có thể liên quan đến khối lượng công việc phải làm, mức độ phức tạp của công việc, rủi ro hoặc sự không chắc chắn của công việc để thực hiện đầy đủ một hạng mục trong Product Backlog (backlog ticket) hoặc bất kỳ phần công việc nào khác.

Các Giá Trị của Story Point trong Phương Pháp Agile:

• Ước Lượng Tương Đối: Story point giúp chuyển từ ước lượng tuyệt đối (dựa vào thời gian) sang ước lượng tương đối, tập trung vào so sánh độ phức tạp và quy mô của các công việc thay vì chú trọng vào thời gian cụ thể. Điều này tạo ra sự thoải mái và linh hoạt trong quá trình đánh giá và dự đoán công việc.
• Đánh Giá Tương Đối và So Sánh Công Việc: Story point tạo ra khả năng đánh giá tương đối giữa các công việc trong dự án. Nhờ vào sự tương đối này, đội dự án có thể dễ dàng so sánh độ lớn và độ phức tạp của các công việc mà không phụ thuộc hoàn toàn vào số liệu thời gian.
• Tính Linh Hoạt và Dễ Quản Lý: Nhóm Scrum có thể linh hoạt điều chỉnh và đánh giá lại story points dựa trên những yêu cầu thay đổi hay độ phức tạp của công việc, giúp tối ưu hóa kế hoạch và quản lý tài nguyên.
• Ưu Tiên Công Việc Dựa Trên Độ Phức Tạp: Sự tập trung vào độ phức tạp và quy mô của công việc thay vì thời gian giúp đội dự án ưu tiên công việc dựa trên độ quan trọng và phức tạp thực sự. Điều này hỗ trợ quá trình lập kế hoạch và phân chia công việc một cách thông minh.
• Tạo Không Gian Giao Tiếp Trong Team: Quá trình ước lượng story points thường đi kèm với sự thảo luận sâu rộng giữa các thành viên trong team. Điều này tạo ra sự hiểu biết chi tiết và chia sẻ thông tin, giúp đội dự án đồng thuận về mức độ phức tạp của công việc.

Làm thế nào để ước tính được story point? 

Một trong những đặc điểm quan trọng nhất của Story point đó là tính tương đối giữa các con số. Tuỳ vào đặc điểm, tình hình của team Scrum mà quyết định sử dụng thang đo khác nhau. Trong Pixta Việt Nam, các team scrum sử dụng chuỗi Fibonacci làm thang đo Story point với các con số như 1, 2, 3, 5, 8, 13… Về cơ bản, thang đo Fibonacci Agile cung cấp cho team một cách thực tế hơn để tiếp cận các ước tính bằng cách sử dụng story points. Mỗi story point được gán một số từ thang Fibonacci. Con số càng cao, story càng phức tạp và lượng nỗ lực cần thiết để hoàn thành càng lớn. Team có thể dễ dàng nhận ra sự khác biệt và xác định mức độ phức tạp của từng story points. Nó giúp team thực tế hơn khi xem xét các nhiệm vụ lớn hơn, phức tạp hơn.

Để ước lượng được chính xác số point, team cần xây dựng một quy trình ước tính story point riêng. 

Bước 1: Thiết lập base story point 

Base Story Points cung cấp một cơ sở đồng nhất và hiểu biết chung về cách team đánh giá độ phức tạp của công việc, giúp đảm bảo rằng tất cả các thành viên trong team có cùng một quan điểm về mức độ công việc và phức tạp của nó.

• Chọn 1 ticket dễ xử lý, requirement đơn giản (thời gian xử lý từ 30 phút đến 0,5 ngày) như yêu cầu thay text làm 1 point 
• 2 point: sẽ có độ khó, phức tạp hay rủi ro gấp đôi 1 point 
• 3 point: sẽ có độ khó, phức tạp hay rủi ro gấp ba 1 point, thời gian xử lý sẽ kéo dài khoảng 2~3 ngày  
• Tiếp tục đến con số 13: đây sẽ làm số point lớn nhất, độ rủi ro và khó cao (sẽ mất nguyên 1 sprint để xử lý) 

Vào thời điểm sơ khai của team, việc sử dụng story point thường sẽ không được chính xác bởi chưa có cơ sở để ước lượng. Chính vì vậy, team cần monitor quá trình ước lượng và sẽ improve sau khoảng vài sprint khi team đã đi vào hoạt động quy củ. 

Bước 2: Planning Poker – quy trình ước lượng 

• Phân Phối Thẻ Bài: Mỗi thành viên nhận một bộ thẻ bài có các con số (1, 2, 3, 5, 8, 13) đại diện cho các story point.
• Chọn ticket và Thảo Luận: Đội chọn các ticket để ước lượng. Thảo luận về tính năng, đặt câu hỏi để đảm bảo hiểu rõ công việc.
• Ước Lượng Cá Nhân: Mỗi thành viên tự đưa ra con số ước lượng và chọn một thẻ bài để đại diện cho ước lượng của mình – đảm bảo tính bí mật.
• Tiết Lộ Ước Lượng: Mọi thành viên cùng tiết lộ thẻ bài của mình cùng một lúc. Nếu các ước lượng khớp nhau, đội chọn ticket khác và lặp lại quy trình.
• Xử Lý Sự Khác Biệt: Nếu các ước lượng khác nhau quá nhiều, đội thảo luận để đạt đến sự thống nhất. Mục tiêu là hiểu rõ hơn về công việc và đồng thuận về ước lượng.

Planning Poker giúp tạo ra sự đồng thuận tự nhiên thông qua sự thảo luận và tiết lộ đồng thời, đảm bảo tính công bằng về năng lực với tất cả các thành viên. Tuy nhiên, trong quá trình sử dụng story point, team scrum cũng phải đối mặt nhiều thách thức: 

• Sự đồng thuận trong việc hiểu và ước lượng story points đòi hỏi sự hiểu biết chung và thống nhất giữa các thành viên trong đội. Nếu mỗi thành viên có hiểu biết khác nhau về ý nghĩa của story points, có thể dẫn đến ước lượng không chính xác. Quá trình sử dụng story points đôi khi đòi hỏi sự tương tác và thảo luận chi tiết về từng công việc. Điều này có thể làm tăng thời gian và công sức yêu cầu cho quá trình ước lượng, đặc biệt là trong các dự án lớn với nhiều công việc phức tạp.
• Story points không phải là một đơn vị đo lường cụ thể và có thể tạo ra nguy cơ ước lượng không chính xác nếu đội không đồng thuận về ý nghĩa của chúng. Sự chênh lệch giữa các ước lượng của các thành viên có thể dẫn đến dự đoán không chính xác về thời gian cần thiết để hoàn thành công việc. Ngoài ra, đảm bảo sự thống nhất trong việc ước lượng story points cũng trở nên khó khăn hơn khi có sự thay đổi về nhân sự hoặc quy trình làm việc. Điều này có thể làm ảnh hưởng đến khả năng so sánh giữa các Sprint.
• Story points thường tập trung vào độ phức tạp và quy mô, nhưng đôi khi có thể đánh giá độ ưu tiên của công việc một cách không rõ ràng. Điều này có thể dẫn đến việc đội không ưu tiên đúng mức công việc quan trọng và khẩn cấp.
• Các team thường có xu hướng đưa ra story point trung bình cho những trường hợp có sự ước lượng khác nhau. Điều này dẫn đến những con số không chính xác, và có khúc mắc cho các thành viên. Lúc này, team cần thảo luận và đạt được sự đồng thuận để loại bỏ mọi rào cản. 
• Không monitor lại quy trình là nguyên nhân chính dẫn đến việc ước lượng sai. Theo thời gian, team sẽ có những thay đổi về mức độ hiểu biết, kinh nghiệm xử lý,… điều này cần được thống nhất lại và tinh chỉnh story point theo khả năng thực tế của team. 

Kết Luận

Story Point không chỉ là một đơn vị đo lường, mà là một chiến lược quản lý dự án, giúp tối ưu hóa ước lượng và quản lý công việc trong mô hình Scrum. Bằng cách hiểu rõ khái niệm và quy trình ước lượng, chúng ta có thể tận dụng Story Point một cách tối ưu, đồng thời vượt qua những thách thức để mang lại giá trị cao nhất cho dự án phát triển phần mềm.

Trong quá trình làm việc, team bạn đã đối mặt với những thách thức nào, hãy chia sẻ và cùng nhau thảo luận nhé! 

Tác giả: Đinh Thị Thu Hồng