Mở đầu — vì sao bài này quan trọng
Nếu bạn đã từng ngồi trong một cuộc họp lập kế hoạch dự án và nghe câu hỏi kinh điển: "Tính năng này mất bao lâu?", bạn sẽ hiểu vì sao ước lượng (estimation) là một trong những kỹ năng khiến Project Manager đau đầu nhất. Trong thế giới Waterfall truyền thống, chúng ta cố gắng trả lời bằng số giờ, số ngày — và gần như luôn sai. Lý do đơn giản: con người rất tệ trong việc ước lượng thời gian tuyệt đối, nhưng lại khá giỏi trong việc so sánh tương đối.
Đó chính là lý do Agile ra đời một cách tiếp cận hoàn toàn khác: Story Point và Velocity. Thay vì hỏi "việc này mất bao lâu?", chúng ta hỏi "việc này lớn cỡ nào so với việc kia?". Nghe có vẻ đơn giản, nhưng đây là một thay đổi tư duy sâu sắc, và nó giải quyết được rất nhiều vấn đề mà ước lượng theo giờ không bao giờ giải quyết được.
Bài học này tập trung riêng vào cách một PM/Scrum team ước lượng công việc trong môi trường Agile. Chúng ta sẽ không bàn sâu về Story Points ở góc độ chỉ đo kích thước đơn lẻ, mà đi vào cả hệ thống: cách tính Story Point, cách chạy Planning Poker, cách đo Velocity của team, và cách dùng Velocity để dự báo (forecast) khi nào dự án sẽ xong. Đây là những con số mà Product Owner, Scrum Master và cả sếp của bạn sẽ nhìn vào mỗi Sprint. Nắm vững nó, bạn sẽ giao tiếp về tiến độ một cách tự tin và có căn cứ, thay vì đoán mò.
Khái niệm cốt lõi
Story Point là gì — và không phải là gì
Story Point là một đơn vị đo lường kích thước tương đối (relative size) của một hạng mục công việc (user story). Điểm mấu chốt cần khắc cốt ghi tâm: Story Point không phải là thời gian. Nó không phải là "5 điểm = 5 giờ" hay "8 điểm = 8 ngày".
Một Story Point phản ánh sự tổng hợp của ba yếu tố:
- Effort (công sức): Cần bao nhiêu công việc để hoàn thành?
- Complexity (độ phức tạp): Công việc rối rắm, nhiều nhánh xử lý hay đơn giản?
- Uncertainty/Risk (độ bất định, rủi ro): Chúng ta đã hiểu rõ yêu cầu chưa, hay còn nhiều thứ chưa biết?
Thang Fibonacci — vì sao không dùng 1, 2, 3, 4, 5?
Agile team thường dùng thang Fibonacci đã điều chỉnh: 1, 2, 3, 5, 8, 13, 21. Lý do khoảng cách giữa các số ngày càng lớn là vì độ chính xác của ước lượng giảm khi công việc càng lớn. Bạn có thể tự tin phân biệt giữa việc 1 điểm và 2 điểm, nhưng bạn không thể phân biệt được việc 20 điểm và 21 điểm — sự khác biệt đó nằm trong sai số. Thang Fibonacci buộc team phải chọn dứt khoát: "việc này giống 8 hay giống 13 hơn?", tránh tranh cãi vô nghĩa kiểu "10 hay 11 điểm".
Một quy ước tham khảo phổ biến:
- 1 = việc cực nhỏ (trivial), gần như không cần suy nghĩ.
- 2–3 = story nhỏ, rõ ràng.
- 5 = story điển hình, kích thước "chuẩn" trong Sprint.
- 8 = story lớn, cần cân nhắc kỹ, bắt đầu thấy rủi ro.
- 13 trở lên = quá lớn, đây là dấu hiệu cần chẻ nhỏ (split) story ra trước khi đưa vào Sprint.
Baseline story — điểm neo để so sánh
Vì Story Point là tương đối, team cần một story mốc (baseline/reference story) để so chiếu. Cách làm phổ biến: chọn một story nhỏ, ai cũng hiểu, gán cho nó giá trị 2 hoặc 3 điểm, rồi mọi story khác được ước lượng bằng cách so sánh với story mốc này: "việc này lớn gấp đôi story mốc → 5 điểm". Việc có baseline giúp cả team có cùng "hệ quy chiếu", tránh tình trạng mỗi người hiểu "1 điểm" một kiểu.
Velocity — nhịp độ của team
Velocity là tổng số Story Point mà team hoàn thành thực sự (đạt Definition of Done) trong một Sprint. Nếu Sprint vừa rồi team làm xong 5 story với tổng 34 điểm, thì Velocity của Sprint đó là 34.
Velocity là chỉ số đo năng lực thực tế, không phải cam kết. Nó có hai công dụng lớn:
- Lập kế hoạch Sprint: Nếu Velocity trung bình 3 Sprint gần nhất là ~30 điểm, thì Sprint tới team chỉ nên kéo vào khoảng 30 điểm công việc — không nhồi 45 điểm rồi vỡ kế hoạch.
- Dự báo (forecasting): Nếu backlog còn 300 điểm và Velocity ~30 điểm/Sprint, ta ước tính cần khoảng 10 Sprint để hoàn thành. Với Sprint 2 tuần, đó là khoảng 20 tuần.
Planning Poker — cách team ước lượng cùng nhau
Planning Poker là kỹ thuật ước lượng đồng thuận. Mỗi thành viên có một bộ thẻ Fibonacci. Với mỗi story: Product Owner đọc yêu cầu → team hỏi đáp làm rõ → mỗi người đồng thời lật thẻ thể hiện ước lượng của mình. Việc lật đồng thời để tránh hiệu ứng "neo" (anchoring) — người nói trước ảnh hưởng người nói sau. Nếu con số chênh lệch lớn (ví dụ người ra 3, người ra 13), người thấp nhất và cao nhất giải thích lý do, rồi cả team ước lượng lại. Chính cuộc thảo luận này — chứ không phải con số — mới là giá trị lớn nhất: nó phơi bày những cách hiểu khác nhau về yêu cầu ngay từ đầu.
Tình huống thực tế
Ví dụ 1 — Team fintech ở TP.HCM chuyển từ ước lượng theo giờ sang Story Point
Một công ty fintech tại TP.HCM (gọi là MoMoPay giả định, khoảng 8 developer) trước đây ước lượng mọi thứ theo giờ. Kết quả: mỗi Sprint 2 tuần họ cam kết 320 giờ (8 người × 40 giờ), nhưng thực tế chỉ hoàn thành khoảng 60% khối lượng cam kết. Sếp liên tục thất vọng, team liên tục làm thêm giờ.
Khi chuyển sang Story Point, Scrum Master chọn story "Thêm màn hình lịch sử giao dịch" làm baseline = 3 điểm. Trong 3 Sprint đầu, Velocity của họ dao động mạnh: 22, 38, 29 điểm — vì team còn đang "hiệu chỉnh" cảm nhận về điểm. Đến Sprint 4–6, Velocity ổn định quanh 28–32 điểm. Từ đó, họ chỉ kéo vào Sprint tối đa 30 điểm.
Diễn giải: Ba Sprint đầu Velocity nhảy loạn là hoàn toàn bình thường — đừng hoảng. Team cần thời gian để "calibrate". Bài học rút ra: Đừng vội dùng Velocity để dự báo trong 2–3 Sprint đầu; hãy chờ nó ổn định. Và khi đã ổn định, việc lập kế hoạch trở nên đáng tin: tỷ lệ hoàn thành cam kết của họ tăng lên ~90%.
Ví dụ 2 — Story 21 điểm "chết kẹt" tại một công ty outsourcing ở Đà Nẵng
Một team làm dự án outsourcing cho khách Nhật tại Đà Nẵng (12 người) đưa vào Sprint một story "Xây dựng module báo cáo động" được ước lượng 21 điểm. Scrum Master lúc đó còn non kinh nghiệm, để nó lọt vào Sprint vì "khách hàng cần gấp". Kết quả: hết Sprint 2 tuần, story vẫn chưa xong. Sang Sprint sau, vẫn chưa xong. Velocity hai Sprint đó tụt thảm hại vì nguyên một khối 21 điểm không được tính (chưa đạt Definition of Done thì không được cộng điểm).
Sau khi nhìn lại, họ chẻ story 21 điểm thành 5 story nhỏ: 5 + 5 + 3 + 3 + 2 điểm. Ngay lập tức, mỗi Sprint team hoàn thành được vài story, tiến độ nhìn thấy được, và điều bất ngờ là tổng điểm sau khi chẻ chỉ còn 18 — vì khi chẻ nhỏ, phần bất định giảm, họ hiểu rõ hơn nên ước lượng chính xác hơn.
Bài học rút ra: Story càng lớn, rủi ro "kẹt cả Sprint" càng cao. Quy tắc "không đưa story lớn hơn 8 điểm vào Sprint" sinh ra chính vì lý do này. Chẻ nhỏ không chỉ giúp tracking mà còn giúp ước lượng chuẩn hơn.
Ví dụ 3 — Khi Velocity bị "thổi phồng" vì áp lực từ quản lý
Tại một ngân hàng số ở Hà Nội, ban lãnh đạo bắt đầu treo bảng xếp hạng Velocity giữa các Squad, kèm thưởng cho squad "năng suất cao nhất". Chỉ sau 2 tháng, Velocity trung bình toàn khối tăng gần gấp đôi — nghe có vẻ tuyệt vời. Nhưng chất lượng sản phẩm không đổi, thời gian ra mắt tính năng không nhanh hơn. Điều gì đã xảy ra? Các team đơn giản là thổi phồng điểm: story trước đây gán 3 điểm giờ gán 8 điểm. Con số đẹp lên, nhưng vô nghĩa.
Diễn giải: Đây là ví dụ kinh điển của định luật Goodhart — "khi một chỉ số trở thành mục tiêu, nó không còn là chỉ số tốt". Bài học rút ra: Velocity là công cụ để team tự lập kế hoạch, tuyệt đối không phải KPI để quản lý ép năng suất hay so sánh giữa các team. Một PM giỏi phải biết bảo vệ ý nghĩa của Velocity trước áp lực từ trên xuống.
Hướng dẫn từng bước
Đây là quy trình ước lượng Agile bạn có thể áp dụng ngay:
- Chuẩn bị backlog: Product Owner đảm bảo các user story đã đủ rõ ràng (có mô tả, có acceptance criteria) trước buổi ước lượng. Story mù mờ không thể ước lượng chính xác.
- Chọn story mốc (baseline): Cả team thống nhất một story nhỏ, quen thuộc, gán 2 hoặc 3 điểm làm điểm neo tham chiếu cho mọi so sánh sau này.
- Chạy Planning Poker cho từng story: Đọc story → hỏi đáp làm rõ → mọi người lật thẻ đồng thời → thảo luận nếu chênh lệch → ước lượng lại đến khi đồng thuận (không nhất thiết tuyệt đối, chỉ cần đủ gần).
- Chẻ nhỏ story quá lớn: Bất kỳ story nào ra 13 hoặc 21 điểm → dừng lại, tách thành nhiều story nhỏ hơn 8 điểm trước khi cho vào Sprint.
- Đo Velocity sau mỗi Sprint: Cộng tổng điểm của các story đã đạt Definition of Done. Story làm dở dang không được tính điểm (không có điểm "một nửa").
- Tính Velocity trung bình: Lấy trung bình 3 Sprint gần nhất để có con số ổn định cho việc lập kế hoạch. Có thể dùng khoảng (ví dụ 28–34) thay vì một số cứng.
- Lập kế hoạch Sprint tiếp theo: Kéo vào Sprint lượng công việc xấp xỉ Velocity trung bình, có tính đến số ngày nghỉ lễ, thành viên vắng mặt (capacity).
- Dự báo cho dự án: Tổng điểm backlog còn lại ÷ Velocity trung bình = số Sprint ước tính còn lại. Trình bày dưới dạng khoảng thời gian, kèm giả định.
Lỗi thường gặp & mẹo
Lỗi 1 — Quy đổi Story Point thành giờ. Ngay khi ai đó nói "1 điểm = 4 giờ", toàn bộ lợi ích của ước lượng tương đối biến mất, và bạn quay về đúng cái bẫy cũ. Hãy kiên quyết tách rời điểm khỏi thời gian.
Lỗi 2 — Dùng Velocity để so sánh team hoặc ép năng suất. Như ví dụ 3, điều này chắc chắn dẫn đến thổi phồng điểm (point inflation) và làm hỏng dữ liệu. Velocity chỉ để team tự dự báo.
Lỗi 3 — Tính điểm cho story làm dở. Definition of Done là ranh giới trắng đen: xong thì tính đủ điểm, chưa xong thì 0 điểm. "Nửa điểm" làm sai lệch Velocity.
Lỗi 4 — Kỳ vọng Velocity ổn định ngay lập tức. Team mới cần 3–5 Sprint để calibrate. Thay đổi thành viên, công nghệ mới, nghỉ lễ cũng làm Velocity dao động — đó là chuyện bình thường.
Lỗi 5 — Đưa story 13/21 điểm vào Sprint. Gần như luôn dẫn đến kẹt. Chẻ nhỏ trước.
Mẹo hữu ích:
- Dùng T-shirt sizing (S, M, L, XL) cho backlog thô khi cần ước lượng nhanh nhiều hạng mục lớn ở giai đoạn đầu, sau đó mới chuyển sang Story Point khi story vào gần Sprint.
- Ước lượng lại nếu hiểu biết thay đổi, nhưng đừng đi ước lượng lại toàn bộ backlog cũ chỉ để "làm đẹp" Velocity.
- Chú ý Velocity giảm dần nhiều Sprint liên tiếp — đó là tín hiệu cảnh báo về nợ kỹ thuật, kiệt sức, hoặc yêu cầu ngày càng mù mờ. Hãy điều tra nguyên nhân gốc.
- Đừng để một hai người "áp điểm" cho cả team. Sức mạnh của Planning Poker nằm ở việc mọi tiếng nói được lắng nghe.
Bài tập thực hành
- Ước lượng tương đối: Lấy 5 công việc bất kỳ trong đời sống (ví dụ: nấu một bữa cơm, giặt đồ, dọn nhà, sơn một căn phòng, chuyển nhà). Chọn "giặt đồ" làm baseline = 2 điểm. Gán Story Point Fibonacci cho 4 việc còn lại bằng cách so sánh với baseline. Ghi lại lý do effort/complexity/uncertainty cho mỗi việc.
- Tính Velocity: Một team hoàn thành các Sprint như sau — Sprint 1: 26 điểm; Sprint 2: 31; Sprint 3: 24; Sprint 4: 29. Tính Velocity trung bình 3 Sprint gần nhất. Nếu backlog còn 210 điểm, ước tính team cần bao nhiêu Sprint để hoàn thành?
- Nhận diện lỗi: Một Scrum Master nói: "Sprint này team làm được 40 điểm, còn team bên kia chỉ 25 điểm, nên team mình năng suất hơn 60%." Hãy chỉ ra ít nhất hai điểm sai trong lập luận này.
- Chẻ story: Story "Xây dựng chức năng đăng nhập" được ước lượng 13 điểm. Hãy đề xuất cách chẻ nó thành 3–4 story nhỏ hơn (ví dụ: đăng nhập bằng email/mật khẩu, quên mật khẩu, đăng nhập bằng Google, xác thực 2 lớp) và ước lượng lại từng phần.
Tóm tắt
Ước lượng Agile xoay quanh một ý tưởng đơn giản nhưng mạnh mẽ: con người ước lượng kích thước tương đối tốt hơn nhiều so với thời gian tuyệt đối. Story Point đóng gói effort, complexity và uncertainty vào một con số theo thang Fibonacci (1, 2, 3, 5, 8, 13, 21) — trong đó 1 là việc cực nhỏ, 3–5 là story điển hình, còn 8 trở lên là dấu hiệu cần cân nhắc chẻ nhỏ. Planning Poker giúp team đạt đồng thuận và, quan trọng hơn, phơi bày những cách hiểu khác nhau về yêu cầu.
Velocity — tổng điểm hoàn thành đạt Definition of Done mỗi Sprint — là nhịp độ thực tế của team, dùng để lập kế hoạch Sprint và dự báo tiến độ dự án. Hãy nhớ ba nguyên tắc vàng: Story Point không phải giờ; Velocity không dùng để so sánh giữa các team; và story quá lớn phải được chẻ nhỏ trước khi vào Sprint. Nắm vững những công cụ này, bạn sẽ chuyển từ việc "đoán mò khi nào xong" sang "dự báo có căn cứ" — một bước tiến lớn trong sự chuyên nghiệp của một Project Manager thời Agile.