Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Product Owner của một đội phát triển app gọi xe ở TP.HCM. Sếp hỏi: "Tính năng đặt xe theo nhóm bao giờ xong?" Nếu bạn trả lời "Em không chắc, có thể vài tuần", bạn vừa đánh mất sự tin tưởng. Nhưng nếu bạn nói "Dựa trên tốc độ hiện tại của đội, tính năng này khoảng 3 sprint, tức cuối tháng 8 sẽ ra mắt được", bạn vừa thể hiện mình là một PO chuyên nghiệp, có dữ liệu trong tay.
Khoảng cách giữa hai câu trả lời đó chính là nội dung của bài học hôm nay: Estimation (ước lượng) và Velocity (tốc độ đội).
Đây là hai khái niệm bị hiểu lầm nhiều nhất trong Scrum. Rất nhiều đội biến Story Points thành một thứ "giờ công trá hình", rồi dùng Velocity để ép tiến độ hay so sánh giữa các đội — và kết quả là cả hệ thống ước lượng sụp đổ. Là một PO, bạn không cần phải là người ước lượng (việc đó thuộc về Developers), nhưng bạn bắt buộc phải hiểu cơ chế đằng sau để: dự báo ngày ra mắt, thương lượng phạm vi với stakeholder, và bảo vệ đội khỏi áp lực vô lý. Bài này sẽ trang bị cho bạn tư duy đó.
Khái niệm cốt lõi
Story Points là gì — và không phải là gì
Story Points (điểm câu chuyện) là đơn vị tương đối đo độ lớn của một hạng mục công việc. Lưu ý chữ "tương đối": Story Points không đo bằng giờ hay ngày. Nó trả lời câu hỏi "việc này lớn cỡ nào so với việc kia?" chứ không phải "việc này mất mấy tiếng?".
Một Story Point gói gọn ba yếu tố trong một con số duy nhất:
- Complexity (độ phức tạp): Logic nghiệp vụ rối hay đơn giản? Có nhiều trường hợp ngoại lệ không?
- Effort (khối lượng công việc): Cần viết bao nhiêu code, test bao nhiêu màn hình?
- Uncertainty / Risk (độ bất định): Đội đã làm việc tương tự bao giờ chưa? Có phụ thuộc bên thứ ba không?
Vì sao lại là dãy Fibonacci?
Dãy số quen thuộc nhất để gán điểm là Fibonacci: 1, 2, 3, 5, 8, 13, 21 (và đôi khi thêm 40, 100 cho những thứ "khổng lồ chưa rõ").
Khoảng cách giữa các số ngày càng giãn ra không phải ngẫu nhiên. Nó phản ánh một sự thật: việc càng lớn thì độ bất định càng cao, nên không có ý nghĩa khi cố phân biệt chi li. Bạn có thể tự tin nói một việc là "5" hay "8", nhưng bạn không thể nói nó là "6" hay "7" — sự chính xác giả tạo đó vô nghĩa. Fibonacci ép đội phải chọn dứt khoát, tránh tranh cãi vô bổ về những chênh lệch nhỏ.
Một thang tham chiếu thực dụng để bạn và đội cùng hiểu:
- 1 = thay đổi cực nhỏ (trivial): sửa một dòng chữ, đổi màu nút bấm. Ai cũng làm được trong nháy mắt.
- 2 = nhỏ, rõ ràng, gần như không có rủi ro.
- 3 = vừa phải, requirement rõ ràng, đội đã từng làm việc tương tự.
- 5 = độ phức tạp trung bình, cần suy nghĩ về thiết kế, có vài đầu việc con.
- 8 = lớn, nhiều phần ghép lại, bắt đầu có rủi ro hoặc phụ thuộc.
- 13 = rất lớn, nên cảnh giác — thường là tín hiệu cần chẻ nhỏ (split) story ra.
- 21+ = quá lớn để đưa vào một sprint. Đây thực chất là một Epic, chưa sẵn sàng.
Velocity — nhịp đập của đội
Velocity là tổng số Story Points mà đội hoàn thành (đạt Definition of Done) trong một sprint. Nếu sprint vừa rồi đội "Done" 5 story trị giá lần lượt 3, 5, 8, 2, 5 điểm, thì Velocity của sprint đó là 23.
Hai điều then chốt về Velocity:
- Chỉ tính việc đã Done. Story làm dở 90% mà chưa đạt DoD thì tính 0 điểm. Không có "điểm an ủi".
- Velocity là chỉ số đo lường (measure), không phải mục tiêu (target). Đây là ranh giới sống còn. Khoảnh khắc bạn biến Velocity thành KPI để ép đội "phải đạt 30 điểm/sprint", đội sẽ lập tức "thổi điểm" (point inflation) — gán điểm cao hơn cho cùng một khối lượng việc. Con số đẹp lên nhưng giá trị thật không đổi. Bạn tự bắn vào chân mình.
Tình huống thực tế
Tình huống 1: Tiki và bài học về "thổi điểm"
Một đội tại một sàn thương mại điện tử lớn của Việt Nam (gọi là đội Checkout) từng có Velocity ổn định 28 điểm/sprint. Một Engineering Manager mới về, nhìn vào con số và yêu cầu: "Quý này phải nâng Velocity lên 40, tăng 40% năng suất."
Đội không thể đột nhiên code nhanh hơn 40%. Nhưng họ cần con số đẹp để báo cáo. Thế là trong buổi Planning Poker tiếp theo, một story trước đây gán 5 điểm bỗng được gán 8; story 3 điểm thành 5. Sau hai sprint, Velocity "đạt" 40. Manager hài lòng.
Vấn đề: lượng tính năng thực sự ra mắt cho khách hàng không hề tăng. Tệ hơn, vì điểm đã bị bóp méo, mọi dự báo release sau đó đều sai bét. PO không còn dùng Velocity để forecast được nữa vì con số đã mất ý nghĩa.
Bài học: Velocity thuộc về đội, dùng để đội tự dự báo, không phải công cụ để cấp trên ép năng suất. Là PO, bạn phải đứng ra giải thích điều này với stakeholder và bảo vệ tính toàn vẹn của hệ thống ước lượng.
Tình huống 2: Startup fintech và sự nguy hiểm của story 13 điểm
Một startup fintech ở Singapore (đội 5 developers) nhận story: "Tích hợp cổng thanh toán mới cho thị trường Indonesia." Trong Planning Poker, ý kiến rất phân tán — người gán 8, người gán 21. Sự phân tán lớn này là tín hiệu vàng: đội chưa hiểu rõ phạm vi.
Thay vì ép lấy trung bình thành 13 rồi nhét vào sprint, Scrum Master đề nghị thảo luận. Hóa ra người gán 21 lo về việc xử lý tiền tệ Rupiah (làm tròn, số lẻ), còn người gán 8 chỉ nghĩ đến phần gọi API cơ bản. Họ quyết định chẻ story thành ba phần: "Gọi API thanh toán cơ bản" (5), "Xử lý định dạng tiền tệ và làm tròn" (3), "Đối soát và xử lý lỗi giao dịch" (5).
Kết quả: hai story đầu vào được sprint hiện tại, story đối soát phức tạp đẩy sang sprint sau khi đã research kỹ. Việc ra mắt diễn ra suôn sẻ.
Bài học: Khi điểm số phân tán mạnh hoặc một story chạm 13+, đừng vội nhét vào sprint. Đó là lúc cần làm rõ và chẻ nhỏ. Một story lớn mơ hồ là rủi ro lớn nhất với cam kết sprint.
Tình huống 3: Đội outsource ở Đà Nẵng và sự ổn định của Velocity
Một công ty phần mềm ở Đà Nẵng nhận dự án cho khách hàng Nhật. Khách hàng liên tục hỏi "khi nào xong toàn bộ 200 điểm backlog?". PO theo dõi Velocity qua 6 sprint: 22, 26, 19, 24, 25, 23.
Thay vì hứa một ngày cụ thể, PO dùng cả khoảng. Lấy Velocity thấp nhất (19) và cao nhất (26): 200 ÷ 26 ≈ 8 sprint (kịch bản lạc quan), 200 ÷ 19 ≈ 11 sprint (kịch bản thận trọng). PO báo cáo: "Với tốc độ hiện tại, dự án hoàn thành trong khoảng 8 đến 11 sprint, nhiều khả năng quanh sprint thứ 9–10." Khách hàng Nhật rất hài lòng vì cách trả lời trung thực, có dữ liệu và có biên độ rủi ro rõ ràng.
Bài học: Đừng forecast bằng một con số cứng. Dùng khoảng (range) dựa trên dao động Velocity thực tế. Điều này vừa trung thực vừa giúp bạn không bị "việt vị" khi có biến động.
Hướng dẫn từng bước
Dưới đây là quy trình thực hành để đội bạn ước lượng và dùng Velocity hiệu quả:
Bước 1 — Chọn một story tham chiếu (baseline). Trước khi gán điểm cho cả backlog, hãy chọn một story nhỏ, ai cũng hiểu rõ, và đồng thuận gán nó là "2" hoặc "3". Mọi story sau đó được ước lượng bằng cách so sánh với nó: "Việc này lớn gấp đôi baseline, vậy là khoảng 5".
Bước 2 — Tổ chức Planning Poker. Mỗi developer cầm bộ thẻ Fibonacci (hoặc dùng app như Planning Poker online). Sau khi PO trình bày story và đội hỏi đáp làm rõ, tất cả đồng loạt lật thẻ. Việc lật cùng lúc tránh hiệu ứng "neo" — người sau bị ảnh hưởng bởi con số người trước nói.
Bước 3 — Thảo luận khi có chênh lệch lớn. Nếu người gán 3 và người gán 13, đừng vội lấy trung bình. Hãy để hai người đó giải thích góc nhìn. Thường người gán cao đã nhìn ra một rủi ro mà người khác bỏ sót. Đây mới là giá trị thật của Planning Poker: làm lộ ra hiểu biết ngầm.
Bước 4 — Gán điểm và lưu lại. Sau thảo luận, lật thẻ lại lần hai cho đến khi đồng thuận. Lưu điểm vào backlog (Jira, Linear...).
Bước 5 — Đo Velocity sau mỗi sprint. Cuối sprint, cộng điểm của các story đã Done (không tính dở dang). Ghi lại con số này.
Bước 6 — Tính Velocity trung bình để dự báo. Sau 3–6 sprint, lấy trung bình (và biết khoảng dao động). Dùng nó để trả lời câu hỏi "bao giờ xong" bằng một khoảng sprint, như Tình huống 3.
Bước 7 — Hiệu chỉnh liên tục. Velocity sẽ thay đổi khi đội thay người, học công nghệ mới, hay quen tay hơn. Đừng kỳ vọng nó cố định. Đội mới thành lập thường có Velocity nhiễu loạn trong 3–4 sprint đầu — đó là bình thường.
Lỗi thường gặp & mẹo
Lỗi 1: Quy đổi Story Points ra giờ. "1 điểm = 4 giờ" là cái bẫy phổ biến nhất. Khi làm vậy, bạn vứt bỏ toàn bộ lợi ích của ước lượng tương đối và biến Story Points thành lịch công cứng nhắc. Mỗi developer có tốc độ khác nhau; cùng một story, người giỏi làm 2 giờ, người mới làm 6 giờ — nhưng độ lớn của story thì không đổi. Mẹo: Nếu sếp đòi quy đổi ra giờ, hãy giải thích rằng Velocity đã làm việc đó ở cấp độ đội rồi, chính xác hơn nhiều.
Lỗi 2: So sánh Velocity giữa các đội. "Đội A đạt 40, đội B chỉ 25, vậy đội B kém hơn." Hoàn toàn sai. Story Points là thang điểm nội bộ của mỗi đội — "5 điểm" của đội A có thể là "8 điểm" của đội B. So sánh Velocity giữa các đội cũng vô nghĩa như so sánh nhiệt độ đo bằng độ C với độ F mà không quy đổi. Mẹo: Chỉ so sánh Velocity của một đội với chính nó qua thời gian.
Lỗi 3: PO ước lượng thay đội. Đôi khi PO sốt ruột tự gán điểm. Đừng. Người làm việc mới là người ước lượng. PO chỉ làm rõ "cái gì" và "tại sao", còn "lớn cỡ nào" là việc của Developers. Mẹo: Vai trò của bạn trong Planning Poker là trả lời câu hỏi và làm rõ phạm vi, không phải lật thẻ.
Lỗi 4: Cam kết 100% Velocity vào mỗi sprint. Nếu Velocity trung bình là 25, đừng nhồi đúng 25 điểm vào mỗi sprint. Luôn chừa biên cho việc phát sinh, hỗ trợ kỹ thuật, lỗi khẩn cấp. Mẹo: Nhiều đội lành mạnh chỉ lên kế hoạch 80–85% Velocity trung bình.
Lỗi 5: Phạt đội khi Velocity tụt. Velocity tụt có thể do nghỉ lễ, có người ốm, hay gặp việc khó. Phạt đội sẽ khiến họ thổi điểm để "đẹp con số". Mẹo: Coi Velocity tụt là tín hiệu để hỏi "có trở ngại gì?", không phải cái cớ để trách móc.
Bài tập thực hành
Bài 1 — Thiết lập baseline. Lấy backlog hiện tại (hoặc giả định) của sản phẩm bạn. Chọn một story nhỏ, rõ ràng, gán nó là 3 điểm. Viết một câu mô tả vì sao nó là 3 để cả đội cùng tham chiếu sau này.
Bài 2 — Tự chơi Planning Poker. Lấy 5 story bất kỳ. Trước tiên tự ước lượng (giấu kết quả). Nếu có đồng đội, mỗi người ước lượng độc lập rồi so sánh. Tìm story nào có chênh lệch lớn nhất và viết ra lý do đằng sau sự khác biệt — đó chính là rủi ro ẩn cần làm rõ.
Bài 3 — Phát hiện story cần chẻ nhỏ. Trong 5 story trên, có story nào bị gán 13 trở lên không? Hãy thử chẻ nó thành 2–3 story con sao cho mỗi story con đều dưới 8 điểm và vẫn mang lại giá trị độc lập.
Bài 4 — Dự báo bằng khoảng. Giả sử Velocity 5 sprint gần nhất của đội bạn là: 20, 24, 18, 22, 26. Backlog còn lại 150 điểm. Hãy tính khoảng số sprint cần thiết (dùng Velocity thấp nhất và cao nhất) và viết một câu trả lời stakeholder theo phong cách "khoảng X đến Y sprint".
Tóm tắt
- Story Points là đơn vị tương đối đo độ lớn công việc, gói gọn complexity + effort + uncertainty. Tuyệt đối không quy đổi ra giờ.
- Dãy Fibonacci (1, 2, 3, 5, 8, 13, 21) phản ánh việc càng lớn càng bất định, ép đội chọn dứt khoát. Story chạm 13+ là tín hiệu cần chẻ nhỏ.
- Velocity là tổng điểm các story đã Done trong một sprint. Đây là chỉ số đo lường, không phải mục tiêu để ép.
- Planning Poker có giá trị không phải ở con số cuối cùng, mà ở cuộc thảo luận làm lộ ra hiểu biết và rủi ro ngầm.
- Để dự báo, dùng Velocity trung bình 3–6 sprint và trả lời bằng một khoảng, không phải con số cứng.
- Là PO: bạn không ước lượng thay đội, không so sánh Velocity giữa các đội, và bạn là người bảo vệ tính toàn vẹn của hệ thống ước lượng trước áp lực từ stakeholder.