Mở đầu — vì sao bài này quan trọng
Nếu bạn đã từng tham gia một dự án phần mềm, chắc hẳn bạn đã nghe câu hỏi quen thuộc: "Cái này làm bao lâu xong?" Và bạn cũng đã chứng kiến những lời hứa kiểu "ba ngày nữa em xong" rồi… ba tuần sau vẫn chưa xong. Ước lượng (estimation) là một trong những nỗi đau kinh điển nhất của quản lý dự án, và Agile đưa ra một cách tiếp cận khác hẳn truyền thống: thay vì cố đoán chính xác số giờ, ta ước lượng kích thước tương đối của công việc bằng một đơn vị gọi là Story Points, và làm việc đó tập thể qua một trò chơi gọi là Planning Poker.
Đây không phải chuyện kỹ thuật vặt vãnh. Story Points là nền tảng để bạn tính velocity (bài 23), lập kế hoạch release (bài 22), và quan trọng nhất: chúng định hình cách team nói chuyện với nhau về độ phức tạp công việc. Một team ước lượng tốt là một team hiểu rõ công việc của mình; một team ước lượng tồi thường là một team chưa thật sự hiểu mình đang làm gì. Hiểu đúng Story Points và biết cách facilitate Planning Poker là một trong những kỹ năng "đáng tiền" nhất mà một PM hay Scrum Master cần có. Bài này sẽ giúp bạn nắm chắc cả tư duy lẫn cách thực hành.
Khái niệm cốt lõi
Story Points là gì — và vì sao không dùng giờ?
Story Points là đơn vị trừu tượng dùng để biểu thị kích thước tương đối (relative size) của một hạng mục công việc — thường là một user story. "Tương đối" nghĩa là: ta không nói "việc này mất 8 giờ", mà nói "việc này lớn gấp đôi việc kia".
Tại sao không dùng giờ? Có ba lý do sâu sắc:
Thứ nhất, con người ước lượng tương đối giỏi hơn ước lượng tuyệt đối. Nếu tôi hỏi bạn "ngọn núi kia cao bao nhiêu mét?", bạn sẽ lúng túng. Nhưng nếu tôi hỏi "ngọn núi A cao hơn hay thấp hơn ngọn núi B?", bạn trả lời ngay. Phần mềm cũng vậy: đoán chính xác số giờ rất khó, nhưng so sánh "task này khó hơn task kia" thì dễ và đáng tin hơn nhiều.
Thứ hai, giờ là của cá nhân, point là của team. Một task developer senior làm mất 2 giờ thì junior có thể mất 8 giờ. Nếu ước lượng bằng giờ, con số sẽ thay đổi tùy ai làm. Story Points biểu thị bản chất công việc — nó "to" như nhau bất kể ai cầm. Điều này giúp ước lượng ổn định ngay cả khi nhân sự thay đổi.
Thứ ba, point gói gọn ba yếu tố cùng lúc: độ phức tạp (complexity), công sức (effort), và độ bất định/rủi ro (uncertainty). Một task có thể ít việc nhưng rủi ro cao (ví dụ tích hợp với một hệ thống cổng thanh toán bạn chưa từng đụng đến) — nó vẫn xứng đáng nhiều point dù "code không bao nhiêu". Giờ làm việc không nắm bắt được chiều rủi ro này, còn point thì có.
Thang Fibonacci — vì sao lại là 1, 2, 3, 5, 8, 13?
Hầu hết team Agile dùng dãy số gần giống Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100. Vì sao không dùng 1, 2, 3, 4, 5, 6…?
Lý do là độ bất định tăng theo kích thước. Khi một việc càng lớn, khả năng bạn ước lượng sai càng cao, nên việc phân biệt "13 hay 14 point" là vô nghĩa — bạn không đủ thông tin để chính xác đến mức đó. Khoảng cách giãn dần của Fibonacci buộc team phải dứt khoát: một story hoặc là "5", hoặc là "8", không có vùng xám "6, 7". Sự thiếu lựa chọn này lại là điểm mạnh: nó phản ánh trung thực rằng ước lượng vốn là phỏng đoán, không phải đo đạc.
Khi một story chạm tới 20 hay lớn hơn, đó là tín hiệu nó quá lớn (gọi là epic) và cần được chẻ nhỏ (split) trước khi đưa vào Sprint. Nhiều team đặt quy ước: không story nào trên 8 hoặc 13 được phép vào Sprint.
Một "điểm tham chiếu" — viên gạch nền của cả hệ thống
Story Points chỉ có ý nghĩa khi so với một chuẩn. Vì thế, bước đầu tiên của mọi team là chọn một reference story (story tham chiếu): một việc cả team đều hiểu rõ, gán cho nó một con số (thường là 2 hoặc 3), rồi mọi ước lượng sau đều neo vào nó. "Story này so với story tham chiếu thì lớn gấp mấy?" — đó là câu hỏi gốc.
Planning Poker là gì?
Planning Poker (còn gọi là Scrum Poker) là kỹ thuật ước lượng đồng thuận (consensus-based) do Mike Cohn phổ biến. Mỗi thành viên có một bộ bài mang các số Fibonacci. Với mỗi story, mọi người chọn bài kín, lật cùng lúc, rồi thảo luận khi có khác biệt. Cái hay của nó nằm ở hai chữ "cùng lúc": nó chống lại anchoring (mỏ neo) — hiện tượng cả nhóm bị ảnh hưởng bởi con số người đầu tiên nói ra. Đồng thời nó kéo tri thức ẩn ra ánh sáng: khi người gán 2 và người gán 13 cùng giải thích, cả team đột nhiên hiểu story rõ hơn rất nhiều.
Tình huống thực tế
Ví dụ 1 — Tiki và bài học "story tham chiếu sai làm hỏng cả thang đo"
Một team thuộc mảng thương mại điện tử (bối cảnh giả định lấy cảm hứng từ các sàn như Tiki) bắt đầu áp dụng Story Points. Họ chọn reference story là "Thêm nút Yêu thích vào trang sản phẩm" và gán 3 point. Nghe hợp lý. Nhưng vấn đề: nút Yêu thích này thực ra đòi hỏi cả API mới, lưu trạng thái, đồng bộ giữa web và app — nó là một việc khá nặng nhưng team lúc đầu tưởng nhẹ.
Hệ quả: vì story tham chiếu "to thật mà bị gán nhỏ", nên mọi story sau đó đều bị ước lượng thấp hơn thực tế. Sau hai Sprint, team liên tục không hoàn thành cam kết, tinh thần đi xuống, stakeholder mất niềm tin. Khi Scrum Master ngồi lại phân tích, họ nhận ra gốc rễ nằm ở reference story bị chọn sai.
Bài học: reference story phải là việc đã làm xong, ai cũng hiểu cặn kẽ, lý tưởng là một việc cỡ trung bình. Đừng chọn việc còn mơ hồ làm chuẩn. Khi thang đo bị lệch ở gốc, mọi con số phía sau đều lệch theo.
Ví dụ 2 — Một fintech ở Singapore và "cuộc tranh luận 2 với 13"
Tại một công ty fintech ở Singapore, team đang ước lượng story "Tích hợp xác thực OTP qua SMS". Khi lật bài Planning Poker, kết quả gây sốc: ba người gán 2, một developer gán 13.
Theo đúng luật chơi, người cao nhất và thấp nhất giải thích trước. Ba người gán 2 nghĩ đơn giản: "Gọi API của nhà cung cấp SMS, xong." Developer gán 13 mới tiết lộ: nhà cung cấp SMS ở thị trường họ nhắm tới (Indonesia) có độ trễ cao, tỷ lệ rớt tin nhắn lớn, nên cần cơ chế retry, fallback sang nhà cung cấp thứ hai, và xử lý ca người dùng nhập sai OTP nhiều lần. Đây là kiến thức mà ba người kia hoàn toàn không biết.
Sau khi nghe xong, cả team vote lại: lần này kết quả hội tụ về 8. Quan trọng hơn con số: team vừa phát hiện ra hàng loạt edge case mà nếu không có buổi Planning Poker này, họ sẽ chỉ vỡ lẽ giữa Sprint — lúc đã quá muộn.
Bài học: giá trị lớn nhất của Planning Poker không phải là con số cuối, mà là cuộc hội thoại nó tạo ra. Sự bất đồng là vàng, không phải vấn đề. Một team luôn vote giống nhau ngay lần đầu thường là team chưa đào sâu đủ.
Ví dụ 3 — Startup VN remote và "Planning Poker async"
Một startup SaaS ở Việt Nam có team phân tán: 4 người ở TP.HCM, 2 người ở Đà Nẵng, 1 người ở Nhật. Họ không thể tụ họp lật bài vật lý. Ban đầu họ thử ước lượng qua chat, nhưng dính ngay anchoring: ai gõ con số đầu tiên là cả nhóm "gật theo".
Họ chuyển sang dùng công cụ Planning Poker online (như Planning Poker tích hợp trong Jira hoặc các tool miễn phí), nơi mọi người chọn bài kín và hệ thống chỉ lật khi tất cả đã chọn. Họ cũng đặt một quy tắc nhỏ nhưng hiệu quả: giới hạn mỗi vòng thảo luận tối đa 5 phút; nếu sau hai vòng vote vẫn lệch, họ chọn con số cao hơn (an toàn) và ghi chú lại điểm chưa rõ để refine sau.
Sau một tháng, độ ổn định ước lượng của họ cải thiện rõ, và buổi Sprint Planning rút từ 3 tiếng xuống còn 90 phút.
Bài học: Planning Poker hoàn toàn áp dụng được cho team remote, miễn là bạn giữ nguyên nguyên tắc "chọn kín, lật đồng thời" và đặt giới hạn thời gian để tránh sa lầy tranh luận.
Hướng dẫn từng bước
Đây là quy trình một buổi ước lượng bằng Planning Poker bạn có thể áp dụng ngay:
Bước 1 — Chuẩn bị backlog. Trước buổi họp, Product Owner đảm bảo các story đã được viết rõ, có acceptance criteria sơ bộ. Story mơ hồ thì không ước lượng được — hãy refine trước (xem bài 15).
Bước 2 — Chọn story tham chiếu. Lấy một story team đã hiểu rõ, gán cho nó một con số neo (ví dụ 2 hoặc 3). Dán nó ở nơi ai cũng thấy để so sánh suốt buổi.
Bước 3 — Đọc và làm rõ story. Product Owner trình bày story đang xét. Team đặt câu hỏi cho đến khi đủ hiểu. Đây là lúc đào edge case, ràng buộc, phụ thuộc.
Bước 4 — Chọn bài kín. Mỗi người chọn một con số Fibonacci phản ánh kích thước tương đối so với reference story. Không ai để lộ bài.
Bước 5 — Lật đồng thời. Tất cả lật cùng lúc. Điều này phá vỡ anchoring.
Bước 6 — Thảo luận khi có khác biệt. Nếu con số chênh nhau, mời người cao nhất và thấp nhất giải thích góc nhìn. Đây là phần quý giá nhất.
Bước 7 — Vote lại. Sau thảo luận, vote lại. Lặp tối đa 2–3 vòng. Thường con số sẽ hội tụ. Nếu vẫn lệch dai dẳng, chọn con số cao hơn để an toàn, hoặc tách story.
Bước 8 — Ghi lại và chuyển story tiếp theo. Ghi số point, lưu lại các giả định/rủi ro phát hiện được, rồi tiếp tục.
Một mẹo quan trọng: đừng ước lượng quá nhiều story trong một buổi. Sau 60–90 phút, năng lượng và độ chính xác đều giảm. Chia nhỏ thành nhiều phiên hoặc gắn vào buổi Backlog Refinement định kỳ.
Lỗi thường gặp & mẹo
Lỗi 1 — Quy đổi point ra giờ. "1 point = 4 giờ" là cái bẫy phổ biến nhất và nó giết chết toàn bộ giá trị của Story Points. Một khi bạn quy đổi cố định, point chỉ còn là giờ đội lốt, mất hết tính tương đối và linh hoạt. Hãy để point là point.
Lỗi 2 — So sánh velocity giữa các team. Point của team A và team B là hai thang đo khác nhau hoàn toàn vì reference story khác nhau. Dùng point để xếp hạng team là sai về bản chất và cực kỳ độc hại cho văn hóa. (Bài 23 và 52 sẽ nói sâu về cạm bẫy velocity.)
Lỗi 3 — Để sếp hoặc người to tiếng áp đặt con số. Nếu manager ngồi trong phòng và "gợi ý" con số, anchoring xảy ra ngay. Tốt nhất là người có quyền lực không vote, hoặc lật bài đồng thời nghiêm ngặt.
Lỗi 4 — Coi point là cam kết bất biến. Ước lượng là phỏng đoán tại một thời điểm với thông tin có hạn. Đừng dùng point như hợp đồng để "đòi nợ" developer khi thực tế khác đi.
Lỗi 5 — Ước lượng story còn mơ hồ. Nếu cả team không hiểu story, đừng vote. Điểm số khi đó là vô nghĩa. Hãy đẩy story về refine.
Mẹo hay:
- Dùng "T-shirt sizing" (S, M, L, XL) cho ước lượng thô ở mức cao (như release planning), rồi chuyển sang point khi vào chi tiết.
- Khi một story bị gán 13 trở lên, mặc định coi đó là tín hiệu phải chẻ nhỏ.
- Đừng ép đạt đồng thuận tuyệt đối — đồng thuận "đủ tốt" là được. Mục tiêu là hiểu chung, không phải con số hoàn hảo.
- Định kỳ rà lại reference story; nếu team đã trưởng thành, cách họ cảm nhận "3 point" có thể đã đổi.
Bài tập thực hành
Bài tập 1 — Tự xây thang tham chiếu. Lấy 5 task gần đây bạn đã làm xong (công việc hay dự án bất kỳ). Chọn một task cỡ trung bình làm chuẩn = 3 point. Gán Fibonacci cho 4 task còn lại bằng cách so sánh tương đối. Viết một câu lý giải vì sao mỗi task nhận con số đó — chú ý xem bạn có vô thức nghĩ theo "giờ" không.
Bài tập 2 — Mô phỏng Planning Poker. Rủ 3–4 đồng nghiệp. Lấy 5 user story (thật hoặc giả định). Mỗi người ước lượng kín, lật đồng thời. Với mỗi story chênh từ 2 bậc Fibonacci trở lên, cho người cao nhất và thấp nhất giải thích, rồi vote lại. Ghi lại: có bao nhiêu edge case mới được phát hiện nhờ thảo luận?
Bài tập 3 — Phân tích một thất bại. Nhớ lại một lần ước lượng của bạn sai nặng. Phân loại nguyên nhân: do thiếu hiểu công việc (complexity), do việc nhiều hơn tưởng (effort), hay do rủi ro bất ngờ (uncertainty)? Viết 3 câu rút ra. Bài tập này rèn cho bạn "đánh hơi" được loại rủi ro nào hay khiến mình ước lượng lệch.
Tóm tắt
Story Points là đơn vị tương đối, gói gọn độ phức tạp, công sức và độ bất định — chứ không phải giờ làm việc trá hình. Ta dùng thang Fibonacci (1, 2, 3, 5, 8, 13…) vì độ bất định tăng theo kích thước, và mọi ước lượng đều neo vào một reference story mà cả team hiểu rõ. Planning Poker là kỹ thuật ước lượng đồng thuận: chọn bài kín, lật đồng thời để chống anchoring, và biến sự bất đồng thành cuộc hội thoại làm sáng tỏ công việc. Hãy nhớ ba điều cốt lõi: (1) giá trị nằm ở cuộc thảo luận chứ không chỉ ở con số; (2) đừng bao giờ quy đổi point ra giờ hay so velocity giữa các team; (3) point là phỏng đoán, không phải lời thề. Làm chủ những điều này, bạn sẽ có một team ước lượng đáng tin — nền tảng cho mọi việc lập kế hoạch về sau.