Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Product Manager của một startup fintech ở TP.HCM. Sáng thứ Hai, sếp hỏi: "Tính năng thanh toán QR bao giờ xong?" Bạn quay sang hỏi team dev, và ba người đưa ra ba câu trả lời khác nhau: một bạn nói "khoảng 2 ngày", một bạn nói "1 tuần nếu tính cả test", bạn còn lại thì im lặng vì… chưa biết bắt đầu từ đâu. Nếu bạn từng rơi vào tình huống này, bạn sẽ hiểu tại sao ước lượng theo giờ (hour) hay ngày (day) lại dễ gây tranh cãi và sai lệch đến vậy.
Story Points và Velocity chính là hai công cụ mà Agile sinh ra để giải quyết chính xác vấn đề này. Story Points giúp team ước lượng công việc theo một thước đo tương đối, ổn định hơn nhiều so với đơn vị thời gian. Velocity thì cho bạn — với vai trò PM — một con số đáng tin để dự báo: "Với tốc độ hiện tại, team sẽ hoàn thành backlog này trong khoảng bao nhiêu sprint?"
Đây là bài học nền tảng cho mọi hoạt động lập kế hoạch của bạn sau này: từ Sprint Planning, dự báo roadmap, cho tới việc trả lời câu hỏi "bao giờ xong" một cách có cơ sở thay vì đoán mò. Nắm chắc bài này, bạn sẽ nói chuyện với engineer và với stakeholder bằng cùng một ngôn ngữ dữ liệu.
Khái niệm cốt lõi
Story Point là gì
Story Point là một thước đo tương đối (relative measure) phản ánh tổng hợp ba yếu tố của một công việc:
- Effort (công sức): khối lượng việc cần làm nhiều hay ít.
- Complexity (độ phức tạp): việc này rối rắm, nhiều thành phần phụ thuộc, hay đơn giản, rõ ràng.
- Uncertainty (độ bất định): mức độ chúng ta chưa biết. Có công nghệ mới chưa từng dùng? Yêu cầu còn mơ hồ? Phụ thuộc vào bên thứ ba?
Tại sao lại tách rời khỏi thời gian? Vì con người rất giỏi so sánh nhưng lại rất tệ khi ước lượng tuyệt đối. Nếu tôi hỏi bạn "đi bộ từ nhà ra chợ mất mấy phút?", bạn sẽ ngập ngừng. Nhưng nếu tôi hỏi "quãng đường ra chợ xa gấp mấy lần ra đầu ngõ?", bạn trả lời ngay được. Story Point tận dụng đúng thế mạnh so sánh này.
Vì sao dùng thước đo tương đối thay vì giờ
Ước lượng theo giờ có ba vấn đề chí mạng:
- Kỹ năng khác nhau, giờ khác nhau. Một task, senior làm 2 giờ, junior làm 8 giờ. Vậy ghi bao nhiêu giờ vào backlog? Story Point thì bằng nhau vì độ khó của task không đổi, chỉ có người thực hiện đổi.
- Ước lượng giờ tạo áp lực cam kết sai. Khi bạn nói "8 giờ", stakeholder nghe thành một lời hứa chính xác. Đến khi trễ, niềm tin sụp đổ. Story Point cố tình mờ đi để tránh cái bẫy "cam kết giả" này.
- Giờ không cộng dồn để dự báo được. Còn Story Point, khi kết hợp với Velocity, cho phép dự báo trung hạn rất tốt.
Thang điểm Fibonacci
Hầu hết các team Agile dùng thang Fibonacci đã điều chỉnh: 1, 2, 3, 5, 8, 13, 20, 40, 100. (Đôi khi thêm 0 cho việc gần như không tốn công, và ký hiệu "?" cho việc quá mơ hồ chưa ước lượng được.)
Vì sao lại là Fibonacci mà không phải 1, 2, 3, 4, 5, 6? Vì khoảng cách giữa các số càng lớn thì độ chính xác của ước lượng càng giảm — điều này phản ánh đúng thực tế. Bạn có thể tự tin phân biệt một task 1 điểm với task 2 điểm. Nhưng bạn KHÔNG thể phân biệt được task 21 điểm với task 22 điểm — sự chính xác đó là ảo tưởng. Fibonacci ép team phải chọn giữa 13 và 20 thay vì cãi nhau xem là 14 hay 15.
Một quy tắc thực tế: nếu một item được ước lượng từ 13 điểm trở lên, đó là dấu hiệu nó quá lớn, cần được chẻ nhỏ (split) thành các story con trước khi đưa vào sprint. Story quá lớn = rủi ro cao, khó hoàn thành trong một sprint.
Baseline — điểm neo tham chiếu
Vì Story Point là tương đối, team cần một baseline — một story mẫu mà mọi người đồng thuận. Ví dụ: "Thêm một trường bắt buộc vào form đăng ký, có validate cơ bản = 2 điểm." Từ đó mọi story khác được so sánh: "Cái này khó gấp đôi baseline → 5 điểm." Không có baseline chung, mỗi người sẽ chấm theo một hệ quy chiếu riêng và con số trở nên vô nghĩa.
Velocity là gì
Velocity là tổng số Story Point mà team hoàn thành (Done — đạt Definition of Done) trong một sprint. Lưu ý chữ "hoàn thành": một story làm dở 80% vẫn tính là 0 điểm velocity, không có điểm nửa vời.
Velocity không phải mục tiêu để tối đa hóa, mà là công cụ dự báo. Sau 3–4 sprint, bạn lấy trung bình velocity để trả lời câu hỏi vàng: "Backlog còn 120 điểm, velocity trung bình 20 điểm/sprint → cần khoảng 6 sprint nữa để hoàn thành."
Velocity là chỉ số nội bộ của riêng một team, không dùng để so sánh giữa các team. Team A đạt 40 điểm/sprint không có nghĩa là giỏi gấp đôi team B đạt 20 điểm — vì baseline của hai team khác nhau hoàn toàn.
Tình huống thực tế
Ví dụ 1 — Planning Poker tại một team ở Tiki
Một team engineering thuộc mảng logistics của Tiki (giả định minh họa) gồm 6 người ngồi vào buổi Sprint Planning. Story cần ước lượng: "Tích hợp API tra cứu tồn kho từ kho Bình Dương vào trang chi tiết sản phẩm."
Họ chơi Planning Poker: mỗi người có bộ bài Fibonacci, cùng lật đồng thời. Kết quả: 4 người chọn 5, một senior backend chọn 3, một bạn frontend chọn 13.
Thay vì lấy trung bình, Scrum Master mời hai người ở hai cực giải thích. Bạn senior nói: "API này tôi từng làm với kho Hà Nội, tái sử dụng được 70% code, nên 3." Bạn frontend nói: "Ơ, tôi tưởng phải build cả màn hình hiển thị realtime, nên 13." → Hóa ra hai người hiểu khác nhau về phạm vi (scope). Sau khi làm rõ story chỉ gồm phần API, không có UI realtime, cả team lật lại và đồng thuận ở 5 điểm.
Bài học rút ra: Giá trị lớn nhất của Story Point không nằm ở con số cuối cùng, mà ở cuộc thảo luận để đi đến con số đó. Sự chênh lệch điểm số là "đèn báo" phát hiện các cách hiểu khác nhau về yêu cầu — thứ mà nếu bỏ qua sẽ nổ tung giữa sprint.
Ví dụ 2 — Dự báo roadmap cho CEO tại startup edtech
Bạn là PM một startup edtech ở Hà Nội, 15 nhân sự. CEO cần biết tính năng "lớp học live có chatbox" ra mắt kịp mùa tựu trường tháng 9 không. Hôm nay là đầu tháng 6.
Bạn nhìn lại dữ liệu 4 sprint gần nhất (mỗi sprint 2 tuần):
| Sprint | Điểm hoàn thành |
|---|---|
| 21 | 23 |
| 22 | 18 |
| 23 | 21 |
| 24 | 22 |
Bạn tính: 95 ÷ 21 ≈ 4,5 sprint → làm tròn lên 5 sprint = 10 tuần. Từ đầu tháng 6 cộng 10 tuần rơi vào giữa tháng 8. Bạn trình bày với CEO: "Nếu team không bị rút người và scope giữ nguyên, khả năng cao kịp trước tựu trường, nhưng buffer chỉ khoảng 2 tuần — em đề xuất khóa scope ngay."
Bài học rút ra: Velocity biến câu hỏi cảm tính "chắc kịp thôi" thành một dự báo có khoảng tin cậy và có điều kiện kèm theo. PM giỏi luôn kèm giả định (scope giữ nguyên, không rút người) khi đưa dự báo, vì velocity chỉ đúng khi bối cảnh ổn định.
Ví dụ 3 — Khi velocity bị hiểu sai thành KPI
Một công ty gia công phần mềm (outsourcing) ở Đà Nẵng áp velocity thành KPI: "Sprint sau phải cao hơn sprint trước." Kết quả sau 2 tháng: velocity tăng vọt từ 20 lên 45 điểm/sprint. Nghe có vẻ tuyệt vời?
Thực tế, team đã thổi phồng điểm (point inflation): cùng một loại task trước chấm 3 giờ giờ chấm 8. Chất lượng thì đi xuống vì ai cũng vội "đóng" story để lấy điểm. Velocity trở thành con số vô nghĩa, dự báo sai bét, và stakeholder mất niềm tin.
Bài học rút ra: Khoảnh khắc velocity biến thành KPI đánh giá con người là khoảnh khắc nó chết. Đây là ví dụ kinh điển 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." Velocity phải là công cụ của team, không phải cây gậy của quản lý.
Hướng dẫn từng bước
Đây là quy trình áp dụng Story Point và Velocity từ con số không:
- Chọn thang điểm và thống nhất với team. Dùng Fibonacci (1, 2, 3, 5, 8, 13). Trong Jira, bật trường "Story Points" (Estimation field) cho project của bạn ở phần Board settings → Estimation.
- Thiết lập baseline. Cùng team chọn một story cỡ nhỏ, ai cũng hiểu rõ, gán nó là 2 hoặc 3 điểm. Đây là mốc so sánh cho mọi story sau này.
- Ước lượng bằng Planning Poker. Trong buổi refinement hoặc planning, cả team cùng chấm điểm đồng thời (dùng app như Planning Poker Online, hoặc plugin trong Jira). Lật bài đồng loạt để tránh hiệu ứng "neo" theo người nói đầu tiên.
- Thảo luận các điểm chênh lệch. Nếu điểm cách nhau xa (ví dụ 3 và 13), mời hai cực giải thích. Chấm lại cho đến khi hội tụ. Đừng lấy trung bình — hãy để thảo luận dẫn đến đồng thuận.
- Gán điểm vào từng story trong Jira. Điền số vào trường Story Points của mỗi issue.
- Chạy sprint và chỉ tính điểm cho story Done. Cuối sprint, cộng tổng điểm các story đã đạt Definition of Done → đó là velocity của sprint này.
- Tích lũy 3–4 sprint rồi tính velocity trung bình. Đừng dùng velocity của một sprint đơn lẻ để dự báo — quá nhiều nhiễu. Dùng trung bình, hoặc dùng khoảng (min–max) để có dự báo lạc quan/bi quan.
- Dự báo và cập nhật liên tục. Lấy tổng điểm backlog chia cho velocity trung bình để ước tính số sprint còn lại. Cập nhật sau mỗi sprint vì velocity sẽ ổn định dần theo thời gian.
Lỗi thường gặp & mẹo
Lỗi 1 — Quy đổi ngầm Story Point ra giờ. Câu nói kinh điển "1 điểm = 4 giờ" phá hỏng toàn bộ triết lý tương đối. Ngay khi bạn quy đổi cố định, bạn quay về mọi vấn đề của ước lượng theo giờ. Mẹo: Nếu ai đó hỏi "1 điểm bao nhiêu giờ", hãy trả lời "tùy người, tùy hôm — nhưng chắc chắn 5 điểm khó gấp hơn 2 điểm."
Lỗi 2 — So sánh velocity giữa các team. "Team A 40 điểm, team B 20 điểm, team B kém hơn." Sai hoàn toàn — hai team dùng hai baseline khác nhau. Mẹo: Chỉ so velocity của một team với chính nó qua thời gian.
Lỗi 3 — Dùng velocity làm KPI đánh giá. Như ví dụ Đà Nẵng, việc này gây thổi phồng điểm. Mẹo: Velocity chỉ để dự báo và tự cải thiện, tuyệt đối không đưa vào bảng đánh giá cá nhân.
Lỗi 4 — Tính điểm cho story làm dở. "Story này xong 90% rồi, cho nửa điểm nhé." Không. Velocity chỉ tính binary: Done hoặc không. Mẹo: Giữ nguyên tắc này để velocity phản ánh đúng năng lực giao hàng thực tế.
Lỗi 5 — Ước lượng thời điểm chưa hiểu yêu cầu. Chấm điểm khi story còn mơ hồ sẽ cho số vô nghĩa. Mẹo: Dùng ký hiệu "?" cho story chưa đủ rõ, đưa về refinement làm rõ trước.
Lỗi 6 — Re-estimate liên tục. Đừng chấm lại điểm story chỉ vì làm mất nhiều thời gian hơn dự kiến. Điểm phản ánh độ khó ước lượng ban đầu, không phải thời gian thực tế đã bỏ ra. Mẹo: Chỉ re-estimate khi scope thực sự thay đổi.
Mẹo bổ sung cho PM: Với vai trò PM, bạn không nên là người chấm điểm — chấm điểm là việc của team dev vì họ là người thực thi. Vai trò của bạn là làm rõ yêu cầu, ưu tiên backlog, và dùng velocity để giao tiếp với stakeholder. Đừng ép điểm số theo ý mình.
Bài tập thực hành
Bài 1 — Xây baseline và ước lượng tương đối. Lấy 5 công việc bất kỳ trong dự án hiện tại của bạn (hoặc giả định). Chọn một việc nhỏ nhất làm baseline = 2 điểm. Gán điểm Fibonacci cho 4 việc còn lại bằng cách so sánh với baseline. Viết ra lý do cho từng điểm số theo ba yếu tố: effort, complexity, uncertainty.
Bài 2 — Tính velocity và dự báo. Cho dữ liệu 4 sprint sau (điểm hoàn thành): 15, 19, 17, 21. Backlog còn lại 110 điểm.
- Tính velocity trung bình.
- Ước tính cần bao nhiêu sprint để hoàn thành backlog.
- Nếu mỗi sprint 2 tuần và hôm nay là 27/06/2026, dự báo ngày hoàn thành gần đúng.
(Gợi ý đáp án Bài 2: velocity trung bình = 18; 110 ÷ 18 ≈ 6,1 → 7 sprint = 14 tuần; hoàn thành khoảng đầu tháng 10/2026.)
Tóm tắt
- Story Point là thước đo tương đối phản ánh effort + complexity + uncertainty, KHÔNG phải giờ hay ngày. Sức mạnh của nó nằm ở việc con người so sánh tốt hơn ước lượng tuyệt đối.
- Dùng thang Fibonacci (1, 2, 3, 5, 8, 13…) vì độ chính xác giảm dần khi việc lớn hơn; item ≥ 13 điểm nên được chẻ nhỏ.
- Baseline là điểm neo giúp cả team chấm điểm trên cùng một hệ quy chiếu.
- Velocity = tổng điểm các story Done trong một sprint; là công cụ dự báo nội bộ, không phải KPI, không dùng để so sánh giữa các team.
- Lấy trung bình 3–4 sprint để dự báo: tổng điểm backlog ÷ velocity ≈ số sprint còn lại — luôn kèm giả định về scope và nhân sự.
- Giá trị lớn nhất của việc ước lượng nằm ở cuộc thảo luận làm lộ ra những cách hiểu khác nhau về yêu cầu, chứ không phải ở con số cuối cùng.