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

Bạn Đang Xem: Viện Quản lý dự án ATOHA (Học Online, Offline, In-house)

Theo tự nhiên thì tất cả chúng ta rất khó có thể đưa ra các ước tính tuyệt đối một cách xác thực, nhưng sẽ dễ dàng và thoải mái hơn trong việc đưa ra các ước tính bằng phương pháp so sánh với một yếu tố khác (ước tính tương đối). Các nhóm Agile cũng vậy, họ đề cao việc ước tính tương đối. Họ thực hiện hồ hết các ước tính 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 tính tương đối đó là mỗi thành viên trong nhóm thao tác làm việc ở tốc độ khác nhau. Ví dụ một user story có ước tính là 3 points (3 điểm) có thể được hoàn thành bởi một viên chức có kinh nghiệm trong một buổi sáng nhưng một viên chức 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 tính độ lớn, độ phức tạp của story.

Story points là gì?

Story points là một thuật ngữ được sử dụng trong quản lý và phát triển dự án để ước tính độ 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ấp thiết để thực hiện nó. Nói một cách dễ hiểu, story points là một số lượng, một đơn vị đo lường và thống kê cho tất 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 kiên cố 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 tính bằng story points, một loại ước tính tương đối, thường được thực ngày nay cuộc thảo luận về Product Backlog.

Vì sao nên sử dụng story points?

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

(Xem thêm: Khoá tập huấn thực hiện Quản lý dự án theo mô hình Agile)

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

Story points rất đơn giản: nhóm chỉ việc 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ấp thiết cho từng story và gán số đó cho từng user story trong backlog. Thay vì cố gắng nỗ lực dự đoán xác thự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 từng story dựa trên độ phức tạp của nó, sau thời điểm đem đi so sánh với những tính năng khác mà nhóm đã xây dựng trước đó. Lúc đầu, các ước tính sẽ thay đổi rất nhiều từ story này sang story khác, nhưng sau một thời kì nhóm đã quen với quy mô mà nhóm sử dụng để ước tính thì sẽ dễ dàng hơn để tìm ra độ lớn của mỗi story.

