Story points – Công cụ ước lượng của Agile

Như đã chia sẻ trong bài viết “User stories – Công cụ lên kế hoạch của Agile”, chúng ta đã đề cập đến User stories – một trong những công cụ được các nhóm Agile sử dụng để lập kế hoạch làm 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ả. Tiếp tục với chuỗi những công cụ, kỹ thuật này, chúng ta sẽ cùng tìm hiểu công cụ thứ 2 không kém phần quan trọng đó chính là Story Points.

Theo tự nhiên thì chúng ta khó có thể đưa ra các ước lượng tuyệt đối một cách chính xác, nhưng sẽ dễ dàng và thoải mái hơn trong việc đưa ra các ước lượng bằng cách so sánh với một yếu tố khác (ước lượng tương đối). Các nhóm Agile cũng vậy, họ đề cao việc ước lượng tương đối. Họ thực hiện hầu hết các ước lượng của họ không phải theo giờ/ngày/tuần, mà bằng một đơn vị tương đối được gọi là “Story points“.

Một lý do khác để sử dụng ước lượng tương đối đó là mỗi thành viên trong nhóm làm việc ở tốc độ khác nhau. Ví dụ một user story có ước lượng là 3 points (3 điểm) có thể được hoàn thành bởi một nhân viên có kinh nghiệm trong một buổi sáng nhưng một nhân viên mới có thể phải mất suốt một ngày mới hoàn thành. Nên story point chỉ tập trung vào ước lượng độ lớn, độ phức tạp của story.

Story points 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 points 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 item) hoặc bất kỳ phần công việc nào khác.

Ước lượng bằng story points, một loại ước lượng tương đối, thường được thực hiện tại cuộc thảo luận về Product Backlog.

Khi lập kế hoạch cho một dự án Agile, thường thì nhóm sẽ không thể dự đoán được các tính năng của sản phẩm/phần mềm sẽ thực hiện trong bao lâu hoặc ngày hoàn thành chính xác của chúng. Khi ước tính theo giờ/ngày/tuần, bạn phải đưa ra cam kết thời gian chính xác. Thay vào đó, khi sử dụng story point, nhóm chỉ định một giá trị điểm (point) cho mỗi story dựa trên độ lớn của nó. Đó là lý do tại sao hầu hết nhóm Scrum sử dụng story points để lập kế hoạch dự án của họ, cho phép họ so sánh các stories với nhau. Bằng cách tập trung vào độ phức tạp của các 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à đưa ra 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/sản phẩm sau mỗi vòng lặp.

(Khoá đào tạo thực hành Quản lý dự án theo mô hình 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 story và gán số đó cho mỗi user story trong backlog. Thay vì cố gắng dự đoán chính xác sẽ mất bao lâu để xây dựng một tính năng, nhóm chỉ định một giá trị điểm cho mỗi story dựa trên độ phức tạp của nó, sau khi đem đi 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ừ story này sang story khác, nhưng sau một thời gian nhóm đã quen với quy mô mà nhóm sử dụng để ước lượng thì sẽ dễ dàng hơn để tìm ra độ lớn của mỗi story.

Khi chúng ta ước lượng bằng story points, chúng ta sẽ chỉ định một giá trị điểm cho mỗi mục. Các giá trị thô mà các nhóm sử dụng là không quan trọng. Điều quan trọng là các giá trị đó phải có quan hệ tương đối với nhau. Ví dụ như story được gán điểm 2 nên lớn gấp đôi story được gán điểm 1. Nó cũng phải bằng 2/3 story được ước lượng là 3 story points. Thay vì chỉ định 1, 2 và 3, nhóm đó có thể chỉ định 100, 200 và 300. Hoặc 1 triệu, 2 triệu và 3 triệu. Điều 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ộ khi thực hiện 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 theo từng nhóm sẽ 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:

• Scrum teams có thể dựa vào ý tưởng chia theo T-shirt sizes để xác định độ lớn, độ phức tạp của một story và gắn giá trị điểm cho từng size. T-shirt sizes là một công cụ ước lượng ở high-level – mức độ tổng quát, được sử dụng để thực hiện các ước lượng ban đầu về các tính năng sản phẩm và user story trong giai đoạn bắt đầu của một dự án, khi mà 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 của chúng ta sẽ là T-shirt sizes, từ Cực nhỏ – Extra Small (ES) đến Cực lớn – Extra Large (XXL).
• Chúng ta sẽ không cố gắng ước lượng kích thước tuyệt đối của từng danh mục hoặc thậm chí kích thước lớn hơn hay nhỏ hơn bao nhiêu so với các kích thước khác. Tất cả những gì chúng ta biết sẽ là Extra Small nhỏ hơn Small, nhỏ hơn Medium và tiếp tục như thế.
• 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).

