Mở đầu — vì sao bài này quan trọng
Có một câu hỏi mà gần như Scrum Master nào cũng từng bị "dí" trong phòng họp: "Story point đổi ra mấy giờ vậy em?" Câu hỏi nghe có vẻ vô hại, nhưng nó là dấu hiệu rõ ràng nhất cho thấy tổ chức đang đứng ở đâu trên thang trưởng thành về estimation (ước lượng). Một Scrum Master ở cấp độ PSM I có thể trả lời "story point không phải là giờ ạ" rồi để đó. Nhưng ở cấp độ PSM II — cấp độ mà chúng ta đang hướng tới — bạn phải hiểu vì sao tổ chức lại hỏi như vậy, họ đang ở giai đoạn trưởng thành nào, và làm thế nào để dẫn dắt họ đi lên mà không gây ra phản kháng.
Estimation không phải là mục tiêu của Scrum. Nó là một công cụ phục vụ cho việc lập kế hoạch và quản lý rủi ro. Nhưng cách một team ước lượng phản ánh rất chính xác mức độ tin cậy, mức độ tự chủ và mức độ trưởng thành về tư duy của cả tổ chức. Một team mới chuyển đổi từ Waterfall thường bám chặt vào "giờ công" vì đó là thứ duy nhất họ biết để đo lường. Một team trưởng thành hơn dùng story point để nói về độ phức tạp tương đối. Và một số ít team đạt đến đỉnh cao thì gần như không cần ước lượng chi tiết nữa — họ dựa vào dữ liệu dòng chảy thực tế.
Bài học này giúp bạn nhìn estimation như một hành trình trưởng thành (maturity journey), chứ không phải một kỹ thuật cố định. Khi bạn hiểu được bản đồ này, bạn sẽ biết cách "đọc vị" team mình đang ở đâu và chọn đúng can thiệp tiếp theo — đây chính là tư duy chẩn đoán (diagnosis) đặc trưng của một Scrum Master cấp cao.
Khái niệm cốt lõi
Estimation maturity là gì?
Estimation maturity là mức độ trưởng thành trong cách một team (và rộng hơn là tổ chức) tiếp cận việc ước lượng công việc. Nó không đo bằng việc team ước lượng chính xác đến đâu, mà đo bằng việc mục đích của ước lượng được hiểu đúng đến đâu, và team có dùng đúng công cụ cho đúng bối cảnh hay không.
Một sai lầm phổ biến là nghĩ rằng "trưởng thành = ước lượng càng chính xác càng tốt". Thực ra ngược lại: team càng trưởng thành thì càng bớt lệ thuộc vào độ chính xác của từng con số, và càng chú trọng vào tính dự đoán được (predictability) của cả hệ thống.
Các giai đoạn trưởng thành về estimation
Hãy hình dung một thang gồm bốn bậc. Không phải team nào cũng cần leo lên tới đỉnh, nhưng biết mình đang ở đâu là điều quan trọng.
Giai đoạn 1 — Ước lượng theo giờ (Hours / task-level estimates). Đây là di sản trực tiếp từ Waterfall. Mỗi task được gán một con số giờ cụ thể: "viết API này mất 6 tiếng", "test màn hình kia mất 3 tiếng". Manager cộng hết lại ra tổng giờ, chia cho số người, ra deadline. Cách này có vẻ trực quan và dễ giải thích cho cấp trên, nhưng nó có vài nhược điểm chí mạng. Thứ nhất, con người ước lượng giờ rất tệ — nghiên cứu cho thấy chúng ta thường lạc quan thái quá (planning fallacy). Thứ hai, giờ là con số tuyệt đối, không tính đến việc người làm là junior hay senior. Thứ ba, và quan trọng nhất với Scrum: ước lượng giờ tạo áp lực biến estimate thành commitment (cam kết), khiến team sợ sai và bắt đầu "phòng thủ" bằng cách thổi phồng con số.
Trong Scrum, ước lượng giờ vẫn có một chỗ đứng hợp pháp: ở mức task trong Sprint Backlog, nhiều team dùng giờ để tự kiểm tra xem một Product Backlog Item có vừa với Sprint hay không. Đây là việc nội bộ của Developers, hoàn toàn ổn. Vấn đề chỉ phát sinh khi giờ trở thành đơn vị giao tiếp với bên ngoài và bị dùng để đánh giá hiệu suất.
Giai đoạn 2 — Story point (relative sizing). Bước nhảy quan trọng đầu tiên là chuyển từ tuyệt đối (giờ) sang tương đối (point). Thay vì hỏi "việc này mất bao lâu?", team hỏi "việc này lớn cỡ nào so với việc kia?". Story point gói gọn ba yếu tố: khối lượng công việc, độ phức tạp, và độ bất định/rủi ro. Team thường dùng dãy Fibonacci (1, 2, 3, 5, 8, 13...) để phản ánh thực tế rằng việc càng lớn thì ước lượng càng kém chắc chắn.
Ưu điểm lớn nhất của story point là nó tách rời ước lượng khỏi con người cụ thể và khỏi áp lực thời gian. Một item 5 point là 5 point dù junior hay senior làm; thời gian thực tế khác nhau, nhưng "kích thước" thì không đổi. Qua nhiều Sprint, team tích lũy được velocity (số point hoàn thành trung bình mỗi Sprint), từ đó có thể dự báo (forecast) một cách tương đối cho việc lập kế hoạch dài hơi hơn.
Cạm bẫy ở giai đoạn này là tổ chức bắt đầu lạm dụng velocity như một thước đo năng suất, ép team "tăng velocity" — điều này lập tức làm hỏng tính trung thực của story point vì team sẽ chỉ việc thổi point lên.
Giai đoạn 3 — Right-sizing và flow metrics (đo bằng dòng chảy). Khi team đã thuần thục relative sizing, nhiều team trưởng thành nhận ra một điều thú vị: phần lớn các item sau khi refinement tốt đều rơi vào cỡ "nhỏ và gần đều nhau". Lúc này, thay vì tranh luận 3 point hay 5 point, team chuyển sang right-sizing — chỉ cần xác định item có đủ nhỏ để hoàn thành trong vài ngày hay không. Họ bắt đầu quan tâm đến các flow metrics như throughput (số item hoàn thành mỗi tuần) và cycle time (thời gian từ lúc bắt đầu đến lúc xong một item). Đây là cửa ngõ dẫn sang tư duy của Kanban và Lean.
Giai đoạn 4 — #NoEstimates / probabilistic forecasting (dự báo xác suất). Ở đỉnh cao, một số team gần như bỏ ước lượng chi tiết. Họ tách item thành các đơn vị đủ nhỏ và tương đối đồng đều, rồi dùng dữ liệu lịch sử (throughput) cùng mô phỏng Monte Carlo để trả lời câu hỏi kinh doanh thực sự: "Với 80% xác suất, 40 việc còn lại sẽ xong trước ngày nào?". Cách này không hề "vô kỷ luật" — ngược lại nó đòi hỏi kỷ luật rất cao về việc chia nhỏ công việc và thu thập dữ liệu. Nó trả lời đúng câu hỏi mà lãnh đạo cần, bằng ngôn ngữ xác suất thay vì một con số giả vờ chắc chắn.
Vai trò của Scrum Master trong hành trình này
Lưu ý cực kỳ quan trọng cho kỳ thi PSM II và cho thực tế: Scrum không quy định kỹ thuật ước lượng nào. Scrum Guide chỉ nói Product Backlog Item cần được "kích cỡ" (sized) bởi Developers, và Developers là người chịu trách nhiệm về estimate. Story point, planning poker, t-shirt sizing... đều là kỹ thuật bổ trợ, không phải luật. Vai trò của Scrum Master không phải là áp đặt một kỹ thuật, mà là giúp team chọn công cụ phù hợp với mức trưởng thành của họ và bảo vệ tính trung thực của estimate khỏi sự lạm dụng của tổ chức.
Tình huống thực tế
Tình huống 1 — Công ty fintech ở TP.HCM và cú chuyển từ giờ sang point
Một công ty fintech khoảng 120 người tại TP.HCM (gọi là VPay) vừa chuyển từ mô hình dự án Waterfall sang Scrum. Trong ba Sprint đầu, các team vẫn ước lượng mọi thứ bằng giờ vì PMO yêu cầu báo cáo "man-hours" hằng tuần lên ban giám đốc. Kết quả: Developers dành gần nửa buổi Sprint Planning để cãi nhau "task này 4 tiếng hay 6 tiếng", và gần như Sprint nào cũng "trượt" so với tổng giờ đã cam kết, khiến ban giám đốc mất niềm tin vào Agile.
Scrum Master mới về phân tích và nhận ra vấn đề không nằm ở năng lực team, mà ở chỗ tổ chức đang kẹt ở Giai đoạn 1. Anh không ép đổi ngay sang story point — điều đó sẽ vấp phải PMO. Thay vào đó, anh làm hai việc song song. Với team, anh giới thiệu planning poker và relative sizing trong nội bộ Sprint Planning. Với PMO, anh vẫn cung cấp một bản quy đổi tham khảo trong vài Sprint đầu để giữ niềm tin, đồng thời bắt đầu trình bày biểu đồ velocity ổn định dần. Sau khoảng sáu Sprint, velocity của một team dao động quanh 32-38 point khá ổn định, và anh dùng chính sự ổn định đó để thuyết phục ban giám đốc rằng "predictability" mới là thứ đáng tin, chứ không phải tổng giờ. PMO dần bỏ yêu cầu báo cáo man-hours.
Bài học rút ra: Trưởng thành về estimation là một cuộc chuyển đổi tổ chức, không chỉ là dạy team một kỹ thuật mới. Đừng đập bỏ thước đo cũ ngay lập tức; hãy xây niềm tin vào thước đo mới song song rồi mới thay thế.
Tình huống 2 — Velocity bị biến thành KPI ở một công ty gia công Đông Nam Á
Một công ty outsourcing có văn phòng ở Hà Nội và Manila (gọi là TechBridge) rơi vào cái bẫy kinh điển của Giai đoạn 2. Một giám đốc kỹ thuật ra quy định: mỗi team phải tăng velocity 10% mỗi quý, và velocity được đưa vào đánh giá performance cuối năm. Chỉ sau hai quý, velocity báo cáo của các team đều tăng đẹp như mơ — nhưng số bug production cũng tăng, còn khách hàng phàn nàn tiến độ thực tế chẳng nhanh hơn.
Chuyện gì đã xảy ra? Các team đơn giản là lạm phát point. Việc trước đây 3 point giờ thành 5, việc 5 point thành 8. Con số đẹp lên nhưng giá trị giao cho khách thì không. Đây là biểu hiện sống động của định luật Goodhart: "khi một thước đo trở thành mục tiêu, nó không còn là thước đo tốt nữa".
Scrum Master cùng Agile Coach đã can thiệp bằng cách trình bày dữ liệu cho lãnh đạo: vẽ song song velocity (đang tăng) với cycle time và số defect (đang xấu đi), cho thấy rõ velocity tăng nhưng kết quả thực không cải thiện. Họ đề xuất chuyển trọng tâm đo lường từ velocity sang các thước đo kết quả như cycle time, tỷ lệ hoàn thành Sprint Goal và mức độ hài lòng của khách hàng. Velocity được trả về đúng vai trò ban đầu: công cụ nội bộ để team tự forecast, tuyệt đối không phải KPI.
Bài học rút ra: Story point chỉ trung thực khi nó không bị gắn với phần thưởng hay hình phạt. Một trong những nhiệm vụ quan trọng nhất của Scrum Master là bảo vệ estimate khỏi bị vũ khí hóa.
Tình huống 3 — Một team thương mại điện tử "tốt nghiệp" lên flow metrics
Một team sản phẩm trong một công ty thương mại điện tử tại Singapore đã dùng story point thuần thục suốt hai năm. Đến một lúc, Scrum Master nhận thấy mỗi Sprint Planning, planning poker gần như luôn cho ra cùng kết quả: hầu hết item là 2 hoặc 3 point, rất hiếm item lớn vì refinement đã quá tốt. Việc tranh luận point bắt đầu trở thành nghi thức tốn thời gian mà không tạo thêm giá trị.
Scrum Master đề xuất một thử nghiệm: ngừng chấm point, thay vào đó chỉ cần đảm bảo mỗi item được chia nhỏ đến mức có thể xong trong tối đa hai ngày (right-sizing), rồi theo dõi throughput và cycle time. Sau bốn Sprint, team thu thập đủ dữ liệu và bắt đầu dùng mô phỏng Monte Carlo trên throughput lịch sử để trả lời câu hỏi của Product Owner: "tính năng thanh toán mới có kịp cho mùa sale tháng 11 không?". Câu trả lời giờ là "85% khả năng xong trước 5/11" — hữu ích hơn nhiều so với một con số point cộng dồn.
Bài học rút ra: Trưởng thành đôi khi nghĩa là bỏ bớt công cụ chứ không phải thêm. Khi việc ước lượng chi tiết không còn tạo giá trị, một Scrum Master giỏi dám đặt câu hỏi "liệu chúng ta có cần làm việc này nữa không?".
Hướng dẫn từng bước
Đây là quy trình để bạn chẩn đoán và nâng cấp mức trưởng thành estimation cho team mình.
Bước 1 — Chẩn đoán hiện trạng. Quan sát ba dấu hiệu: team đang dùng đơn vị gì (giờ / point / không gì cả), estimate đang được dùng để làm gì (lập kế hoạch nội bộ hay báo cáo/đánh giá), và ai đang gây áp lực lên con số. Ánh xạ team vào một trong bốn giai đoạn ở trên.
Bước 2 — Xác định "nỗi đau" thực sự. Đừng nâng cấp chỉ vì thích. Hỏi: vấn đề hiện tại là gì? Planning quá dài? Forecast không đáng tin? Velocity bị lạm dụng? Mỗi nỗi đau dẫn tới một can thiệp khác nhau.
Bước 3 — Tách bạch estimate và commitment. Trước khi đổi kỹ thuật, hãy gieo tư duy: estimate là dự đoán có sai số, không phải lời hứa. Đây là nền tảng tâm lý cho mọi bước tiếp theo.
Bước 4 — Chọn can thiệp tối thiểu. Nếu team ở Giai đoạn 1 và đau vì planning dài, giới thiệu relative sizing với planning poker. Nếu ở Giai đoạn 2 và đau vì velocity bị lạm dụng, làm việc với lãnh đạo để đổi thước đo. Nếu ở Giai đoạn 2 mà item đã đều, thử nghiệm right-sizing.
Bước 5 — Đầu tư vào refinement. Mọi giai đoạn trưởng thành đều phụ thuộc vào việc chia nhỏ Product Backlog Item tốt. Item nhỏ và rõ ràng làm cho ước lượng dễ hơn, và ở cấp cao thì gần như xóa bỏ nhu cầu ước lượng.
Bước 6 — Thu thập và trực quan hóa dữ liệu. Bắt đầu theo dõi velocity, throughput, cycle time. Dữ liệu là vũ khí thuyết phục lãnh đạo mạnh hơn mọi lý lẽ.
Bước 7 — Thử nghiệm, không cách mạng. Áp dụng tư duy thực nghiệm của Scrum: thử một thay đổi trong vài Sprint, dùng Retrospective để kiểm tra, giữ nếu tốt, bỏ nếu không.
Lỗi thường gặp & mẹo
Lỗi: Quy đổi story point ra giờ. Đây là sai lầm phổ biến nhất và làm hỏng toàn bộ ý nghĩa của relative sizing. Khi đã quy đổi, point chẳng khác gì giờ ngụy trang. Mẹo: nếu lãnh đạo cần thời gian, hãy nói chuyện bằng forecast dựa trên velocity ("khoảng 4-5 Sprint"), đừng quy đổi từng item.
Lỗi: Coi velocity là thước đo năng suất. Velocity của hai team không thể so sánh, và ép tăng velocity sẽ gây lạm phát point. Mẹo: chỉ dùng velocity nội bộ cho forecast của chính team đó.
Lỗi: Nhầm "trưởng thành" với "chính xác". Đuổi theo độ chính xác tuyệt đối của estimate là cuộc chơi thua. Mẹo: chuyển mục tiêu từ "đúng" sang "dự đoán được".
Lỗi: Manager hoặc Scrum Master tự ước lượng thay Developers. Vi phạm trực tiếp Scrum Guide. Người làm việc là người ước lượng. Mẹo: Scrum Master chỉ facilitate, không bao giờ áp con số.
Lỗi: Nhảy cóc giai đoạn. Đẩy một team Waterfall thẳng lên #NoEstimates sẽ gây hỗn loạn. Mẹo: tôn trọng thứ tự trưởng thành, mỗi bước cần thời gian thấm.
Mẹo bổ sung: Dùng t-shirt sizing (S/M/L) cho refinement ở cấp cao và cho các item lớn chưa rõ ràng — nó nhanh và đủ tốt để ưu tiên, không cần xuống tới con số.
Bài tập thực hành
- Chẩn đoán team của bạn. Viết ra: team đang dùng đơn vị ước lượng gì, estimate đang được dùng vào việc gì, và ai gây áp lực lên con số. Xác định team đang ở giai đoạn nào trong bốn giai đoạn.
- Phát hiện lạm dụng. Liệt kê mọi nơi trong tổ chức mà velocity hoặc giờ công đang được dùng để đánh giá, so sánh hay khen thưởng. Với mỗi trường hợp, viết một câu bạn sẽ nói với lãnh đạo để tái định hướng về thước đo kết quả.
- Soạn kịch bản trả lời. Viết ba câu trả lời cho câu hỏi "story point đổi ra mấy giờ?" — một câu cho lãnh đạo nóng vội, một cho Product Owner, một cho một Developer mới. Mỗi câu phải vừa giữ được tính trung thực của estimate vừa không gây phòng thủ.
- Lập kế hoạch nâng cấp một bậc. Chọn một nỗi đau cụ thể của team, đề xuất một thử nghiệm kéo dài 3 Sprint để nâng team lên giai đoạn kế tiếp, và xác định trước thước đo nào cho biết thử nghiệm thành công.
Tóm tắt
Estimation maturity là một hành trình bốn bậc: từ ước lượng theo giờ (di sản Waterfall), lên story point và relative sizing, rồi tới right-sizing với flow metrics, và cuối cùng là dự báo xác suất gần như không cần ước lượng chi tiết. Điều quan trọng nhất cần nhớ: trưởng thành không có nghĩa là ước lượng chính xác hơn, mà là dự đoán được hơn và hiểu đúng mục đích của ước lượng.
Scrum không bắt buộc bất kỳ kỹ thuật ước lượng nào — đó luôn là lựa chọn của Developers. Vai trò của một Scrum Master cấp PSM II không phải là áp đặt công cụ, mà là chẩn đoán team đang ở đâu, chọn can thiệp tối thiểu phù hợp, và quan trọng nhất là bảo vệ tính trung thực của estimate khỏi bị tổ chức vũ khí hóa thành KPI. Khi bạn nhìn estimation như một tấm gương phản chiếu mức độ tin cậy và tự chủ của tổ chức, bạn sẽ biết chính xác bước tiếp theo cần dẫn dắt team đi tới đâu.