Khi tất cả chúng ta ước tính bằng story points, tất cả chúng ta sẽ chỉ định một giá trị điểm cho từng 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 khi đối chiếu 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 tính 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à số lượng thực sự về thời kì (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 tính sơ bộ khi thực hiện Product Backlog Refinement, trước lúc 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 sẽ không?

– User story đã được phân chia hợp lý chưa?

Có rất nhiều phương pháp để ước tính story points trong Agile và tùy theo từng nhóm sẽ thống nhất với nhau về phương pháp tính. Trong hồ 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:

Định cỡ theo T-shirt size (size áo):

• 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 phương tiện ước tính ở high-level – mức độ tổng quát, được sử dụng để thực hiện các ước tính thuở đầu về các tính năng sản phẩm và user story trong thời đoạn mở màn của một dự án, khi mà đang có ít thông tin rõ ràng.
• Để phản ánh sự không kiên cố liên quan đến những ước tính đó, đơn vị ước tính của tất cả chúng ta sẽ là T-shirt sizes, từ Cực nhỏ – Extra Small (ES) đến Cực lớn – Extra Large (XXL).
• Tất cả chúng ta sẽ không còn cố gắng nỗ lực ước tính kích thước tuyệt đối của từng danh mục hoặc thậm chí là kích thước to ra nhiều thêm hay nhỏ hơn bao nhiêu so với những kích thước khác. Tất cả những gì tất cả chúng ta biết sẽ là Extra Small nhỏ hơn Small, nhỏ hơn Medium và tiếp tục như vậy.
• 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: 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 phương pháp lũy thừa của 2 để ước tính story point.
• Chuỗi Fibonacci cho 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ẽ vận dụng theo phương pháp 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 sao 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.

Xem Thêm : Động cơ servo (servo motor) là gì?

Bất kỳ điều gì không được thực hiện trong Sprint sẽ tiến hành 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éc tơ vận tốc tức thời – tấ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ẽ nhận định rằng 55 story points này như Sprint velocity và điều này cho nhóm một chiếc nhìn chung về tốc độ thực hiện công việc của tất 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 kì, 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 phương pháp đó, 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.

Quy trình ước tính story points

• Bước 1: Xác định Story cơ sở – Base Story

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

• Bước 2: Tạo ma trận để ước tính

Nhóm sẽ thực hiện ước tính 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 từng 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à mở màn phân loại chúng thành các hàng, so sánh các story với nhau và với những 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 trước nhất với giá trị là một story point.

Story point

Story

1

Với tư cách là người truy cập vào website, 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 từng story, nhóm có một cuộc họp, nơi tất cả những thành viên của development team sẽ sử dụng Planning Poker để lấy ra số lượng story point cho một story.

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

Bước 3: Quy trình ước tính Planning Poker

• Mỗi thành viên nhận được một bộ thẻ bài.
• Tất cả những thành viên chọn Backlog items để ước tính, thảo luận các tính năng và đặt vướng mắc.
• Khi một tính năng đã được thảo luận đầy đủ, mỗi người tự đưa ra số lượng ước tính cho riêng mình – đảm bảo kín đáo, và chọn một thẻ bài để đại diện thay mặt cho ước tính của mình.
• Khi tất cả đã có cho mình ước tính 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ả những ước tính đều khớp, cả nhóm sẽ chọn Backlog item khác và tái diễn quy trình tương tự. Lúc các ước tính 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 thời điểm cuối Planning Poker, nhóm sẽ điền toàn bộ kết quả đã chiếm hữu 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ấp 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 website, 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 website, 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ử hào hùng tính sổ của mình trên trang tùy chỉnh cấu hình.

Với tư cách là người truy cập website, tôi muốn có thể gửi phản hồi hoặc giải trình sự cố bằng phương pháp sử dụng biểu mẫu liên hệ.

3

Với tư cách là người truy cập website, 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 website.

5

Với tư cách là người truy cập vào website, tôi muốn sử dụng biểu mẫu tìm kiếm với những bộ lọc để tìm kiếm nội dung cụ thể.

Xem Thêm : Turn Off là gì và cấu trúc cụm từ Turn Off trong câu Tiếng Anh

Với tư cách là người truy cập vào website, tôi muốn xem thông tin rõ ràng 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 đề website, mô tả, nội dung phương tiện (hình ảnh, video, âm thanh), vùng đị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ân dùng khác.

• Bước 4: Sprint Planning

Tại thời khắc này, nhóm đã có ước tính về độ lớn dựa theo story points, vướng mắc đề ra là làm thế nào để nhóm có thể chuyển đổi những story points này thành ước tính thời kì 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 tới khi hoàn thành Sprint trước nhất. Trong những khi Sprint trước nhất đang diễn ra, nhóm có thể theo dõi Velocity của nhóm. Ngay sau thời điểm Sprint kết thúc, sẽ biết nhóm có thể hoàn thành bao nhiêu story points cho từng Sprint. Nhóm sử dụng những số lượng này để tham gia báo khả năng của mình cho những Sprint tiếp theo.

Khi ước tính được tất cả những 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 kì thực.

Những lỗi thường phạm phải khi sử dụng Story Point

• Chuyển đổi story point sang giờ: Bằng phương pháp chuyển đổi story point sang giờ/ngày/tuần, nhóm sẽ mở màn thao tác làm việc và phải mạo hiểm đưa ra cam kết thời kì hoàn thành xác thực. Giả sử story point được ước tính có phạm vi thời kì từ 10 – 20 giờ, nhưng khi ước tính theo giờ, nhóm phải đưa ra một số lượng xác thực như 15 giờ, từ này sẽ dẫn tới việc sai lệch, dẫn đến khó đạt được cam kết hơn khi chúng ta thao tác làm việc theo giờ xác thực.
• Đưa ra story point trung bình: Trong Planning Poker, một nửa thành viên trong nhóm ước tính một product backlog item là 3 story point và nửa còn sót lại ước tính 5 story point. Nhóm xử lý bằng phương pháp đặt 4 story point làm số lượng ước tính. 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ề độ xác thực. Tốt nhất là nhóm nên có một cuộc thảo luận để nắm rõ hơn thay vì lấy giá trị trung bình.
• Kiểm soát và điều chỉnh ước tính Story Point của tương đối nhiều user story trong Sprint: Khi nhóm mở màn xử lý một vấn đề, nhóm không nên kiểm soát và điều chỉnh ước tính story point ngay cả những lúc ước tính của họ không xác thực. Việc ước tính thỉnh thoảng bị sai lệch là điều thường nhật, nên nhóm không nên kiểm soát và đ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 xác thực hơn.
• Ước tính 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ấp thiết phải ước tính lại. Ước tính có thể không xác thực, nhưng đó không phải là vấn đề. Nhờ Sprint Planning, nhóm sẽ biết tất cả những nhiệm vụ (task) cấp thiết để hoàn thành user story. Ước tính của tương đối nhiều 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 kì để hoàn thành product backlog item này.
• Kiểm soát và điều chỉnh ước tính Story Point dựa vào người làm: User story có thể là 3 story point khi đối chiếu với thành viên nhiều kinh nghiệm, nhưng 8 story point khi đối chiếu với thành viên mới. Đây là cách làm không đúng. Tất cả chúng ta không nên kiểm soát và đ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 tương đối nhiều Chuyên Viên 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 tương đối nhiều Chuyên Viên mà không phải là sự việc phối hợp từ phía mỗi thành viên. Nhóm thường xử lý công việc bằng phương pháp để Chuyên Viên trình bày rõ ràng về công việc. Sau đó, để phần còn sót lại của nhóm ước tính mà không cần các Chuyên Viên. Tất cả chúng ta cần nhớ rằng ước tính story point là sự việc nỗ lực của tất 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 xác thực về việc ước tính story point trong Sprint Retrospective: Thỉnh thoảng, nhóm xác định được những vấn đề rõ ràng là ước tính 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 nỗ lực học hỏi, cải thiện, để những ước tính trong tương lai xác thực hơn.

Tổng kết

Khái niệm về story point đơn giản nhưng khó vận dụng. Hồ 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 phương tiện cốt lõi của Scrum. Bởi vì điều này, mọi người dân có ý kiến ​​khác nhau về phong thái bạn nên sử dụng chúng. Lúc đầu khi sử dụng story points có thể sẽ làm nhóm ước tính sai lệch, nhưng sau thời kì 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 tính trở thành nhẹ nhõm, dễ dàng hơn rất nhiều.

Tri 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ệ ra làm sao với WBS

Bản tuyên ngôn Agile – lịch sử hào hùng 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ấp thiết?

Quản lý dự án với Scrum

Scrum of Scrums

User stories – Phương tiện lên kế hoạch của Agile

Story points – Phương tiện ước tính của Agile

Velocity là gì – Phương tiện đo lường và thống kê 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 thao tác làm việc của dự án

PDCA – Chu trình cải tiến liên tục

Personas – Phương tiện 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

Khai mạc với Scrum từ đâu đây ta?

Một số phương pháp chạy Daily scrum hiệu quả