• Ngoài ra cũng không ít các nhóm cũng 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.
• 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ì họ 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 story, độ lớn của một story này so với một story khác. Miễn là nhóm của bạn sử dụng thang đo một cách nhất quán, thì đó không phải là vấn đề khi nhóm sử dụng.

Bất cứ điều gì chưa được thực hiện trong Sprint sẽ được chuyển từ Sprint này sang Sprint tiếp theo. Và tổng số story point được hoàn thành trong mỗi Sprint được theo dõi như Velocity (vận tốc – chúng ta sẽ tìm hiểu cụ thể hơn về khái niệm này ở những bài tiếp theo) của dự án. Nếu một nhóm hoàn thành 15 story với tổng số 55 story points trong một Sprint, họ sẽ cho rằng 55 story points này như Sprint velocity và điều này cho nhóm một cái nhìn chung về tốc độ thực hiện công việc của cả nhóm, dự đoán về tổng số story points họ có thể làm trong Sprint tiếp theo.

Theo thời gian, nhóm ngày càng tốt hơn trong việc gán story points và ngày càng nhất quán hơn về số story points họ hoàn thành trong mỗi Sprint. Bằng cách đó, nhóm sẽ cảm nhận được họ có thể làm được bao nhiêu trong Sprint và kiểm soát kế hoạch cùng nhau.

Để tìm được base story, chúng ta cần tìm một user story cơ bản, ứng với tiêu chuẩn về định nghĩa hoàn thành rõ ràng – DoD, và gán cho nó một story point. Base story được dùng làm cơ sở khi so sánh các story khác.

Nhóm sẽ thực hiện ước lượng story points như đã trình bày ở trên (mục 3). Tiếp theo, nhóm sẽ tạo một ma trận với mỗi hàng cho mỗi story point (ví dụ ở dưới sử dụng dãy số Fibonacci) và stories liên quan của chúng. Sau đó, nhóm tập hợp tất cả stories và bắt đầu phân loại chúng thành các hàng, so sánh các story với nhau và với các story đã hoàn thành khác, hoặc so với base story. Lưu ý rằng base story đã có trong ma trận này, ở hàng đầu tiên với giá trị là một story point.

Để chỉ định story point cho mỗi story, nhóm có một cuộc họp, nơi tất cả các thành viên của development team sẽ sử dụng Planning Poker để đưa ra con số story point cho một story.

là một kỹ thuật ước lượng dựa trên sự đồng thuận, dùng để ước lượng cho Product Backlog. Nó có thể được sử dụng với nhiều đơn vị ước lượng khác nhau, nhưng ở đây chúng ta ví dụ Planning Poker với Story points.

• Mỗi thành viên nhận được một bộ thẻ bài.
• Tất cả các thành viên chọn Backlog items để ước lượng, thảo luận các tính năng và đặt câu hỏi.
• Khi một tính năng đã được thảo luận đầy đủ, mỗi người tự đưa ra con số ước lượng cho riêng mình – đảm bảo bí mật, và chọn một thẻ bài để đại diện cho ước lượng của mình.
• Khi tất cả đã có cho mình ước lượng của story, họ sẽ tiết lộ thẻ bài của họ cùng một lúc. Nếu tất cả các ước lượng đều khớp, cả nhóm sẽ chọn Backlog item khác và lặp lại quy trình tương tự. Khi các ước lượng khác nhau quá nhiều, tất cả sẽ thảo luận về vấn đề này để đi đến thống nhất.

Vào cuối Planning Poker, nhóm sẽ điền toàn bộ kết quả có được vào ma trận. Các user story của nhóm được chia thành các hàng theo story point tương ứng cần thiết để thực hiện chúng. Có thể có nhiều story trong một hàng.

Tại thời điểm này, nhóm đã có ước lượng về độ lớn dựa theo story points, câu hỏi đặt ra là làm thế nào để nhóm có thể chuyển đổi những story points này thành ước lượng thời gian thực tế (giờ/ngày/tuần). Rất tiếc, nhóm không thể thực hiện việc này cho đến khi hoàn thành Sprint đầu tiên. Trong khi Sprint đầu tiên đang diễn ra, nhóm có thể theo dõi Velocity của nhóm. Ngay sau khi Sprint kết thúc, sẽ biết nhóm có thể hoàn thành bao nhiêu story points cho mỗi Sprint. Nhóm sử dụng những con số này để dự báo khả năng của mình cho những Sprint tiếp theo.

