Như đã đề cập trong bài viết “User stories – Công cụ lên kế hoạch của Agile”, chúng ta đã tìm hiểu về User Stories – một công cụ quan trọng dùng để lập kế hoạch công việc và thể hiện các hạng mục cần thực hiện một cách hiệu quả trong nhóm Agile. Tiếp theo trong chuỗi các công cụ và kỹ thuật này, chúng ta sẽ tìm hiểu công cụ thứ hai không kém phần quan trọng đó là Story Points.
Story Points là gì?
Story Points là 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 của công việc triển khai một User Story nhất định. Nó là một thước đo trừu tượng về nỗ lực cần thiết để thực hiện một công việc. Đơn giản, Story Points là một con số, một đơn vị đo lường cho cả nhóm biết về độ khó của User Story, khối lượng công việc, mức độ phức tạp, rủi ro hoặc sự không chắc chắn có trong việc hoàn thành một hạng mục trong Product Backlog hoặc bất kỳ công việc nào khác.
Ứng dụng Story Points, một loại ước lượng tương đối, thường được tiến hành trong cuộc thảo luận về Product Backlog.
Tại sao nên sử dụng Story Points?
Khi lập kế hoạch cho một dự án Agile, thường nhóm không thể dự đoán chính xác thời gian hoàn thành của các tính năng hoặc phần mềm. Khi ước tính theo giờ, ngày, tuần, nhóm phải cam kết thời gian chính xác. Thay vào đó, khi sử dụng Story Points, nhóm chỉ cần gán một giá trị điểm (point) cho mỗi User Story dựa trên độ lớn của nó. Điều này là lý do hầu hết các nhóm Scrum sử dụng Story Points cho việc lập kế hoạch dự án, cho phép so sánh các User Stories với nhau. Bằng cách tập trung vào độ phức tạp của tính năng thay vì thời gian chính xác để phát triển chúng, nhóm tham gia lập kế hoạch cùng nhau và dự đoán các tính năng gia tăng nào có thể được thêm vào phần mềm hoặc sản phẩm sau mỗi vòng lặp.
(Xem thêm: Khoá đào tạo thực hành Quản lý dự án theo mô hình Agile)
Làm thế nào để ước lượng Story Points trong Agile?
Story Points rất đơn giản: nhóm chỉ cần chọn một số điểm thể hiện độ lớn, độ khó, độ phức tạp, khối lượng công việc cần thiết cho mỗi User Story và gán số đó cho mỗi User Story trong backlog. Thay vì cố gắng dự đoán chính xác thời gian để xây dựng một tính năng, nhóm chỉ đặt một giá trị điểm cho mỗi User Story dựa trên độ phức tạp của nó, sau đó so sánh với các tính năng khác mà nhóm đã xây dựng trước đó. Ban đầu, các ước lượng sẽ thay đổi rất nhiều từ User Story này sang User Story khác, nhưng sau một thời gian nhóm sẽ quen với quy mô ước lượng và dễ dàng hơn để xác định độ lớn của mỗi User Story.
Khi ước lượng bằng Story Points, nhóm sẽ chỉ định một giá trị điểm cho mỗi mục. Các giá trị số mà các nhóm sử dụng là không quan trọng. Quan trọng là các giá trị đó phải có quan hệ tương đối với nhau. Ví dụ, một User Story được gán 2 điểm nên lớn gấp đôi User Story được gán 1 điểm. Nó cũng phải bằng 2/3 của User Story được ước lượng là 3 điểm. Thay vì chỉ định 1, 2 và 3, nhóm có thể chỉ định 100, 200 và 300. Quan trọng là tỷ lệ, không phải là con số thực sự về thời gian (giờ, ngày, tuần).
Trong Scrum, để thực hiện Sprint Planning hiệu quả hơn, Product Owner và Development Team sẽ đưa ra một ước lượng sơ bộ trong quá trình Product Backlog Refinement, trước khi diễn ra Sprint Planning và kiểm tra xem:
- Đã sẵn sàng để thực hiện Sprint Plan một cách hiệu quả chưa?
- Có đủ thông tin để hoàn thành những vấn đề này không?
- User Story đã được phân chia hợp lý chưa?
Có rất nhiều cách để ước tính Story Points trong Agile và tùy thuộc vào từng nhóm để thống nhất với nhau về cách tính. Trong hầu hết các trường hợp, Story Points sử dụng một trong số các thang đo sau để xác định kích thước:
1. Định cỡ theo T-shirt size (size áo):
-
Scrum teams có thể sử dụng cách chia theo T-shirt sizes để xác định độ lớn, độ phức tạp của một User Story và gắn giá trị điểm cho từng size. T-shirt sizes là một công cụ ước lượng ở mức tổng quát, được sử dụng để ước lượng ban đầu về các tính năng và User Story trong giai đoạn bắt đầu của một dự án, khi chưa có nhiều thông tin chi tiết.
-
Để phản ánh sự không chắc chắn liên quan đến những ước lượng đó, đơn vị ước lượng sẽ là T-shirt sizes, từ Extra Small (ES) – rất nhỏ, đến Extra Large (XXL) – rất lớn.
-
Ví dụ: nhóm có thể quyết định sử dụng 1 điểm cho tính năng rất nhỏ (Extra Small), 2 điểm cho tính năng nhỏ (Small), 3 điểm cho tính năng trung bình (Medium), 4 điểm cho tính năng lớn (Large) và 5 điểm cho tính năng rất lớn (Extra Large).
Extra Small Small Medium Large Extra Large 1 điểm 2 điểm 3 điểm 4 điểm 5 điểm
2. Lũy thừa của 2:
- Ngoài ra, cũng có những nhóm sử dụng dãy số 1, 2, 4, 8, 16 được tạo ra bằng cách lũy thừa của 2 để ước lượng Story Point.
3. Chuỗi Fibonacci cho Story Point:
- 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ì nghĩ rằng chuỗi Fibonacci cung cấp cái nhìn thực tế hơn về độ lớn của một User Story, độ lớn của một User Story này so với một User Story khác. Miễn là nhóm sử dụng thang đo một cách nhất quán, thì không quan trọng dùng chuỗi Fibonacci hay không.
Bất cứ công cụ nào được sử dụng để ước lượng Story Points, quan trọng nhất là nhóm phải thống nhất và quyết định ứng dụng cách tính nào. Các giá trị số có thể không quan trọng, quan trọng là tỷ lệ và mối quan hệ tương đối giữa các giá trị để ước lượng độ lớn, độ phức tạp của User Story.
Trên thực tế, nhóm không thể biết chính xác thời gian để xây dựng một tính năng từ các User Story được ước lượng. Thời gian cụ thể phụ thuộc vào rất nhiều yếu tố như kinh nghiệm, khả năng và tốc độ của từng thành viên trong nhóm. Thay vì dự đoán chính xác thời gian, nhóm tập trung vào ước lượng độ lớn, độ khó, độ phức tạp, khối lượng công việc và so sánh các User Story với nhau để lập kế hoạch cho dự án.
Những lỗi thường mắc phải khi sử dụng Story Point
Trong quá trình sử dụng Story Points, một số lỗi thường gặp phải bao gồm:
-
Chuyển đổi Story Points sang giờ: Khi chuyển đổi Story Points sang giờ, nhóm thường phải mạo hiểm đưa ra cam kết thời gian hoàn thành chính xác. Tuy nhiên, việc này có thể dẫn đến sai lệch và làm cho cam kết thời gian khó đạt được khi làm việc dựa trên giờ chính xác.
-
Đưa ra Story Point trung bình: Thay vì lấy giá trị trung bình, nhóm nên có cuộc thảo luận để hiểu rõ hơn về các User Story và không phải làm điều này để thỏa hiệp với sự cung cấp sai về độ chính xác.
-
Điều chỉnh ước lượng Story Point của User Story trong Sprint: Việc điều chỉnh ước lượng ngay cả khi không chính xác không được khuyến khích. Việc ước lượng đôi khi bị sai lệch là điều bình thường và nhóm nên lưu lại thông tin này để làm cơ sở cho việc ước lượng chính xác hơn trong tương lai.
-
Ước lượng Story Point cho User Story chưa hoàn thành một lần nữa: Khi chuyển User Story chưa hoàn thành sang Sprint tiếp theo, không cần thiết phải ước lượng lại. Việc này có thể không chính xác, nhưng không phải là vấn đề hàng đầu. Sprint Planning sẽ giúp nhóm xác định tất cả các nhiệm vụ cần thiết để hoàn thành User Story và ước lượng thời gian cần thiết trong Sprint tiếp theo.
-
Điều chỉnh ước lượng Story Point dựa vào người làm công việc: Việc điều chỉnh ước lượng dựa vào người làm công việc không đúng. Story Points chỉ dựa vào độ lớn, độ phức tạp, độ khó của User Story và không được ảnh hưởng bởi cá nhân thực hiện công việc.
-
Tuân theo ý kiến của các chuyên gia trong nhóm: Nhóm nên lắng nghe ý kiến của tất cả các thành viên và không chỉ tuân theo ý kiến của các chuyên gia. Ước lượng Story Point là một nỗ lực của cả nhóm, không chỉ của từng cá nhân.
-
Không thảo luận lại các vấn đề không chính xác về việc ước lượng Story Point trong Sprint Retrospective: Nhóm cần thảo luận về các vấn đề và cố gắng học hỏi, cải thiện để đạt được sự chính xác trong ước lượng trong tương lai.
Tổng kết
Story Points là một công cụ quan trọng trong Agile để ước lượng độ lớn, độ khó, độ phức tạp của các công việc triển khai User Stories. Sử dụng Story Points có thể giúp nhóm lập kế hoạch và dự đoán khả năng hoàn thành công việc trong mỗi Sprint. Mặc dù ban đầu có thể gặp khó khăn và sai lệch trong ước lượng, nhưng sau thời gian hiểu và làm việc cùng nhau, nhóm sẽ trở nên nhất quán hơn về số điểm ước lượng và làm cho quá trình ước lượng trở nên dễ dàng hơn.
Kiến thức tổng hợp bởi Trainer Nguyễn Hải Hà (PMP®, PMI-ATP Instructor)
References:
- PMI-ACP Exam Prep, Head First Agile, Visual-Paradigm, Moutaingoatsoftware, Medium, Ruby.garage
(Product Backlog là gì? Có quan hệ như thế nào với WBS
Bản tuyên ngôn Agile – lịch sử hình thành Agile
12 nguyên tắc của Agile
Trong dự án Agile, công việc ước tính có thật sự cần thiết?
Quản lý dự án với Scrum
Scrum of Scrums
User stories – Công cụ lên kế hoạch của Agile
Story points – Công cụ ước lượng của Agile
Velocity là gì – Công cụ đo lường tốc độ hoàn thành công việc của nhóm Agile
Story Map – Lập kế hoạch tổng quát trong Agile
Agile Retrospectives – Nhìn lại và cải tiến hiệu quả công việc dự án
Kanban – phương pháp giúp cải tiến quy trình làm việc của dự án
PDCA – Chu trình cải tiến liên tục
Personas – Công cụ xây dựng hình tượng khách hàng trong Agile
Lean – Tinh gọn hóa quy trình một cách hiệu quả
Hướng Dẫn Scrum 2020 – The Scrum Guide 2020
Bóng đá có 3-5-2, Scrum có 3-5-3
Bắt đầu với Scrum từ đâu đây ta?
Một số cách chạy Daily scrum hiệu quả)*
