Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa nhận lời mời họp với CEO. Câu hỏi đầu tiên ông ấy đặt ra: "Tính năng thanh toán trả góp này khi nào xong? Tôi cần biết để chốt với đối tác ngân hàng." Bạn quay sang nhìn đội kỹ thuật, và họ nhún vai: "Khó nói lắm, tùy."
Khoảnh khắc đó chính là lý do bài học này tồn tại. Là một Product Manager, bạn không phải người viết code, không phải người ước tính kỹ thuật chi tiết. Nhưng bạn lại là người đứng giữa: giữa kỳ vọng của ban lãnh đạo, lời hứa với khách hàng, và năng lực thực tế của đội ngũ. Estimation (ước lượng) và Sizing (định cỡ công việc) là kỹ năng giúp bạn biến những câu "tùy" mơ hồ thành những con số có cơ sở để ra quyết định.
Nhiều PM mới vào nghề hiểu sai về estimation. Họ nghĩ đó là việc ép đội kỹ thuật cam kết một ngày cụ thể, rồi dùng con số đó để "quản lý" họ. Đó là cách hiểu nguy hiểm. Estimation đúng nghĩa không phải là lời cam kết cứng, mà là một công cụ giao tiếp và quản trị rủi ro. Nó giúp bạn dự báo lộ trình (roadmap), phân bổ năng lực đội ngũ, phát hiện sớm những phần việc rủi ro, và quan trọng nhất — khơi mào những cuộc trò chuyện cần thiết trước khi quá muộn.
Bài học này sẽ giúp bạn hiểu các phương pháp ước lượng phổ biến, biết khi nào dùng cái nào, và đặc biệt là hiểu vai trò thật sự của một PM trong quá trình này: không phải người ước lượng, mà là người tạo điều kiện để ước lượng diễn ra tốt và sử dụng kết quả một cách khôn ngoan.
Khái niệm cốt lõi
Tại sao chúng ta phải ước lượng?
Trước khi học cách làm, hãy hiểu rõ mục đích. Ước lượng phục vụ bốn mục tiêu chính, và nếu bạn quên mục đích, bạn sẽ dễ sa đà vào việc tìm con số "chính xác" — điều gần như không thể.
Dự báo lộ trình (Forecast roadmap). Khi bạn nói với sếp "tính năng X sẽ ra mắt cuối quý 3", con số đó phải dựa trên ước lượng khối lượng công việc so với năng lực đội ngũ, chứ không phải mong muốn.
Lập kế hoạch năng lực (Plan capacity). Đội bạn có 5 kỹ sư, mỗi sprint hai tuần làm được khoảng 40 điểm công việc. Nếu tính năng mới ước lượng 120 điểm, bạn biết ngay cần khoảng 3 sprint, tức 6 tuần. Không có ước lượng, bạn không thể trả lời câu hỏi "chúng ta nhận thêm việc này được không?"
Phát hiện rủi ro (Identify risks). Đây là giá trị bị xem nhẹ nhất. Một story (hạng mục công việc) được ước lượng quá lớn thường là dấu hiệu của rủi ro: yêu cầu chưa rõ, kỹ thuật phức tạp, hoặc phụ thuộc nhiều bên. Story càng lớn, độ bất định càng cao, sai số càng lớn.
Khơi mào cuộc trò chuyện (Trigger conversations). Khi hai kỹ sư ước lượng cùng một việc, một người nói "2 điểm", người kia nói "13 điểm", đó không phải vấn đề — đó là cơ hội vàng. Sự chênh lệch tiết lộ rằng hai người đang hiểu yêu cầu theo hai cách khác nhau. Cuộc tranh luận để thống nhất chính là phần giá trị nhất của estimation.
Phân biệt Estimation và Sizing
Hai khái niệm này thường bị dùng lẫn lộn, nhưng có sự khác biệt tinh tế.
Sizing là việc định cỡ tương đối — so sánh các hạng mục với nhau. Việc A "to gấp đôi" việc B, không cần biết chính xác mất bao nhiêu giờ. Sizing trả lời câu hỏi "lớn hay nhỏ?".
Estimation thường gắn với dự báo thời gian hoặc nỗ lực cụ thể hơn — "việc này khoảng 3 ngày công". Estimation trả lời câu hỏi "bao lâu, bao nhiêu?".
Trong thực hành Agile hiện đại, nhiều đội ưu tiên sizing tương đối (qua Story Points) thay vì estimation theo giờ tuyệt đối, vì con người dở trong việc đoán thời gian tuyệt đối nhưng giỏi trong việc so sánh tương đối. Bạn khó nói chính xác quãng đường từ nhà đến công ty bao nhiêu mét, nhưng dễ dàng nói nó xa gấp ba lần quãng đường ra quán cà phê đầu ngõ.
Các đơn vị ước lượng phổ biến
Story Points (Điểm câu chuyện). Đây là đơn vị trừu tượng đo độ "lớn" tổng hợp của một hạng mục, kết hợp ba yếu tố: khối lượng công việc, độ phức tạp, và độ bất định/rủi ro. Story Points thường dùng dãy Fibonacci (1, 2, 3, 5, 8, 13, 21) vì khoảng cách giữa các số lớn dần phản ánh đúng thực tế: càng việc lớn, ta càng khó ước lượng chính xác, nên không có nghĩa lý gì để phân biệt một việc "37 điểm" với "38 điểm".
T-shirt Sizing (Định cỡ áo thun). Dùng các cỡ XS, S, M, L, XL. Cực kỳ hữu ích ở giai đoạn sớm, khi bạn cần định cỡ thô cho nhiều ý tưởng trên roadmap mà chưa cần độ chi tiết. PM rất hay dùng cách này khi làm việc với lãnh đạo: "Tính năng chat realtime là cỡ L, còn đổi màu nút bấm là cỡ XS."
Ideal days / Person-days (Ngày công lý tưởng). Ước lượng theo số ngày làm việc nếu không bị gián đoạn. Dễ hiểu với người ngoài kỹ thuật nhưng dễ gây hiểu lầm, vì "ngày lý tưởng" hiếm khi bằng ngày thực tế do họp hành, gián đoạn, hỗ trợ lẫn nhau.
Velocity và cách dùng để dự báo
Velocity (Vận tốc) là tổng số Story Points đội hoàn thành trung bình mỗi sprint. Nếu đội bạn có velocity ổn định 40 điểm/sprint, và backlog cho tính năng mới là 160 điểm, bạn dự báo cần khoảng 4 sprint. Đây là công cụ dự báo mạnh nhất của PM — nhưng chỉ đáng tin khi velocity đã ổn định qua nhiều sprint và đội ngũ không thay đổi nhiều.
Một lưu ý đạo đức quan trọng: Velocity là công cụ dự báo, KHÔNG phải thước đo hiệu suất để so sánh giữa các đội hay để gây áp lực. Khoảnh khắc bạn dùng velocity để ép đội "chạy nhanh hơn", họ sẽ lập tức "thổi phồng" điểm số và mọi giá trị dự báo sụp đổ.
Vì sao dùng số tương đối thay vì giờ tuyệt đối?
Con người nổi tiếng dở trong việc ước lượng thời gian tuyệt đối — đây gọi là "planning fallacy" (ngụy biện lập kế hoạch), xu hướng luôn lạc quan thái quá về thời gian hoàn thành. Nhưng chúng ta lại khá giỏi so sánh tương đối. Story Points khai thác chính điểm mạnh này. Thêm nữa, điểm tương đối tách rời con số khỏi cá nhân: một việc "5 điểm" là 5 điểm dù bạn senior hay junior làm, tránh được áp lực cam kết theo giờ cá nhân.
Tình huống thực tế
Ví dụ 1: Đội thanh toán tại một ví điện tử Việt Nam và buổi Planning Poker cứu nguy
Một ví điện tử lớn tại Việt Nam (giả định gọi là "PayViet") chuẩn bị làm tính năng "chia hóa đơn" cho nhóm bạn. PM ban đầu nhìn qua thấy đơn giản, ước lượng nội bộ "khoảng 1 tuần" và lỡ hứa với ban giám đốc.
Khi đội thực hành Planning Poker — kỹ thuật mỗi người giơ thẻ điểm ẩn cùng lúc rồi lật ra — kết quả gây sốc: ba kỹ sư cho 3 điểm, nhưng một kỹ sư backend giơ 13 điểm. Khi được hỏi vì sao, anh giải thích: chia hóa đơn đòi hỏi xử lý giao dịch chia tách, đối soát khi một người không trả, thông báo đẩy cho nhiều người, và xử lý hoàn tiền khi hủy — toàn bộ đều chạm vào hệ thống tài chính lõi cần kiểm toán chặt chẽ.
Ba kỹ sư kia chỉ nghĩ đến giao diện chia tiền, quên mất phần backend giao dịch. Cuộc trò chuyện 15 phút đó tiết lộ rằng "1 tuần" của PM hoàn toàn không thực tế — con số thực gần 4 tuần.
Bài học rút ra: Giá trị lớn nhất của Planning Poker không phải con số cuối cùng, mà là sự chênh lệch buộc cả đội phải nói ra những giả định ngầm. Nếu PM cứ áp đặt "1 tuần", dự án chắc chắn trễ và niềm tin với ban lãnh đạo bị xói mòn. Nhờ ước lượng đúng cách, PM kịp quay lại điều chỉnh kỳ vọng trước khi quá muộn.
Ví dụ 2: Grab và T-shirt Sizing cho roadmap quý
Hãy hình dung đội sản phẩm tại một super app như Grab đang lên kế hoạch quý. Họ có 12 ý tưởng tính năng nhưng chỉ đủ năng lực làm 4-5 cái. Ở giai đoạn này, ngồi ước lượng từng Story Point cho cả 12 ý tưởng là lãng phí — nhiều ý tưởng sẽ bị loại bỏ.
PM tổ chức một buổi định cỡ áo thun nhanh. "Tích hợp đặt vé xem phim" — cỡ XL (chạm nhiều đối tác bên ngoài). "Thêm bộ lọc món chay trong GrabFood" — cỡ S. "Đổi giao diện màn hình chính" — cỡ M. Chỉ trong một buổi sáng, cả đội định cỡ thô được toàn bộ 12 ý tưởng.
Kết quả: PM phát hiện ba ý tưởng "cỡ XL" có giá trị kinh doanh không tương xứng với chi phí, liền gạt khỏi quý này. Họ tập trung vào hai cỡ S và một cỡ M có tỷ lệ giá trị/chi phí cao nhất.
Bài học rút ra: Độ chính xác của ước lượng phải tương xứng với giai đoạn ra quyết định. Ở mức roadmap, T-shirt Sizing "đủ tốt" và nhanh gấp nhiều lần. Đừng dùng kính hiển vi khi bạn chỉ cần một cái nhìn tổng quan từ trên cao. Ước lượng chi tiết chỉ nên diễn ra khi hạng mục đã gần được đưa vào sprint.
Ví dụ 3: Story quá lớn và quyết định "chẻ nhỏ" tại một startup SaaS
Một startup SaaS B2B ở TP.HCM (giả định "DocFlow") có một story trong backlog: "Xây dựng module báo cáo cho khách hàng doanh nghiệp". Khi ước lượng, cả đội đồng loạt cho 21 điểm — con số lớn nhất trong dãy. Theo nguyên tắc, bất kỳ story nào vượt quá 13 điểm đều là tín hiệu cảnh báo: quá lớn để hiểu rõ, quá rủi ro để cam kết.
Thay vì chấp nhận con số đó, PM cùng đội ngồi lại "chẻ nhỏ" (slicing) story này. Họ tách thành: "Báo cáo doanh thu cơ bản dạng bảng" (5 điểm), "Bộ lọc theo khoảng thời gian" (3 điểm), "Xuất file Excel" (3 điểm), "Biểu đồ trực quan" (8 điểm), và "Lập lịch gửi báo cáo tự động qua email" (8 điểm).
Khi chẻ ra, một điều thú vị xảy ra: PM nhận ra phần "biểu đồ trực quan" và "gửi tự động" — chiếm 16 trong tổng 27 điểm — thực ra khách hàng ít cần gấp. Đội quyết định ra mắt phiên bản đầu chỉ với báo cáo bảng, bộ lọc và xuất Excel (11 điểm), thu thập phản hồi rồi mới làm tiếp.
Bài học rút ra: Một ước lượng lớn không phải để bạn nuốt trọn, mà là tín hiệu để dừng lại và đặt câu hỏi. Việc chẻ nhỏ story không chỉ giảm rủi ro ước lượng mà còn mở ra cơ hội cắt giảm phạm vi (scope) và ra mắt sớm hơn. Tổng các phần nhỏ (27 điểm) thường lớn hơn ước lượng gộp ban đầu (21 điểm) — đó là bằng chứng cho thấy ước lượng gộp đã đánh giá thấp độ phức tạp tiềm ẩn.
Hướng dẫn từng bước
Dưới đây là quy trình một PM có thể áp dụng để chạy một buổi ước lượng hiệu quả với đội.
Bước 1 — Chuẩn bị backlog rõ ràng trước buổi họp. Đừng mang những hạng mục mơ hồ ra để ước lượng. Mỗi hạng mục nên có mô tả ngắn, tiêu chí hoàn thành (acceptance criteria) sơ bộ. Là PM, đây là phần việc của bạn: ước lượng chỉ tốt khi đầu vào rõ ràng. "Rác vào, rác ra."
Bước 2 — Thiết lập điểm tham chiếu (reference point). Trước khi ước lượng, hãy cùng đội chọn một hạng mục đã quen thuộc làm chuẩn. Ví dụ: "Việc thêm một trường nhập liệu vào form đăng ký — chúng ta thống nhất đây là 2 điểm." Mọi ước lượng sau đó so với điểm chuẩn này. Không có điểm tham chiếu, các con số trở nên vô nghĩa.
Bước 3 — Để đội kỹ thuật ước lượng, không phải bạn. Đây là nguyên tắc thép. Người làm việc là người ước lượng. Vai trò PM là làm rõ yêu cầu, trả lời câu hỏi về "cái gì" và "tại sao", nhưng tuyệt đối không áp con số "cái này nên là 3 điểm". Bạn áp số là bạn phá hỏng toàn bộ giá trị.
Bước 4 — Dùng Planning Poker hoặc giơ thẻ đồng thời. Mỗi người ước lượng độc lập rồi cùng lật ra một lúc. Cách này tránh hiệu ứng "mỏ neo" (anchoring) — khi người đầu tiên nói "5 điểm", mọi người sau có xu hướng bám theo thay vì suy nghĩ độc lập.
Bước 5 — Đào sâu vào sự chênh lệch. Khi có người 3 điểm, người 13 điểm, đừng vội lấy trung bình. Hãy hỏi cả hai giải thích. Đây là khoảnh khắc vàng để phát hiện hiểu lầm về yêu cầu hoặc rủi ro kỹ thuật ẩn.
Bước 6 — Phát hiện story quá lớn và chẻ nhỏ. Bất kỳ hạng mục nào vượt 13 điểm (hoặc cỡ XL), hãy coi đó là tín hiệu để tách nhỏ. Story nhỏ luôn dễ ước lượng chính xác hơn, dễ giao hơn, và cho phép ra mắt linh hoạt hơn.
Bước 7 — Theo dõi velocity qua thời gian và dùng nó để dự báo. Sau vài sprint, ghi nhận velocity trung bình. Dùng nó để trả lời câu hỏi roadmap: "Với backlog 200 điểm và velocity 40, ta cần khoảng 5 sprint, tức 10 tuần."
Bước 8 — Truyền đạt ước lượng dưới dạng khoảng, không phải điểm chết. Khi báo cáo lên trên, đừng nói "ra mắt ngày 15/8". Hãy nói "khả năng cao trong khoảng nửa cuối tháng 8". Ước lượng vốn có độ bất định; truyền đạt nó như sự thật tuyệt đối là tự đặt bẫy cho chính mình.
Lỗi thường gặp & mẹo
Lỗi 1: PM tự ước lượng thay đội kỹ thuật. Đây là sai lầm phổ biến nhất và tai hại nhất. Bạn không viết code, bạn không thấy được độ phức tạp kỹ thuật ẩn. Mẹo: hãy luôn tự nhắc "việc của tôi là làm rõ CÁI GÌ, việc của họ là ước lượng BAO LÂU".
Lỗi 2: Coi ước lượng là cam kết cứng (deadline). Khi bạn biến một ước lượng thành lời hứa sắt đá rồi trừng phạt khi trễ, đội sẽ học cách "thổi phồng" mọi con số để tự bảo vệ. Mẹo: tách biệt rõ ràng giữa "ước lượng" (dự báo có sai số) và "cam kết" (lời hứa cho một phạm vi đã chốt).
Lỗi 3: Quy đổi Story Points thẳng ra giờ/tiền. "5 điểm = 5 ngày = bao nhiêu triệu" — cách nghĩ này phá hỏng bản chất tương đối của Story Points và tạo áp lực sai. Mẹo: dùng velocity để dự báo ở cấp độ tập hợp nhiều story, đừng quy đổi từng story lẻ.
Lỗi 4: So sánh velocity giữa các đội. Mỗi đội có thang điểm riêng; "40 điểm" của đội A không bằng "40 điểm" của đội B. Dùng nó để xếp hạng đội là vừa sai về kỹ thuật vừa độc hại về văn hóa.
Lỗi 5: Bỏ qua độ bất định. Ước lượng cho một việc đã làm 10 lần khác hẳn việc chưa từng làm. Mẹo: với những việc nhiều bất định, hãy đề xuất một "spike" — một khoảng thời gian giới hạn để nghiên cứu, giảm rủi ro trước khi ước lượng thật.
Mẹo vàng: Hãy đối xử với ước lượng như một dự báo thời tiết, không phải một lời tiên tri. Dự báo thời tiết nói "70% khả năng mưa" — hữu ích để bạn mang ô, nhưng không ai trừng phạt đài khí tượng nếu trời không mưa. Đó chính là tinh thần đúng đắn của estimation.
Bài tập thực hành
Bài tập 1 — Định cỡ áo thun cho roadmap. Hãy lấy 5 tính năng giả định cho một ứng dụng giao đồ ăn (ví dụ: thêm đánh giá món ăn, tích hợp ví trả góp, chế độ tối, gợi ý món bằng AI, theo dõi tài xế realtime). Tự định cỡ XS đến XL cho từng cái và viết một câu lý giải vì sao. Mục tiêu: tập phản xạ định cỡ thô nhanh.
Bài tập 2 — Chẻ nhỏ một story lớn. Lấy story "Xây dựng tính năng chat hỗ trợ khách hàng trong ứng dụng". Hãy chẻ nó thành ít nhất 5 story con nhỏ hơn, mỗi cái đủ nhỏ để ước lượng không quá 8 điểm. Sau đó, đánh dấu xem story con nào thực sự cần cho phiên bản đầu tiên (MVP) và cái nào có thể để sau.
Bài tập 3 — Tính dự báo từ velocity. Đội của bạn có velocity trung bình 35 điểm/sprint (sprint hai tuần). Backlog tính năng mới là 175 điểm. Hãy tính số sprint và số tuần cần thiết. Sau đó viết một câu thông báo cho ban lãnh đạo, truyền đạt mốc thời gian dưới dạng khoảng (không phải ngày chết).
Bài tập 4 — Phân tích chênh lệch. Tưởng tượng trong buổi Planning Poker, một story nhận điểm: 2, 3, 3, 13. Viết ra ba câu hỏi bạn — với vai trò PM — sẽ đặt cho người cho 13 điểm và người cho 2 điểm để làm rõ sự chênh lệch.
Tóm tắt
Estimation và Sizing không phải là nghệ thuật đoán con số chính xác, mà là công cụ để dự báo lộ trình, lập kế hoạch năng lực, phát hiện rủi ro, và khơi mào những cuộc trò chuyện quan trọng. Là PM, vai trò của bạn không phải người ước lượng — đó là việc của đội kỹ thuật — mà là người làm rõ yêu cầu, tạo điều kiện cho buổi ước lượng diễn ra tốt, và sử dụng kết quả một cách khôn ngoan.
Hãy ghi nhớ những điểm cốt lõi: dùng số tương đối (Story Points, T-shirt Sizing) thay vì giờ tuyệt đối vì con người giỏi so sánh hơn đoán thời gian; chọn độ chi tiết ước lượng phù hợp với giai đoạn ra quyết định; coi story quá lớn là tín hiệu để chẻ nhỏ chứ không phải để nuốt trọn; dùng velocity để dự báo nhưng đừng biến nó thành thước đo hiệu suất hay vũ khí gây áp lực; và luôn truyền đạt ước lượng như một dự báo có độ bất định, không phải lời cam kết sắt đá.
Khi lần sau CEO hỏi "khi nào xong?", bạn sẽ không còn nhún vai nói "tùy". Bạn sẽ có một câu trả lời có cơ sở, kèm theo sự trung thực về độ bất định — và đó chính là dấu hiệu của một PM trưởng thành.