Khi ước lượng được tất cả các công việc trong backlog dựa vào story point, Scrum có thể hiểu nhóm sẽ cần bao nhiêu Sprint để hoàn thành dự án. Và cuối cùng, nhóm có thể chuyển đổi các đơn vị trừu tượng này thành các mốc thời gian thực.

• Chuyển đổi story point sang giờ: Bằng cách chuyển đổi story point sang giờ/ngày/tuần, nhóm sẽ bắt đầu làm việc và phải mạo hiểm đưa ra cam kết thời gian hoàn thành chính xác. Giả sử story point được ước lượng có phạm vi thời gian từ 10 – 20 giờ, nhưng khi ước lượng theo giờ, nhóm phải đưa ra một con số chính xác như 15 giờ, từ đó sẽ dẫn đến sự sai lệch, dẫn đến khó đạt được cam kết hơn khi bạn làm việc theo giờ chính xác.
• Trong Planning Poker, một nửa thành viên trong nhóm ước lượng một product backlog item là 3 story point và nửa còn lại ước tính 5 story point. Nhóm giải quyết bằng cách đặt 4 story point làm con số ước lượng. Nhóm không nên làm điều này vì nhóm đang thỏa hiệp với sự cung cấp sai về độ chính xác. Tốt nhất là nhóm nên có một cuộc thảo luận để hiểu rõ hơn thay vì lấy giá trị trung bình.
• Điều chỉnh ước Khi nhóm bắt đầu giải quyết một vấn đề, nhóm không nên điều chỉnh ước lượng story point ngay cả khi ước lượng của họ không chính xác. Việc ước lượng đôi khi bị sai lệch là điều bình thường, nên nhóm không nên điều chỉnh mà hãy lưu lại thông tin này, để làm cơ sở cho việc xác định story point ở những lần sau chính xác hơn.
• Ước Khi chuyển một product backlog item chưa hoàn thành sang Sprint tiếp theo, không cần thiết phải ước lượng lại. Ước lượng có thể không chính xác, nhưng đó không phải là vấn đề. Nhờ Sprint Planning, nhóm sẽ biết tất cả các nhiệm vụ (task) cần thiết để hoàn thành user story. Ước lượng của các nhiệm vụ này là theo giờ. Vì vậy, Sprint tiếp theo, nhóm sẽ biết cần bao nhiêu thời gian để hoàn thành product backlog item này.
• Điều chỉnh ước User story có thể là 3 story point đối với thành viên nhiều kinh nghiệm, nhưng 8 story point đối với thành viên mới. Đây là cách làm không đúng. Chúng ta không nên điều chỉnh story point vì một người cụ thể sẽ thực hiện công việc. Vì story point chỉ dựa vào độ lớn, độ phức tạp, độ khó của user story.
• Tuân theo ý kiến của các chuyên gia trong nhóm: Khi thực hiện Planning Poker, có rủi ro là nhóm sẽ tuân theo ý kiến của các chuyên gia mà không phải là sự kết hợp từ phía mỗi thành viên. Nhóm thường giải quyết công việc bằng cách để chuyên gia trình bày chi tiết về công việc. Sau đó, để phần còn lại của nhóm ước lượng mà không cần các chuyên gia. Chúng ta cần nhớ rằng ước lượng story point là sự nỗ lực của cả nhóm không phải của riêng bất kỳ thành viên nào.
• Không thảo luận lại các vấn đề không chính xác về việc ước Thỉnh thoảng, nhóm xác định được những vấn đề rõ ràng là ước lượng story points đã hoàn toàn sai lệch. Điều quan trọng là phải thảo luận về những vấn đề này và cố gắng học hỏi, cải thiện, để những ước lượng trong tương lai chính xác hơn.

Khái niệm về story point đơn giản nhưng khó áp dụng. Hầu hết mọi nhóm Scrum đều sử dụng chúng, nhưng chúng không phải là một phần các công cụ cốt lõi của Scrum. Bởi vì điều này, mọi người có ý kiến ​​khác nhau về cách bạn nên sử dụng chúng. Ban đầu khi sử dụng story points có thể sẽ làm nhóm ước lượng sai lệch, nhưng sau thời gian hiểu và kiểm soát kế hoạch cùng nhau, nhất quán hơn về số điểm họ cung cấp trong mỗi Sprint giúp nhóm thuần thục hơn và làm cho công việc ước lượng trở nên nhẹ nhàng, dễ dàng hơn rất nhiều.

Kiến thức tổng hợp bởi Masterskills (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 – The Scrum Guide

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ả