Mở đầu — vì sao bài này quan trọng
Có một câu hỏi mà gần như mọi Product Owner đều phải trả lời mỗi tuần, từ một startup ở Cầu Giấy cho tới một tập đoàn fintech ở Singapore: "Cái này bao giờ xong?" Và đây cũng là nơi rất nhiều PO mắc kẹt — họ bị stakeholder ép phải đưa ra một con số chính xác, rồi con số đó biến thành lời hứa, lời hứa biến thành áp lực, và áp lực đè lên Developers. Khi mọi thứ trễ, người ta quay lại hỏi: "Tại sao ước lượng sai?"
Bản chất của vấn đề nằm ở chỗ: nhiều người hiểu sai estimation là gì. Họ nghĩ estimation là dự đoán thời gian. Nhưng trong Scrum, estimation phục vụ một mục đích khác hẳn — nó giúp team hiểu được độ lớn tương đối của công việc, để cùng nhau lập kế hoạch và dự báo (forecast), chứ không phải để ký một hợp đồng cam kết về thời gian hoàn thành từng item.
Trong kỳ thi PSPO I, estimation là chủ đề có nhiều "bẫy" tinh tế. Scrum Guide 2020 cố tình KHÔNG bắt buộc một kỹ thuật ước lượng cụ thể nào — không hề nhắc đến Story Points, Fibonacci hay planning poker. Đây là điểm cực kỳ quan trọng mà nhiều thí sinh không nắm, dẫn đến chọn sai đáp án. Bài này sẽ giúp bạn vừa nắm vững các kỹ thuật phổ biến (Story Points, T-shirt sizing, #NoEstimates), vừa hiểu đúng tinh thần Scrum để không bị lừa trong phòng thi và quan trọng hơn là làm việc đúng đắn ngoài đời.
Khái niệm cốt lõi
Estimation thực chất là gì trong Scrum
Trước hết, hãy gỡ một hiểu lầm lớn: trong Scrum, ai là người ước lượng? Câu trả lời là Developers — những người sẽ thực hiện công việc. PO KHÔNG được áp đặt ước lượng cho Developers, cũng không tự đặt Story Points rồi đưa cho team. Vai trò của PO là làm rõ giá trị, làm rõ "what" và "why"; còn ước lượng "how much effort" thuộc về những người làm.
Scrum Guide 2020 chỉ nói rằng các Product Backlog Item nên được "sized" (định cỡ) bởi Developers để hỗ trợ refinement và planning, nhưng không quy định kỹ thuật. Điều này có nghĩa: bạn hoàn toàn có thể dùng Story Points, T-shirt sizing, ideal days, hoặc thậm chí không ước lượng gì cả — miễn là nó giúp team forecast tốt hơn.
Story Points và thang Fibonacci
Story Points là đơn vị phổ biến nhất. Một Story Point KHÔNG phải là một giờ hay một ngày. Nó đại diện cho một tổ hợp gồm ba yếu tố:
- Effort (công sức) — khối lượng công việc cần bỏ ra.
- Complexity (độ phức tạp) — việc này khó tới mức nào, có bao nhiêu thành phần phải xử lý.
- Uncertainty / Risk (độ bất định) — chúng ta hiểu rõ vấn đề chưa, có nhiều ẩn số không.
Vì sao không dùng giờ? Vì ước lượng theo giờ tạo ảo giác về độ chính xác, và mỗi người làm việc với tốc độ khác nhau. Một bạn senior làm 3 giờ, một bạn junior làm 8 giờ — nhưng "độ lớn" của công việc thì như nhau. Story Points trừu tượng hóa được sự khác biệt cá nhân này.
Velocity — và vì sao nó là công cụ của team, không phải KPI
Khi team dùng Story Points, qua vài Sprint họ biết được trung bình mỗi Sprint hoàn thành khoảng bao nhiêu điểm — đó là velocity. Velocity giúp PO forecast: nếu phần còn lại của backlog khoảng 120 điểm và velocity là 30 điểm/Sprint, ta dự báo cần khoảng 4 Sprint.
Cảnh báo quan trọng cho cả phòng thi lẫn thực tế: velocity là công cụ dự báo nội bộ của team, KHÔNG phải thước đo năng suất để so sánh giữa các team hay làm KPI ép Developers. Khi velocity bị biến thành mục tiêu, Developers sẽ "thổi phồng" điểm số (point inflation), và mọi con số trở nên vô nghĩa.
T-shirt sizing
T-shirt sizing dùng các cỡ áo: XS, S, M, L, XL (đôi khi thêm XXL). Đây là kỹ thuật ước lượng thô, nhanh, ít gây tranh cãi về con số. Nó cực kỳ hữu ích ở giai đoạn sớm — khi nhìn vào một roadmap còn mơ hồ, hoặc khi cần phân loại nhanh hàng chục item mà chưa đủ thông tin để gán điểm chi tiết.
Ưu điểm: nhanh, trực giác, giảm tranh luận. Nhược điểm: thô, khó cộng dồn để forecast (làm sao cộng "M + L + S"?). Nhiều team dùng T-shirt sizing ở mức epic/feature lớn, rồi mới chuyển sang Story Points khi item được làm mịn (refined) đủ nhỏ để vào Sprint.
#NoEstimates
#NoEstimates là một trào lưu (do Vasco Duarte, Woody Zuill và những người khác cổ vũ) đặt câu hỏi: liệu chúng ta có thực sự cần ước lượng từng item không? Ý tưởng cốt lõi: thay vì tốn thời gian gán điểm, hãy chẻ nhỏ các item về kích thước tương đối đồng đều, rồi đơn giản đếm số item hoàn thành mỗi Sprint. Nếu mỗi Sprint team làm xong khoảng 6–8 stories đã được chẻ nhỏ, ta vẫn forecast được mà không cần Story Points.
#NoEstimates không có nghĩa là "không lập kế hoạch" hay "không suy nghĩ". Nó nghĩa là giảm sự phụ thuộc vào con số ước lượng chi tiết, dồn năng lượng vào việc chẻ nhỏ tốt và đo throughput (số item/Sprint). Đây là cách tiếp cận hợp với team trưởng thành, nơi các story đã được refine đủ đều.
Điểm mấu chốt cho PSPO I
Hãy ghi nhớ: Scrum không yêu cầu bất kỳ kỹ thuật nào ở trên. Nếu đề thi hỏi "Scrum bắt buộc dùng Story Points đúng không?" — câu trả lời là SAI. Developers chọn cách họ sizing công việc. Estimation phục vụ planning và forecast, không phải để khóa cam kết về ngày giờ.
Tình huống thực tế
Ví dụ 1: Startup giao đồ ăn ở TP.HCM và cú trượt vì ước lượng theo giờ
Một startup giao đồ ăn (gọi là FoodNow) có team 6 Developers. Ban đầu, PO yêu cầu mọi item phải ước lượng theo giờ để báo cáo lên ban giám đốc. Tính năng "tích hợp ví điện tử MoMo" được ước lượng 40 giờ. Thực tế mất 95 giờ vì gặp vô số ẩn số: tài liệu API thay đổi, phải xử lý refund, phải đối soát giao dịch.
Ban giám đốc nổi giận: "Các bạn ước lượng sai hơn gấp đôi!" Niềm tin sụp đổ, và áp lực khiến Developers bắt đầu "ước lượng phòng thủ" — cứ nhân đôi mọi con số cho an toàn, làm chậm cả tiến độ thật.
Scrum Master và PO ngồi lại, chuyển sang Story Points. Họ lấy một tính năng nhỏ đã làm xong (sửa giao diện danh sách món) làm mốc tham chiếu = 2 điểm. Tích hợp ví MoMo, vốn nhiều bất định, được team đánh giá 13 điểm. Sau 4 Sprint, velocity ổn định ở mức ~28 điểm/Sprint. Giờ khi ban giám đốc hỏi "bao giờ xong tính năng X", PO trả lời bằng forecast theo phạm vi: "Khoảng 3–4 Sprint, chúng tôi sẽ cập nhật sau mỗi Sprint."
Bài học: Con số tuyệt đối theo giờ tạo ra ảo giác chính xác và phá hủy niềm tin khi sai. Ước lượng tương đối + velocity cho phép forecast trung thực mà vẫn linh hoạt. Quan trọng hơn, PO đã ngừng biến estimation thành cam kết.
Ví dụ 2: Công ty SaaS B2B ở Singapore và T-shirt sizing cho roadmap
Một công ty SaaS B2B phục vụ doanh nghiệp logistics có một roadmap với khoảng 40 ý tưởng tính năng cho 2 quý tới, nhưng phần lớn còn rất mơ hồ. PO cố ép team gán Story Points cho tất cả ngay từ đầu, nhưng các buổi refinement kéo dài 3 tiếng vẫn không xong vì team thiếu thông tin, và tranh luận "cái này 8 hay 13" diễn ra bất tận.
Họ đổi chiến lược: ở cấp roadmap, chỉ dùng T-shirt sizing. Trong một buổi 90 phút, team phân loại 40 ý tưởng thành XS/S/M/L/XL. "Báo cáo tùy biến" được gắn XL, "đổi màu logo theo brand khách hàng" gắn XS. Nhờ đó PO nhìn ra ngay đâu là những món "to và rủi ro" cần được khám phá sớm. Chỉ những item sắp vào Sprint (đã được làm mịn) mới được chuyển sang Story Points chi tiết.
Bài học: Dùng đúng độ thô của ước lượng cho đúng giai đoạn. Ép độ chính xác cao lên thông tin còn mơ hồ là lãng phí. T-shirt sizing ở tầm cao, Story Points ở tầm Sprint.
Ví dụ 3: Team platform trưởng thành ở Hà Nội thử #NoEstimates
Một team platform 7 người trong một công ty công nghệ ở Hà Nội đã làm việc cùng nhau 2 năm. Họ nhận thấy các buổi planning poker ngày càng giống thủ tục: gần như mọi story đều rơi vào 2, 3 hoặc 5 điểm, và họ tốn 45 phút mỗi Sprint chỉ để tranh luận những khác biệt nhỏ nhặt.
Scrum Master đề xuất thử #NoEstimates trong 3 Sprint. Quy ước mới: mỗi story phải được chẻ nhỏ sao cho team tin là hoàn thành được trong 1–2 ngày. Không gán điểm nữa, chỉ đếm số story. Họ phát hiện throughput ổn định ở mức 9–11 stories/Sprint. Forecast cho phần backlog còn lại (khoảng 50 stories đã refine) là 5 Sprint — và độ chính xác không hề kém phiên bản Story Points trước đây.
Điều thú vị: kỹ năng chẻ nhỏ story của team tăng vọt, vì giờ đây đó là việc quan trọng nhất. PO hưởng lợi: backlog gồm các item nhỏ, độc lập, dễ ưu tiên lại.
Bài học: Khi team đủ trưởng thành và story đủ đều, đếm item có thể thay thế gán điểm. Trọng tâm dịch chuyển từ "đoán con số" sang "chẻ nhỏ tốt" — vốn là điều mang lại giá trị thật.
Hướng dẫn từng bước
Dưới đây là cách thiết lập một quy trình ước lượng lành mạnh cho team của bạn:
- Xác định mục đích trước khi chọn kỹ thuật. Bạn ước lượng để forecast tiến độ và lập kế hoạch Sprint, không phải để cam kết ngày giờ với từng item. Truyền thông điều này với stakeholder ngay từ đầu.
- Chọn một item tham chiếu (reference story). Lấy một công việc team đã làm xong, có độ lớn vừa phải, ai cũng hiểu. Gán cho nó một giá trị (ví dụ 2 hoặc 3 điểm). Mọi ước lượng về sau đều so sánh với mốc này.
- Chọn kỹ thuật phù hợp với giai đoạn. Roadmap mơ hồ → T-shirt sizing. Item sắp vào Sprint, đã refine → Story Points (Fibonacci). Team trưởng thành, story đều → cân nhắc #NoEstimates (đếm item).
- Ước lượng theo nhóm, không cá nhân. Dùng Planning Poker hoặc kỹ thuật tương tự để mọi Developer cho con số đồng thời. Khi có chênh lệch lớn (ví dụ người ra 3, người ra 13), đó là dấu hiệu cần thảo luận — thường lộ ra một ẩn số hoặc một cách hiểu khác nhau. Chính cuộc thảo luận này mới là giá trị, không phải con số cuối.
- Để Developers quyết định con số cuối. PO làm rõ phạm vi, trả lời câu hỏi, nhưng KHÔNG áp đặt điểm. Đây là ranh giới vai trò quan trọng.
- Theo dõi velocity hoặc throughput qua nhiều Sprint. Đừng tin một Sprint đơn lẻ; lấy trung bình 3–5 Sprint gần nhất để forecast.
- Forecast theo phạm vi, không phải một con số đơn. Nói "3–5 Sprint" thay vì "đúng 4 Sprint". Cập nhật lại sau mỗi Sprint dựa trên dữ liệu thực — đây chính là tinh thần empiricism của Scrum.
- Định kỳ xem lại cách ước lượng trong Retrospective. Nếu kỹ thuật hiện tại tốn thời gian mà ít giá trị, hãy thử cách khác.
Lỗi thường gặp & mẹo
Lỗi: Quy đổi Story Points sang giờ. "1 điểm = 4 giờ" phá hủy toàn bộ mục đích của ước lượng tương đối và đưa bạn trở lại cái bẫy chính xác giả tạo. Tránh tuyệt đối.
Lỗi: PO áp đặt điểm cho Developers. Đây là vi phạm vai trò và là bẫy kinh điển trong đề PSPO I. Người làm việc là người ước lượng.
Lỗi: Biến velocity thành KPI hoặc dùng để so sánh giữa các team. Mỗi team có thang điểm riêng; so sánh velocity giữa team này với team kia là vô nghĩa, và sẽ dẫn đến point inflation.
Lỗi: Coi ước lượng là cam kết. Estimate là forecast, có thể sai và sẽ được điều chỉnh. Khi bạn (hoặc stakeholder) đối xử với nó như lời hứa khắc đá, áp lực sẽ làm hỏng cả chất lượng lẫn niềm tin.
Lỗi: Tốn quá nhiều thời gian tranh luận con số. Nếu một item kẹt giữa 5 và 8, cứ chọn số lớn hơn và đi tiếp. Mục đích là forecast, không phải sự hoàn hảo.
Lỗi: Ước lượng item quá lớn. Một item 21 điểm thường là dấu hiệu nó cần được chẻ nhỏ, vì độ bất định quá cao. Item càng lớn, ước lượng càng kém tin cậy.
Mẹo cho phòng thi: Khi gặp câu hỏi nhắc đến Story Points, Fibonacci, planning poker — hãy nhớ Scrum Guide KHÔNG bắt buộc chúng. Đáp án đúng thường nhấn mạnh: Developers chọn kỹ thuật; estimation hỗ trợ planning; không có technique bắt buộc.
Mẹo thực tế: Khi stakeholder ép một ngày cụ thể, đừng đưa một con số đơn. Hãy đưa phạm vi kèm điều kiện: "Với velocity hiện tại và phạm vi này, dự kiến 3–4 Sprint. Nếu phạm vi đổi, dự báo sẽ đổi theo."
Bài tập thực hành
- Xây thang tham chiếu: Lấy 5 item gần đây team bạn đã hoàn thành. Cùng nhau gán chúng vào thang Fibonacci bằng cách so sánh tương đối (item nào là 1, item nào là 8?). Đây là bộ "reference stories" cho các lần ước lượng sau.
- So sánh hai kỹ thuật: Chọn 10 item trong backlog. Lần lượt ước lượng bằng T-shirt sizing rồi bằng Story Points. Quan sát: kỹ thuật nào nhanh hơn? Kỹ thuật nào cho thông tin hữu ích hơn ở giai đoạn hiện tại của bạn?
- Thử đếm thay vì gán điểm: Nhìn lại 3 Sprint gần nhất. Đếm số item đã hoàn thành mỗi Sprint (throughput). So sánh forecast bằng throughput với forecast bằng velocity. Chúng có khác nhau nhiều không?
- Tình huống ra quyết định: Giám đốc yêu cầu bạn cam kết "tính năng thanh toán sẽ xong vào ngày 30". Velocity của team là 25 điểm/Sprint, phần việc còn lại ước khoảng 70 điểm, Sprint dài 2 tuần. Hãy soạn một câu trả lời cho giám đốc thể hiện đúng tinh thần forecast (phạm vi + điều kiện), thay vì một lời cam kết cứng.
- Tự kiểm tra PSPO I: Đúng hay sai — "Scrum yêu cầu Product Backlog Items phải được ước lượng bằng Story Points." Giải thích lý do cho lựa chọn của bạn.
Tóm tắt
Estimation trong Scrum tồn tại để giúp team lập kế hoạch và dự báo, KHÔNG phải để cam kết thời gian từng item. Người ước lượng luôn là Developers, không phải PO. Story Points là đơn vị tương đối phản ánh effort + complexity + uncertainty, dùng thang Fibonacci (1, 2, 3, 5, 8, 13...) và KHÔNG phải là thời gian. T-shirt sizing (XS–XL) phù hợp cho ước lượng thô ở tầm roadmap. #NoEstimates đề xuất chẻ nhỏ story đều và đếm số item thay vì gán điểm — hợp với team trưởng thành.
Velocity và throughput là công cụ forecast nội bộ của team, tuyệt đối không phải KPI để so sánh hay ép buộc. Và điểm cốt lõi cho cả kỳ thi lẫn công việc thật: Scrum Guide không bắt buộc bất kỳ kỹ thuật ước lượng nào — team tự chọn cách giúp họ inspect và adapt tốt nhất. Một PO giỏi không phải là người đoán đúng con số, mà là người biến estimation thành công cụ giao tiếp trung thực với stakeholder, đồng thời bảo vệ Developers khỏi áp lực biến forecast thành lời hứa khắc đá.