Mở đầu — vì sao bài này quan trọng
Nếu bạn đang ôn thi PSM I, có một cái bẫy mà rất nhiều người sập vào ở phần Estimation: họ học thuộc lòng "Scrum dùng Story Points" hoặc "Sprint phải có Planning Poker" rồi tự tin chọn đáp án sai. Đề thi PSM I cố tình đưa ra những câu mà đáp án nghe rất "đúng theo thực tế công ty bạn" nhưng lại sai theo Scrum Guide.
Sự thật cốt lõi của bài này — và bạn cần khắc cốt ghi tâm: Scrum Guide 2020 không quy định bất kỳ kỹ thuật ước lượng nào. Không có Story Points, không có Planning Poker, không có T-shirt sizing trong Scrum Guide. Những thứ đó là technique (kỹ thuật) — công cụ phổ biến mà đội tự chọn, chứ không phải mandate (yêu cầu bắt buộc) của framework.
Hiểu được ranh giới này không chỉ giúp bạn ghi điểm trong phòng thi. Khi ra ngoài làm Scrum Master thật, bạn sẽ gặp những đội tranh cãi nảy lửa về "1 story point bằng bao nhiêu giờ" hay "tại sao chúng ta phải estimate". Một Scrum Master hiểu đúng bản chất sẽ biết cách dẫn dắt đội thoát khỏi những cuộc tranh cãi vô bổ đó. Bài này sẽ trang bị cho bạn cả hai: kiến thức "by the book" để qua thi, và sự hiểu biết thực tế để hành nghề.
Khái niệm cốt lõi
Scrum Guide nói gì (và không nói gì) về estimation
Hãy đọc thật kỹ những gì Scrum Guide thực sự viết. Trong phần Product Backlog, Scrum Guide nói: "Developers who will be doing the work are responsible for the sizing." — Những Developer thực hiện công việc chịu trách nhiệm về việc xác định kích cỡ (sizing) công việc. Và: "The Product Owner may influence the Developers by helping them understand and select trade-offs, but the people who will perform the work make the final assessment."
Từ hai câu này, bạn rút ra ba nguyên tắc bất di bất dịch cho phòng thi:
- Ai estimate? Developers — những người sẽ làm việc. Không phải Product Owner, không phải Scrum Master, không phải sếp.
- Product Owner có vai trò gì? PO có thể ảnh hưởng bằng cách giúp Developer hiểu và lựa chọn trade-off, nhưng không quyết định con số cuối cùng.
- Technique nào? Scrum Guide hoàn toàn im lặng. Đội tự chọn.
Tại sao Scrum cố tình không quy định technique?
Đây là điểm triết lý mà PSM I rất thích kiểm tra. Scrum là một framework empirical (thực nghiệm) — nhẹ, có chủ đích để mở. Scrum Guide chỉ định nghĩa những gì tối thiểu cần thiết. Mọi thứ khác (technique, công cụ, process) để cho đội tự bồi đắp dựa trên bối cảnh của mình.
Estimation chính là một ví dụ điển hình. Một đội phát triển app fintech với độ phức tạp kỹ thuật cao có thể cần Story Points để nắm bắt được "độ khó", trong khi một đội làm content marketing có thể chỉ cần T-shirt sizing thô. Nếu Scrum ép buộc một technique, nó sẽ trở thành chiếc áo chật cho nhiều đội. Vì vậy Scrum để ngỏ — đúng tinh thần self-managing team.
Ba kỹ thuật estimation phổ biến nhất
Mặc dù Scrum không bắt buộc, một Scrum Master cần hiểu rõ các technique để giúp đội chọn lựa. Đây là ba nhóm phổ biến nhất.
Story Points (relative estimation — ước lượng tương đối)
Đây là cách phổ biến nhất trong thực tế. Thay vì hỏi "việc này mất bao nhiêu giờ?", đội hỏi "việc này to cỡ nào so với một việc tham chiếu?". Story Point là con số tương đối, không có đơn vị tuyệt đối, thường gói gọn ba yếu tố: khối lượng công việc (effort), độ phức tạp (complexity), và độ bất định/rủi ro (uncertainty).
Người ta hay dùng dãy Fibonacci điều chỉnh (1, 2, 3, 5, 8, 13, 20, 40, 100) vì khi việc càng lớn, độ bất định càng cao, nên khoảng cách giữa các con số nên giãn ra. Một item 1 điểm và 2 điểm khác nhau rõ ràng; nhưng giữa 20 và 21 thì sự phân biệt là ảo tưởng — Fibonacci ép đội chọn 20 hoặc 40, tránh bàn cãi vô nghĩa.
Lưu ý quan trọng cho phòng thi: Story Points không phải là giờ. Một câu hỏi kinh điển: "5 story points bằng bao nhiêu giờ?" — câu trả lời đúng theo tinh thần là không có sự quy đổi cố định; điểm số là tương đối, không phải thời gian.
Planning Poker
Đây là một kỹ thuật cộng tác để đi đến Story Points (hoặc đơn vị khác), do James Grenning đề xuất và Mike Cohn phổ biến. Mỗi Developer cầm một bộ thẻ Fibonacci, cùng đọc item, rồi đồng loạt lật thẻ. Nếu con số chênh lệch lớn, người ước lượng cao nhất và thấp nhất giải thích góc nhìn của mình, rồi cả đội ước lượng lại. Mục đích thật sự không phải con số, mà là cuộc đối thoại để lộ ra những giả định ẩn — "à hóa ra anh nghĩ việc này phải tích hợp với cổng thanh toán cũ nên anh cho 13 điểm".
T-shirt Sizing (XS, S, M, L, XL)
Khi đội cần ước lượng thô và nhanh — đặc biệt ở giai đoạn đầu khi Product Backlog còn mơ hồ — họ gán mỗi item một "cỡ áo": XS, S, M, L, XL. Cách này dễ tiếp cận với người không quen con số, giảm cảm giác "chính xác giả tạo", và rất hợp cho refinement sơ bộ hoặc roadmap. Sau này, các cỡ áo có thể được quy đổi sang Story Points nếu cần chi tiết hơn.
#NoEstimates
Đây là một trào lưu (do Woody Zuill, Vasco Duarte và những người khác cổ vũ) đặt câu hỏi cấp tiến: liệu chúng ta có thực sự cần estimate không? Lập luận: việc ước lượng tốn thời gian, thường không chính xác, và đôi khi bị lạm dụng để biến "forecast" thành "commitment cứng". Thay vào đó, đội chia công việc thành các item nhỏ và đều nhau nhất có thể, rồi đơn giản đếm số item hoàn thành mỗi Sprint (throughput) để dự báo.
Điểm cực kỳ quan trọng cho PSM I: #NoEstimates hoàn toàn không vi phạm Scrum. Vì Scrum không bắt buộc estimation, một đội chọn không dùng Story Points mà chỉ đếm item vẫn đang làm Scrum đúng chuẩn. Nếu đề thi hỏi "Một đội Scrum quyết định không ước lượng bằng story points mà chỉ chia nhỏ item đều nhau và đếm — điều này có hợp lệ không?", đáp án là Có, hợp lệ.
Tình huống thực tế
Ví dụ 1: Tiki và cuộc tranh cãi "1 point bằng bao nhiêu giờ"
Một đội phát triển tại một công ty thương mại điện tử lớn ở TP.HCM (tạm gọi giống mô hình Tiki) gồm 6 Developer dùng Planning Poker với dãy Fibonacci. Vấn đề nảy sinh khi một Engineering Manager mới về, yêu cầu đội "chuẩn hóa": 1 story point = 4 giờ. Lý do anh đưa ra: để anh báo cáo lên ban giám đốc rằng "Sprint này đội làm được 40 point tức 160 giờ".
Hậu quả xuất hiện sau hai Sprint. Developer bắt đầu "đếm ngược": một item họ thấy phức tạp về kiến trúc nhưng nhanh về thời gian gõ code thì bị ép thành điểm thấp; một item đơn giản nhưng phải chờ team khác thì bị thổi điểm cao. Velocity dao động loạn xạ, và tệ hơn, các con số point trở thành công cụ để quản lý "gây áp lực giờ giấc".
Scrum Master can thiệp, quay lại đúng bản chất: Story Point là relative size gói cả complexity và uncertainty, không phải đơn vị thời gian. Cô bỏ quy đổi cứng, giải thích với manager rằng forecast của đội đến từ velocity lịch sử, không phải phép nhân giờ. Sau ba Sprint, velocity ổn định trở lại quanh 35-40 point.
Bài học: Quy đổi cứng point sang giờ là một anti-pattern. Nó phá hỏng bản chất tương đối của Story Points và biến một công cụ giao tiếp thành công cụ giám sát. Trong phòng thi, nếu thấy đáp án nào ngụ ý "point = giờ cố định", hãy cảnh giác.
Ví dụ 2: Startup fintech ở Singapore chuyển sang #NoEstimates
Một startup fintech 4 Developer ở Singapore, làm tính năng cho ví điện tử, nhận ra họ tốn trung bình 90 phút mỗi tuần chỉ để Planning Poker, nhưng độ chính xác của ước lượng chẳng giúp ích gì cho dự báo — vì backlog thay đổi liên tục theo phản hồi từ ngân hàng đối tác.
Scrum Master đề xuất thử nghiệm #NoEstimates trong 4 Sprint: thay vì gán point, đội cam kết chia mọi Product Backlog item xuống còn cỡ "có thể xong trong 1-2 ngày". Họ ngừng họp poker, và chỉ đếm số item hoàn thành mỗi Sprint. Sau 4 Sprint, throughput của họ là 8, 9, 7, 9 item — đủ ổn định để Product Owner forecast với stakeholder rằng "khoảng 8 item mỗi Sprint".
Kết quả: tiết kiệm khoảng 6 giờ họp mỗi tháng, và dự báo còn đáng tin hơn trước vì các item đã được chuẩn hóa kích cỡ. Quan trọng nhất, không một quy tắc Scrum nào bị vi phạm.
Bài học: #NoEstimates là một lựa chọn hợp lệ trong Scrum. Giá trị nằm ở kỷ luật chia nhỏ item đều nhau — đó mới là điều thực sự cải thiện khả năng dự báo, chứ không phải bản thân con số ước lượng.
Ví dụ 3: Đội mới ở một ngân hàng dùng T-shirt sizing để khởi động
Một đội vừa thành lập tại bộ phận chuyển đổi số của một ngân hàng ở Hà Nội, các Developer chưa từng làm Scrum và rất ngại con số — họ sợ "ước lượng sai bị quy trách nhiệm". Khi Scrum Master ép họ chơi Planning Poker ngay, mọi người lật thẻ rón rén, ai cũng chờ nhìn thẻ người khác.
Scrum Master đổi chiến thuật: bắt đầu bằng T-shirt sizing. Đội chỉ cần phân loại item thành S, M, L. Không có con số, không có cảm giác bị chấm điểm. Sau vài Sprint khi đội đã thoải mái và có dữ liệu thực tế về "S thường xong nhanh, L hay kéo dài", Scrum Master mới dần giới thiệu Story Points để có độ chi tiết cao hơn.
Bài học: Không có technique "đúng nhất" — chỉ có technique phù hợp với độ trưởng thành của đội. Vai trò Scrum Master là facilitate việc lựa chọn, không phải áp đặt. Và bất kỳ technique nào trong số này đều hợp lệ với Scrum.
Hướng dẫn từng bước
Nếu bạn là Scrum Master và muốn giúp đội thiết lập cách estimate, đây là quy trình thực tế.
Bước 1 — Khẳng định nguyên tắc nền tảng. Làm rõ với đội và stakeholder: Developers là người estimate, technique do đội tự chọn, và estimate là forecast chứ không phải lời hứa cứng. Đặt nền này trước để tránh tranh cãi về sau.
Bước 2 — Chọn technique theo bối cảnh đội. Đội mới, ngại con số → bắt đầu T-shirt sizing. Đội cần chi tiết và đã trưởng thành → Story Points qua Planning Poker. Backlog biến động nhanh, item dễ chia đều → cân nhắc #NoEstimates với throughput.
Bước 3 — Thiết lập item tham chiếu (reference). Với relative estimation, chọn một item đội đã hiểu rõ làm mốc (ví dụ "cái này là 3 point/cỡ M"). Mọi ước lượng sau so với mốc này. Đây là chìa khóa để con số tương đối có ý nghĩa.
Bước 4 — Estimate trong Refinement, không nhất thiết trong Planning. Việc xác định kích cỡ là một phần của hoạt động refinement diễn ra liên tục, để khi vào Sprint Planning item đã đủ rõ. (Lưu ý: refinement không phải một Scrum Event — chi tiết ở bài khác.)
Bước 5 — Dùng estimate để forecast, không để đánh giá con người. Tổng hợp dữ liệu lịch sử (velocity hoặc throughput) để Product Owner dự báo. Tuyệt đối không dùng con số ước lượng để xếp hạng hay so sánh hiệu suất Developer.
Bước 6 — Inspect & adapt cách estimate. Trong Sprint Retrospective, định kỳ hỏi: cách estimate hiện tại có giúp ích không, hay đang tốn thời gian vô ích? Sẵn sàng đổi technique. Bản thân cách estimate cũng là đối tượng của cải tiến liên tục.
Lỗi thường gặp & mẹo
Lỗi 1 — Tin rằng Scrum bắt buộc Story Points hoặc Planning Poker. Đây là lỗi số một trong PSM I. Hãy nhớ: Scrum Guide không nêu tên bất kỳ technique nào. Nếu một đáp án nói "Scrum yêu cầu dùng story points", nó sai.
Lỗi 2 — Nghĩ Product Owner hoặc Scrum Master estimate. Người làm việc mới estimate, tức Developers. PO chỉ ảnh hưởng qua việc làm rõ trade-off. Scrum Master facilitate, không đưa ra con số.
Lỗi 3 — Quy đổi cứng point sang giờ. Như ví dụ Tiki, điều này phá hỏng bản chất relative và thường dẫn tới lạm dụng. Point đo kích cỡ tương đối, không phải thời gian.
Lỗi 4 — Biến estimate thành commitment cứng. Estimate là forecast dựa trên hiểu biết tại thời điểm đó. Coi nó như lời hứa bất biến sẽ giết chết sự trung thực — Developer sẽ thổi phồng con số để "thủ".
Lỗi 5 — Tưởng #NoEstimates là vi phạm Scrum. Hoàn toàn không. Vì Scrum để ngỏ technique, không estimate bằng point vẫn là Scrum hợp lệ.
Mẹo phòng thi: Khi gặp câu về estimation, hãy tự hỏi "Scrum Guide có thực sự nói điều này không?". Nếu đáp án mô tả một technique cụ thể như bắt buộc, gần như chắc chắn là bẫy. Đáp án "by the book" thường là những câu chung chung: "Developers chọn technique phù hợp", "đội tự quyết", "estimate là trách nhiệm của người làm việc".
Mẹo thực hành: Đừng để cuộc họp estimation kéo dài. Mục tiêu là đủ tốt để forecast, không phải chính xác tuyệt đối. Nếu đội cãi nhau 15 phút về 5 hay 8 point, hãy chọn số lớn hơn và đi tiếp.
Bài tập thực hành
- Phân biệt mandate và technique: Liệt kê ra giấy 5 thứ liên quan estimation và đánh dấu cái nào là Scrum mandate, cái nào chỉ là technique: (a) Developers chịu trách nhiệm sizing, (b) Story Points, (c) Planning Poker, (d) Fibonacci, (e) Product Owner không quyết định con số cuối. Đáp án: a và e là mandate; b, c, d là technique.
- Tình huống quyết định: Bạn là Scrum Master của đội mới toanh ở một công ty Việt Nam, Developer rất ngại con số và sợ bị quy trách nhiệm khi ước lượng sai. Bạn sẽ chọn technique nào để khởi động và vì sao? Viết 4-5 câu lập luận.
- Bắt bẫy đề thi: Tự soạn 2 câu hỏi trắc nghiệm kiểu PSM I về estimation, mỗi câu có một đáp án "nghe đúng theo thực tế nhưng sai theo Scrum Guide". Trao đổi với một bạn học và giải thích vì sao đáp án bẫy lại sai.
- Thử nghiệm tư duy #NoEstimates: Lấy một danh sách 10 công việc bất kỳ trong đời thực (ví dụ chuẩn bị một sự kiện). Thay vì ước lượng giờ, hãy chia chúng thành các đầu việc nhỏ và đều nhau nhất có thể. Bạn cần chia thế nào? Rút ra: vì sao việc chia đều lại quan trọng hơn bản thân con số ước lượng?
Tóm tắt
- Scrum Guide không quy định bất kỳ technique estimation nào. Story Points, Planning Poker, T-shirt sizing, Fibonacci — tất cả đều là technique do đội tự chọn, không phải mandate của Scrum.
- Developers — những người làm việc — là người estimate. Product Owner có thể ảnh hưởng bằng cách làm rõ trade-off nhưng không quyết định con số cuối; Scrum Master chỉ facilitate.
- Story Points là ước lượng tương đối, gói effort + complexity + uncertainty, không phải giờ. Quy đổi cứng point sang giờ là anti-pattern.
- Planning Poker là kỹ thuật cộng tác để lộ ra giả định ẩn; giá trị nằm ở cuộc đối thoại, không chỉ con số. T-shirt sizing hợp cho ước lượng thô và đội mới.
- #NoEstimates là lựa chọn hợp lệ trong Scrum — chia item nhỏ đều nhau rồi đếm throughput. Không estimate bằng point vẫn là Scrum đúng chuẩn.
- Estimate là forecast, không phải commitment cứng, và không bao giờ dùng để đánh giá con người.
- Mẹo thi cốt lõi: nếu một đáp án mô tả một technique cụ thể như bắt buộc, đó gần như chắc chắn là bẫy. Hãy chọn câu trả lời tôn trọng quyền tự quyết của đội.