Trong bài viết về User Stories, chúng ta đã biết đến một công cụ lập kế hoạch hiệu quả trong Agile. Tiếp nối chủ đề này, bài viết này sẽ giới thiệu Story Points, một công cụ quan trọng khác giúp các nhóm Agile ước lượng và quản lý công việc hiệu quả hơn.
Trong thực tế, việc đưa ra các ước lượng chính xác tuyệt đối là rất khó. Tuy nhiên, chúng ta sẽ dễ dàng hơn khi ướ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 và sử dụng Story Points thay vì ước lượng thời gian cụ thể (giờ/ngày/tuần).
Một lý do khác là mỗi thành viên trong nhóm có tốc độ làm việc khác nhau. Ví dụ, một User Story được ước lượng là 3 points 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ể mất cả ngày. Do đó, Story Point tập trung vào độ lớn và độ phức tạp của Story, không phải thời gian thực hiện.
Mục Lục
Story Points Là Gì?
Story Points là một đơn vị đo lường trừu tượng được sử dụng trong quản lý dự án Agile để ước lượng độ lớn, độ khó và độ phức tạp của một User Story. Nó cho biết nỗ lực cần thiết để hoàn thành công việc.
Nói một cách đơn giản, Story Points là một con số thể hiện độ khó của Story, bao gồm:
- Khối lượng công việc
- Mức độ phức tạp
- Rủi ro
- Sự không chắc chắn
Việc ước lượng bằng Story Points (ước lượng tương đối) thường được thực hiện trong cuộc họp Product Backlog Refinement.
Story points – Công cụ ước lượng của Agile – Atoha
Tại Sao Nên Sử Dụng Story Points?
Khi lập kế hoạch dự án Agile, nhóm thường khó dự đoán chính xác thời gian hoàn thành các tính năng. Ước tính theo giờ/ngày/tuần đòi hỏi cam kết thời gian cụ thể. Thay vào đó, Story Points cho phép nhóm gán một giá trị điểm cho mỗi Story dựa trên độ lớn của nó. Điều này cho phép so sánh các Stories với nhau.
Bằng cách tập trung vào độ phức tạp thay vì thời gian, nhóm có thể cùng nhau lập kế hoạch và dự đoán số lượng tính năng có thể được thêm vào sản phẩm sau mỗi vòng lặp.
Làm Thế Nào Để Ước Lượng Story Point Trong Agile?
Nhóm sẽ chọn một số điểm đại diện cho độ lớn, độ khó, độ phức tạp và khối lượng công việc cần thiết cho mỗi Story và gán số đó cho User Story trong Backlog. Thay vì dự đoán chính xác thời gian xây dựng một tính năng, nhóm chỉ định một giá trị điểm dựa trên độ phức tạp so với các tính năng khác đã xây dựng trước đó.
Ban đầu, ước lượng có thể khác nhau giữa các Stories, nhưng sau một thời gian, nhóm sẽ quen với quy mô và dễ dàng xác định độ lớn của mỗi Story hơn.
Khi ước lượng bằng Story Points, giá trị thô không quan trọng, quan trọng là mối quan hệ tương đối giữa chúng. Ví dụ, Story được gán điểm 2 nên lớn gấp đôi Story được gán điểm 1, và bằng 2/3 Story được ước lượng là 3. Thay vì 1, 2, 3, nhóm có thể dùng 100, 200, 300 hoặc 1 triệu, 2 triệu, 3 triệu. Điều quan trọng là tỷ lệ, không phải con số thực tế.
Trong Scrum, Product Owner và Development Team sẽ đưa ra ước lượng sơ bộ khi thực hiện Product Backlog Refinement trước Sprint Planning để:
- Đảm bảo sẵn sàng cho Sprint Plan hiệu quả.
- Đảm bảo đủ thông tin để hoàn thành công việc.
- Đảm bảo User Story đã được chia nhỏ hợp lý.
Có nhiều cách để ước tính Story Points trong Agile. Tùy theo từng nhóm, sẽ có sự thống nhất 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:
Định cỡ theo T-shirt size (size áo):
Các Scrum team 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 ở 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 (XS) đế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).
Extra Small
Small
Medium
Large
Extra Large
1 điểm
2 điểm
3 điểm
4 điểm
5 điểm
Lũy thừa của 2: Một số nhóm sử dụng dãy số 1, 2, 4, 8, 16 (lũy thừa của 2) để ước lượng Story Point.
Chuỗi Fibonacci cho Story Point:
Một số nhóm sử dụng chuỗi Fibonacci hoặc 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 so với Story khác. Quan trọng là nhóm sử dụng thang đo một cách nhất quán.
Story points – Công cụ ước lượng của Agile – Atoha
Bất cứ điều gì chưa được thực hiện trong Sprint sẽ được chuyển sang Sprint tiếp theo. Tổng số Story Point được hoàn thành trong mỗi Sprint được theo dõi như Velocity (vận tốc). Nếu một nhóm hoàn thành 15 Story với tổng số 55 Story Point trong một Sprint, họ sẽ coi 55 Story Point này là Sprint Velocity. Điều này cho nhóm cái nhìn tổng quan về tốc độ thực hiện công việc và dự đoán số lượng Story Point có thể làm trong Sprint tiếp theo.
Theo thời gian, nhóm sẽ ngày càng tốt hơn trong việc gán Story Point và nhất quán hơn về số Story Point hoàn thành trong mỗi Sprint. Bằng cách đó, nhóm sẽ cảm nhận được khả năng của mình trong Sprint và kiểm soát kế hoạch cùng nhau.
Quy Trình Ước Lượng Story Points
Bước 1: Xác định Story cơ sở – Base Story
Để tìm được Base Story, cần 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ở so sánh các Story khác.
Bước 2: Tạo ma trận để ước lượng
Nhóm sẽ thực hiện ước lượng Story Point như đã trình bày ở trên. 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ụ sử dụng dãy số Fibonacci) và các Stories liên quan. Sau đó, nhóm tập hợp tất cả Stories và bắt đầu phân loại chúng vào các hàng, so sánh với nhau, với các Story đã hoàn thành 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.
Story Point
Story
1
Với tư cách là khách truy cập vào trang web, tôi muốn truy cập trang giới thiệu để biết thêm về các dịch vụ.
2
3
5
8
Để chỉ định Story Point cho mỗi Story, nhóm sẽ 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.
Planning Poker 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.
Bước 3: Quy trình ước lượng Planning Poker
- 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ó ước lượng của Story, họ sẽ tiết lộ thẻ bài của mình 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.
Story Point
Story
1
Với tư cách là người truy cập vào trang web, tôi muốn truy cập trang giới thiệu để biết thêm về các dịch vụ.
Với tư cách là người truy cập vào trang web, tôi muốn có thể đặt lại mật khẩu của mình trong trường hợp tôi quên mật khẩu.
2
Với tư cách là người dùng đã đăng nhập, tôi muốn có thể xem lịch sử thanh toán của mình trên trang cài đặt.
Với tư cách là người truy cập trang web, tôi muốn có thể gửi phản hồi hoặc báo cáo sự cố bằng cách sử dụng biểu mẫu liên hệ.
3
Với tư cách là người truy cập trang web, tôi muốn đăng nhập / đăng ký bằng email / mật khẩu của mình.
Với tư cách là người dùng đã đăng nhập, tôi muốn thêm nhận xét vào nội dung trên trang web.
5
Với tư cách là người truy cập vào trang web, tôi muốn sử dụng biểu mẫu tìm kiếm với các bộ lọc để tìm kiếm nội dung cụ thể.
Với tư cách là người truy cập vào trang web, tôi muốn xem thông tin chi tiết về nội dung.
8
Với tư cách là người dùng đã đăng nhập, tôi muốn có thể thêm nội dung trên tiêu đề trang web, mô tả, nội dung phương tiện (hình ảnh, video, âm thanh), vị trí địa lý.
Với tư cách là người dùng đã đăng nhập, tôi muốn có thể giao tiếp qua tin nhắn với những người dùng khác.
Bước 4: Sprint Planning
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 Points, 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.
Những Lỗi Thường Mắc Phải Khi Sử Dụng Story Point
- 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.
- Đưa ra Story Point trung bình: 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 lượng Story Point của các User Story trong Sprint: 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 lượng Story Point cho những vấn đề chưa hoàn thành một lần nữa: 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 lượng Story Point dựa vào người làm: 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 lượng Story Point trong Sprint Retrospective: 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.
Tổng Kết
Story Points là một công cụ mạnh mẽ giúp các nhóm Agile ước lượng và quản lý công việc hiệu quả hơn. Mặc dù khái niệm này đơn giản, nhưng việc áp dụng nó có thể gặp nhiều thách thức.
Ban đầu, việc sử dụng Story Points có thể dẫn đến ước lượng sai lệch, nhưng theo thời gian, nhóm sẽ hiểu rõ hơn về khả năng của mình và trở nên nhất quán hơn trong việc gán điểm. Điều này giúp nhóm kiểm soát kế hoạch và làm cho công việc ướ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, sentayho.com.vnge
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ả