Trong bài viết trước về “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 được các nhóm Agile sử dụng để lập kế hoạch và thể hiện các hạng mục công việc một cách hiệu quả. Tiếp tục với chuỗi công cụ và kỹ thuật này, chúng ta sẽ tìm hiểu công cụ thứ hai cũng rất 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. Story Points là một đơn vị đo lường trừu tượng cho nỗ lực cần thiết để hoàn thành một User story. Story points là con số, một đơn vị đo lường để biết về độ phức tạp của công việc và rủi ro liên quan đến thực hiện một hạng mục trong Product Backlog hoặc bất kỳ công việc nào khác.

Ước lượng story points thường được thực hiện 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 bao lâu thực hiện các tính năng của sản phẩm hoặc phần mềm. Thay vì dự đoán thời gian chính xác, nhóm chỉ định 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 cho phép nhóm so sánh các User stories với nhau. Chú trọng 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 có thể lập kế hoạch cùng nhau và dự đoán tính năng nào có thể thêm vào sản phẩm sau mỗi vòng lặp.

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 Product Backlog. Thay vì cố gắng dự đoán chính xác 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 User story dựa trên độ phức tạp của nó, sau khi 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 có thể thay đổi nhiều từ User story này sang User story khác, nhưng sau một thời gian nhóm đã quen với quy mô ước lượng và dễ dàng hơn để ước lượng độ lớn của mỗi User story.

Khi ước lượng bằng story points, nhóm chỉ định một giá trị điểm cho mỗi User story. Các giá trị thô không quan trọng, quan trọng là các giá trị này có quan hệ tương đối với nhau. Ví dụ, nếu User story A được gán 2 điểm, thì User story B có thể được gán 4 điểm. Điều quan trọng là tỷ lệ, không phải 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 Planning 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ó 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:

• Định cỡ theo T-shirt size (size áo):
  • Các nhóm Scrum có thể sử dụng ý tưởng 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 sản phẩm và User story.
  • Các giá trị của T-shirt sizes thể hiện độ lớn của User story, từ Cực nhỏ (Extra Small – ES) đến Cực lớn (Extra Large – XXL).
  • Ví dụ: nhóm có thể gán 1 điểm cho User story rất nhỏ (extra small), 2 điểm cho User story nhỏ (small), 3 điểm cho User story trung bình (medium), 4 điểm cho User story lớn (large), và 5 điểm cho User story 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 được tạo ra bằng cách lũy thừa của 2 để ước lượng story points.

• 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ì 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 và so sánh với các User story khác. Điều quan trọng là nhóm sử dụng thang đo một cách nhất quán.

Quy trình ước lượng story points

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

  • Tìm một User story cơ bản, có tiêu chuẩn 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ở để so sánh với các User story khác.

• Bước 2: Tạo ma trận để ước lượng

  • Tạo một ma trận với mỗi hàng được gán cho mỗi story point (ví dụ sử dụng dãy số Fibonacci) và các User story liên quan. Nhóm phân loại các User story, so sánh chúng với nhau và với các User story đã hoàn thành hoặc base story. Base story cũng được thêm vào ma trận.

• 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.
  • Thảo luận và chọn các User story để ước lượng, đặt câu hỏi và thảo luận về tính năng của User story.
  • 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ọi người tiết lộ thẻ bài cùng một lúc. Nếu các ước lượng khớp nhau, tiếp tục lựa chọn User story khác và lặp lại quy trình này. Nếu có sự chênh lệch lớn, thảo luận để đạt được sự thống nhất.

• Bước 4: Sprint Planning

  • Khi nhóm có ước lượng story points, câu hỏi là làm thế nào để chuyển đổi thành ước lượng thời gian (giờ/ngày/tuần). Nhóm không thể làm điều 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 mình. Ngay sau khi Sprint kết thúc, nhóm sẽ biết cần bao nhiêu story points để hoàn thành mỗi Sprint và sử dụng thông tin này cho Sprint tiếp theo.

• Các lỗi thường mắc phải khi sử dụng Story Point:

  • Chuyển đổi story point sang giờ: Điều này dẫn đến sự không chính xác trong cam kết thời gian và khó đạt được cam kết khi hoạt động theo giờ chính xác.
  • Đưa ra story point trung bình: Không nên làm điều này vì không phản ánh chính xác.
  • Điều chỉnh ước lượng Story Point: Không nên điều chỉnh ngay lập tức khi ước lượng sai.
  • Ước lượng Story point cho những vấn đề chưa hoàn thành một lần nữa: Không cần thiết phải ước lượng lại.
  • Điều chỉnh ước lượng Story Point dựa vào người làm: Story point chỉ dựa vào độ lớn, độ phức tạp của User story.
  • Tuân theo ý kiến chuyên gia: Story point là nỗ lực của cả nhóm.
  • Không thảo luận lại các vấn đề không chính xác trong Sprint Retrospective.

Khái niệm story points đơn giản nhưng khó áp dụng. Ban đầu, nhóm có thể ướ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óm thuần thục hơn và ướ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 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ả

HEFC