Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Product Owner của một team đang chuẩn bị bước vào Sprint mới. Sếp hỏi bạn: "Tính năng thanh toán qua ví điện tử bao giờ xong?" Bạn quay sang team, một bạn dev nói "chắc khoảng 3 ngày", bạn khác lắc đầu "không, ít nhất một tuần", còn bạn tester thì im lặng vì chưa hình dung được quy mô. Đây là khoảnh khắc mà mọi Product Owner đều gặp, và đây cũng chính là lý do estimation (ước lượng) tồn tại.
Estimation không phải là việc đoán mò cho có. Nó là một trong những kỹ năng nền tảng giúp PO biến những lời hứa mơ hồ thành một kế hoạch có cơ sở. Nếu bạn ước lượng kém, bạn sẽ liên tục lỡ hẹn với stakeholder, đốt cháy niềm tin của họ, và đẩy team vào vòng xoáy làm thêm giờ. Ngược lại, khi team ước lượng tốt, bạn có thể tự tin nói "chúng tôi sẽ giao được X trong vòng Y Sprint" mà không phải nín thở chờ may rủi.
Trong bài này, chúng ta sẽ đi sâu vào hai công cụ trung tâm của estimation trong Scrum: Story Points (điểm câu chuyện) và Planning Poker (kỹ thuật ước lượng nhóm). Tôi sẽ giải thích vì sao Scrum chọn ước lượng theo "kích thước tương đối" thay vì "số giờ", và làm sao để team của bạn ước lượng nhanh, đồng thuận và ngày càng chính xác. Đây là phần rất riêng của Bài 24 — chúng ta sẽ không bàn về velocity hay forecasting (đó là Bài 26), cũng không lan sang refinement (Bài 23). Ở đây, tâm điểm là: làm sao gán được một con số có ý nghĩa cho mỗi hạng mục công việc.
Khái niệm cốt lõi
Vì sao phải estimate?
Trước khi nói đến "ước lượng bằng gì", hãy hiểu rõ "ước lượng để làm gì". Có ba mục đích chính:
Thứ nhất, để dự báo năng lực (forecast capacity). Một team chỉ có một lượng công sức hữu hạn trong mỗi Sprint. Nếu bạn biết các hạng mục trong backlog "nặng" hay "nhẹ" thế nào, bạn mới biết được team có thể ôm được bao nhiêu việc vào một Sprint mà không bị quá tải. Estimation chính là cái thước đo "độ nặng" đó.
Thứ hai, để sắp xếp thứ tự công việc (sequence work). Khi PO nhìn vào backlog và thấy một tính năng có giá trị cao nhưng "nặng" gấp năm lần một tính năng giá trị trung bình nhưng "nhẹ", PO có thể đưa ra quyết định ưu tiên thông minh hơn. Ước lượng cung cấp một chiều thông tin quan trọng bên cạnh giá trị kinh doanh.
Thứ ba, để phát hiện rủi ro sớm (risk identification). Đây là tác dụng bị đánh giá thấp nhất. Khi cả team ngồi lại ước lượng một hạng mục mà các con số đưa ra chênh lệch rất lớn — người nói 2, người nói 13 — đó là tín hiệu vàng cho thấy mọi người đang hiểu khác nhau về phạm vi công việc, hoặc có một ẩn số kỹ thuật nào đó chưa được làm rõ. Cuộc tranh luận để hội tụ con số chính là lúc rủi ro lộ diện trước khi nó kịp gây hại.
Story Points: kích thước tương đối, không phải thời gian
Đây là khái niệm dễ gây hiểu lầm nhất với người mới. Story Point là đơn vị đo kích thước tương đối của một hạng mục công việc, không phải số giờ hay số ngày.
Tại sao lại "tương đối"? Vì con người dở tệ trong việc ước lượng tuyệt đối (bao nhiêu giờ chính xác?) nhưng lại khá giỏi trong việc so sánh tương đối (cái này lớn hơn hay nhỏ hơn cái kia?). Bạn có thể không biết chính xác quãng đường từ Hà Nội vào TP.HCM là bao nhiêu km, nhưng bạn chắc chắn biết nó xa hơn từ Hà Nội đi Hải Phòng "khoảng nhiều lần". Story Points khai thác chính khả năng so sánh tự nhiên này.
Story Points gói gọn ba yếu tố vào một con số duy nhất:
- Khối lượng công việc (effort/volume): việc nhiều hay ít.
- Độ phức tạp (complexity): logic rắc rối, nhiều ngóc ngách hay đơn giản.
- Độ bất định/rủi ro (uncertainty): team đã làm việc tương tự bao giờ chưa, có ẩn số kỹ thuật không.
Thang Fibonacci: vì sao không phải 1, 2, 3, 4, 5?
Đa số team Scrum dùng dãy số gần với Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100 (và thường có thêm 0 và một lá "?" nghĩa là chưa rõ).
Lý do rất tinh tế: khoảng cách giữa các số ngày càng giãn ra (1→2→3→5→8...). Điều này phản ánh đúng thực tế rằng việc càng lớn thì độ bất định càng cao, nên độ phân giải của ước lượng cũng cần thô hơn. Bạn có thể phân biệt rõ một việc 1 điểm và 2 điểm. Nhưng việc "21 điểm" và "22 điểm" thì khác nhau gì? Gần như không, và việc tranh cãi giữa chúng chỉ tốn thời gian. Fibonacci ép team chọn dứt khoát: hoặc 13, hoặc 20 — không có vùng xám ở giữa để mặc cả vô nghĩa.
Một nguyên tắc bất thành văn rất hữu ích: bất cứ hạng mục nào ước lượng từ 13 điểm trở lên là dấu hiệu nó quá lớn, cần được chẻ nhỏ ra trước khi đưa vào Sprint. Một việc 20 hay 40 điểm thường ẩn chứa quá nhiều rủi ro để team cam kết hoàn thành gọn ghẽ.
Planning Poker: ước lượng bằng trí tuệ tập thể
Planning Poker là kỹ thuật để cả team cùng ước lượng một cách đồng thuận, tránh việc một người (thường là người to tiếng nhất) áp đặt con số lên cả nhóm. Mỗi thành viên có một bộ thẻ ghi các số Fibonacci. Với mỗi hạng mục, mọi người chọn thẻ một cách độc lập rồi lật cùng lúc. Cái hay nằm ở chữ "cùng lúc": nó loại bỏ hiệu ứng tâm lý đám đông (anchoring), nơi con số của người nói trước kéo theo phán đoán của tất cả những người sau.
Tình huống thực tế
Tình huống 1: Tiki và cái bẫy "ước lượng theo giờ"
Một team phát triển tính năng tại một sàn thương mại điện tử lớn ở Việt Nam (gọi là team Checkout của Tiki để dễ hình dung) ban đầu ước lượng mọi thứ bằng giờ. Một hạng mục "thêm phương thức thanh toán Momo" được dev senior ước lượng 8 giờ. Đến Sprint thực thi, bạn senior bận việc khác, một bạn junior nhận task và mất 3 ngày. Kế hoạch vỡ, stakeholder bực bội.
PO quyết định chuyển team sang Story Points. Họ chọn một hạng mục tham chiếu quen thuộc — "thêm một trường lọc đơn giản vào trang sản phẩm" — gán cho nó 2 điểm làm mốc. Khi đánh giá lại task Momo, cả team thống nhất nó "nặng khoảng gấp 4 lần" việc tham chiếu, ra 8 điểm. Con số 8 này không đổi dù ai làm. Sau vài Sprint, dữ liệu cho thấy team hoàn thành ổn định một lượng điểm nhất định, và việc dự báo trở nên đáng tin hơn hẳn.
Bài học: Tách ước lượng khỏi "ai làm và làm nhanh hay chậm". Đo kích thước công việc, đừng đo con người. Một hạng mục tham chiếu rõ ràng là điểm tựa cho mọi ước lượng sau đó.
Tình huống 2: Startup fintech và lần chênh lệch 2 với 13
Tại một startup fintech ở TP.HCM, trong buổi Planning Poker, hạng mục "tích hợp xác thực sinh trắc học (eKYC)" được đưa ra. Các lá bài lật lên: ba người chọn 2, một người chọn 13. Theo phản xạ, nhiều team sẽ vội lấy trung bình rồi cho qua. Nhưng PO làm đúng quy trình: mời người chọn 13 giải thích.
Bạn dev đó nói: "Nhà cung cấp eKYC mình định dùng yêu cầu một quy trình kiểm duyệt pháp lý kéo dài, và SDK của họ chưa hỗ trợ Android cũ — mình từng vướng cái này ở công ty trước." Ba người kia trố mắt: họ tưởng chỉ là gọi một API có sẵn. Cuộc tranh luận lộ ra một rủi ro lớn mà nếu bỏ qua, cả Sprint sẽ trật bánh. Kết quả: họ tách hạng mục thành một spike nghiên cứu trước, và đẩy phần tích hợp thật sang Sprint sau.
Bài học: Chênh lệch lớn trong ước lượng không phải vấn đề cần "dẹp cho nhanh" — nó là món quà. Nó báo cho bạn biết team đang hiểu công việc khác nhau, và đó chính là nơi rủi ro ẩn náu. Đừng bao giờ lấy trung bình để né tránh cuộc trò chuyện đó.
Tình huống 3: Team agency và bệnh "lạm phát điểm"
Một agency phần mềm ở Đà Nẵng có thói quen nguy hiểm: ban lãnh đạo lấy Story Points làm thước đo năng suất, khen team nào "ghi" được nhiều điểm hơn. Hệ quả tất yếu là team bắt đầu thổi phồng ước lượng — việc đáng 3 điểm thì gán 5, đáng 5 thì gán 8. Trên giấy, "năng suất" tăng vọt mỗi quý. Nhưng lượng tính năng giao cho khách thực tế không hề tăng, thậm chí còn giảm vì team mất thời gian tranh cãi con số.
Khi một Scrum Master mới về phát hiện, anh giải thích lại với lãnh đạo: Story Points là công cụ nội bộ để team tự lập kế hoạch, không phải KPI để so sánh team này với team kia hay thưởng phạt. Điểm của team A và team B vốn không cùng đơn vị — mỗi team có mốc tham chiếu riêng. Sau khi gỡ bỏ áp lực đo năng suất bằng điểm, ước lượng của team dần trở về phản ánh đúng thực tế.
Bài học: Khoảnh khắc bạn biến Story Points thành chỉ tiêu thành tích, bạn giết chết tính trung thực của nó. Điểm là để hoạch định, không phải để đánh giá con người. Đừng so sánh điểm giữa các team khác nhau.
Hướng dẫn từng bước
Đây là quy trình tổ chức một buổi ước lượng bằng Planning Poker mà bạn có thể áp dụng ngay:
Bước 1 — Chuẩn bị mốc tham chiếu (baseline). Trước buổi họp, cùng team chọn một hạng mục nhỏ, đơn giản, ai cũng hiểu rõ, và gán cho nó giá trị 2 (hoặc 3) điểm. Đây sẽ là "cây thước" để so sánh mọi việc khác. Không có mốc này, các con số sẽ trôi nổi vô nghĩa.
Bước 2 — PO trình bày hạng mục. Với mỗi item, PO đọc user story, làm rõ tiêu chí chấp nhận (acceptance criteria), và trả lời các câu hỏi về "cái gì" và "tại sao". Lưu ý: PO mô tả nhu cầu, còn việc ước lượng "nặng nhẹ" thuộc về Developers — những người sẽ thực sự làm.
Bước 3 — Mỗi người chọn thẻ độc lập. Cả team suy nghĩ và chọn một lá bài Fibonacci, úp xuống, không tiết lộ. Có thể dùng bộ thẻ thật, hoặc công cụ trực tuyến như Planning Poker online, Jira, hay tính năng vote trong Miro nếu team làm việc từ xa.
Bước 4 — Lật bài cùng lúc. Tất cả lật một lượt. Nếu mọi người chọn giống hoặc sát nhau (ví dụ toàn 3 và 5), chốt nhanh con số đồng thuận và đi tiếp.
Bước 5 — Thảo luận khi có chênh lệch. Nếu khoảng cách lớn, mời người chọn số cao nhất và thấp nhất giải thích lý do. Đây là phần giá trị nhất của cả buổi — nơi giả định ngầm được phơi bày. Lắng nghe, đừng phán xét.
Bước 6 — Bỏ phiếu lại. Sau khi nghe nhau, cả team chọn thẻ lần nữa. Thường chỉ cần 2-3 vòng là hội tụ. Mục tiêu là đồng thuận đủ tốt, không phải nhất trí tuyệt đối 100%.
Bước 7 — Ghi nhận và đánh dấu việc quá lớn. Chốt điểm cho hạng mục. Nếu một item ra 13 trở lên, đánh dấu nó cần được chẻ nhỏ trước khi đưa vào Sprint, hoặc tách thành spike nếu phần lớn điểm đến từ độ bất định.
Lỗi thường gặp & mẹo
Lỗi 1: Quy đổi Story Points thành giờ. "5 điểm là bao nhiêu giờ?" — câu hỏi này phá hỏng toàn bộ ý nghĩa của ước lượng tương đối. Nếu team cứ âm thầm quy đổi sang giờ, bạn chỉ đang dùng một cái tên hoa mỹ cho ước lượng thời gian cũ. Mẹo: khi ai đó hỏi quy đổi, kéo họ về câu hỏi so sánh: "Việc này nặng gấp mấy lần việc tham chiếu 2 điểm của chúng ta?"
Lỗi 2: Để một người áp đặt con số. Khi tech lead vừa lên tiếng "cái này 3 điểm" trước khi mọi người chọn, cả team sẽ vô thức bám theo (hiệu ứng anchoring). Mẹo: luôn chọn thẻ độc lập rồi mới lật cùng lúc. Đây chính là lý do Planning Poker tồn tại.
Lỗi 3: Tìm sự chính xác giả tạo. Tranh cãi 30 phút giữa 5 và 8 điểm là lãng phí. Ước lượng vốn dĩ không chính xác — đó là bản chất, không phải lỗi. Mẹo: đặt giới hạn thời gian (timebox) cho mỗi hạng mục, ví dụ 2 phút; nếu chưa hội tụ, chọn con số cao hơn cho an toàn rồi đi tiếp.
Lỗi 4: Ước lượng việc khi chưa hiểu nó. Nếu cả team đều giơ thẻ "?", đừng ép ra con số. Mẹo: đưa hạng mục đó vào diện cần làm rõ thêm, hoặc tạo một spike để nghiên cứu trước.
Lỗi 5: So sánh điểm giữa các team hoặc dùng làm KPI. Như tình huống agency Đà Nẵng đã cho thấy, điều này hủy hoại tính trung thực. Mẹo: nhắc lãnh đạo rằng Story Points là đơn vị nội bộ, không có tỷ giá chung giữa các team.
Mẹo vàng — "tam giác chuẩn": Trước khi ước lượng một danh sách dài, hãy lấy ba hạng mục đại diện cho ba mức nhỏ–vừa–lớn (ví dụ 2, 5, 13) và dán chúng làm mốc trực quan trên bảng. Mọi item mới sẽ được "soi" vào ba mốc này, giúp ước lượng nhanh và nhất quán hơn rất nhiều.
Bài tập thực hành
- Lập bộ mốc tham chiếu: Lấy ba hạng mục có thật từ backlog hiện tại (hoặc một dự án bạn từng làm). Tự gán cho chúng các giá trị 2, 5 và 13 điểm sao cho phản ánh đúng độ "nặng nhẹ" tương đối giữa chúng. Viết một câu giải thích vì sao item 13 điểm lại nặng hơn item 2 điểm gấp nhiều lần — xét cả ba yếu tố: khối lượng, độ phức tạp, độ bất định.
- Mô phỏng Planning Poker: Rủ 2-3 đồng nghiệp (hoặc bạn học) ước lượng cùng 5 hạng mục. Mỗi người chọn thẻ độc lập rồi lật cùng lúc. Ghi lại hạng mục nào có chênh lệch lớn nhất, và liệt kê những giả định khác nhau đã lộ ra trong lúc thảo luận.
- Bài tập phát hiện rủi ro: Nhìn lại danh sách bạn vừa ước lượng. Hạng mục nào ra từ 13 điểm trở lên? Với mỗi cái, hãy viết cách bạn sẽ chẻ nó thành các phần nhỏ hơn, hoặc lý do bạn cần một spike để giảm độ bất định trước khi cam kết.
- Tự phản tỉnh: Viết ra một lần trong quá khứ bạn (hoặc team bạn) ước lượng sai nghiêm trọng. Nguyên nhân nằm ở đâu trong ba yếu tố: khối lượng bị đánh giá thấp, độ phức tạp bị bỏ sót, hay độ bất định không được nhận diện?
Tóm tắt
Estimation là kỹ năng giúp Product Owner biến những lời hứa mơ hồ thành kế hoạch có cơ sở, phục vụ ba mục đích: dự báo năng lực, sắp xếp thứ tự công việc, và phát hiện rủi ro sớm. Công cụ trung tâm là Story Points — đơn vị đo kích thước tương đối, gói gọn khối lượng, độ phức tạp và độ bất định vào một con số, độc lập với tốc độ của người làm. Thang Fibonacci (1, 2, 3, 5, 8, 13...) phản ánh đúng việc càng lớn thì độ phân giải càng cần thô, và nhắc team chẻ nhỏ mọi hạng mục từ 13 điểm trở lên.
Planning Poker khai thác trí tuệ tập thể: chọn thẻ độc lập, lật cùng lúc, và quan trọng nhất — biến mỗi lần chênh lệch lớn thành cơ hội phơi bày giả định và rủi ro. Hãy luôn neo ước lượng vào một bộ mốc tham chiếu rõ ràng, đừng quy đổi sang giờ, đừng để một người áp đặt, và tuyệt đối đừng biến Story Points thành KPI để so sánh hay thưởng phạt. Khi làm đúng, ước lượng không chỉ cho bạn những con số — nó cho bạn những cuộc trò chuyện giúp team hiểu nhau và hiểu công việc sâu hơn mỗi ngày.