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 ứng dụng, và sếp hỏi bạn một câu rất đơn giản: "Khi nào tính năng thanh toán QR sẽ xong?". Nếu bạn trả lời "Em không chắc, chắc vài tuần ạ", bạn vừa đánh mất một cơ hội vàng để xây dựng niềm tin. Nhưng nếu bạn nói: "Dựa trên tốc độ hiện tại của đội, em dự kiến tính năng này hoàn thành trong khoảng 3 đến 4 Sprint, tức là cuối tháng 8, với độ tin cậy khoảng 80%" — thì bạn đã chuyển từ một người "cảm tính" sang một người làm việc bằng dữ liệu.
Công cụ giúp bạn làm được điều đó chính là Velocity (tốc độ hoàn thành) và kỹ thuật forecasting (dự báo). Đây là một trong những kỹ năng định lượng quan trọng nhất của một Product Owner. Velocity không phải để đánh giá đội nhanh hay chậm, mà là để bạn lập kế hoạch release thực tế, đặt kỳ vọng hợp lý với stakeholder, và trả lời câu hỏi "khi nào xong" một cách có cơ sở thay vì đoán mò.
Trong bài này, chúng ta sẽ đi sâu vào bản chất của Velocity: nó là gì, đo như thế nào, và quan trọng nhất là dùng nó để forecast tương lai ra sao một cách trung thực và có tính khoa học.
Khái niệm cốt lõi
Velocity là gì?
Velocity là tổng số Story Points mà đội hoàn thành (đạt Definition of Done) trong một Sprint. Lưu ý ba từ khóa quan trọng:
- Hoàn thành: chỉ tính những hạng mục đã thực sự "Done" theo Definition of Done. Một story làm dở dang 90% vẫn được tính là 0 điểm. Không có khái niệm "điểm thành phần".
- Story Points: Velocity đo bằng đơn vị ước lượng tương đối của đội (thường là Story Points), không phải bằng giờ hay số task.
- Một Sprint: Velocity luôn gắn với một khoảng thời gian cố định (Sprint length). Velocity của Sprint 2 tuần và Sprint 3 tuần không thể so sánh trực tiếp.
Velocity là chỉ số nội bộ, không phải thước đo hiệu suất
Đây là điều cực kỳ quan trọng mà nhiều người hiểu sai. Velocity không dùng để so sánh giữa các đội, và không dùng để đánh giá năng suất nhân viên. Vì sao? Vì Story Points là đơn vị tương đối, mang tính chủ quan riêng của từng đội. Đội A ước lượng một tính năng đăng nhập là 5 điểm, đội B có thể ước lượng cùng tính năng đó là 13 điểm — không phải vì đội B yếu hơn, mà vì thang đo của họ khác. So sánh Velocity giữa hai đội cũng vô nghĩa như so sánh nhiệt độ đo bằng độ C với độ F mà không quy đổi.
Velocity chỉ có giá trị khi dùng chính nó so với chính nó qua thời gian trong cùng một đội ổn định.
Average Velocity và độ ổn định
Một Sprint đơn lẻ không nói lên nhiều điều, vì luôn có biến động (người nghỉ ốm, sự cố production, độ phức tạp bất ngờ). Cái chúng ta quan tâm là xu hướng. Thông thường người ta lấy:
- Average Velocity: trung bình Velocity của 3 đến 6 Sprint gần nhất.
- Velocity Range: khoảng dao động (thấp nhất đến cao nhất) để biết mức độ bất định.
Forecasting là gì?
Forecasting là dùng Velocity trong quá khứ để dự đoán tương lai: bao nhiêu Sprint nữa thì xong một tập backlog, hoặc trong N Sprint tới đội làm được bao nhiêu việc. Công thức cơ bản nhất:
> Số Sprint cần thiết = Tổng Story Points còn lại ÷ Average Velocity
Nhưng forecast giỏi không bao giờ đưa ra một con số duy nhất. Nó luôn đi kèm một khoảng tin cậy (confidence range), vì tương lai vốn bất định.
Tình huống thực tế
Ví dụ 1: Tiki và bài toán release tính năng "Đặt trước sản phẩm"
Giả sử đội phát triển một module tại một sàn thương mại điện tử lớn ở Việt Nam (lấy bối cảnh kiểu Tiki) cần xây dựng tính năng "Pre-order" (đặt trước) cho các sản phẩm sách phát hành mới. Backlog đã được refine và ước lượng tổng cộng 160 Story Points.
Product Owner nhìn lại 5 Sprint gần nhất, Velocity lần lượt là: 32, 28, 35, 30, 30. Average Velocity = 31.
Cách forecast ngây thơ: 160 ÷ 31 ≈ 5,2 Sprint, làm tròn lên 6 Sprint. Nhưng PO giỏi sẽ làm theo cách an toàn hơn, dùng cả khoảng:
- Kịch bản lạc quan (Velocity cao = 35): 160 ÷ 35 ≈ 4,6 → ~5 Sprint.
- Kịch bản bi quan (Velocity thấp = 28): 160 ÷ 28 ≈ 5,7 → ~6 Sprint.
Bài học: Đừng bao giờ báo cáo bằng một con số tuyệt đối. Một khoảng dự báo trung thực giúp bạn vừa giữ uy tín vừa có không gian xoay xở khi có biến động.
Ví dụ 2: Startup fintech ở TP.HCM và cái bẫy "Velocity tăng vọt"
Một startup fintech tại TP.HCM có đội 5 lập trình viên. Trong 4 Sprint đầu, Velocity là 22, 25, 24, 23 — khá ổn định quanh 23. Sang Sprint 5, áp lực gọi vốn khiến CEO yêu cầu "chạy nhanh hơn". Đột nhiên Velocity nhảy lên 38, rồi Sprint 6 là 41.
Nghe có vẻ tuyệt vời? Không hẳn. Khi PO điều tra, hóa ra đội đã làm hai việc nguy hiểm: (1) bắt đầu lạm phát điểm — ước lượng một story trước đây 3 điểm thì giờ gán 5 điểm; và (2) bỏ qua một phần Definition of Done, đẩy việc viết test và refactor sang "làm sau". Velocity tăng trên giấy tờ, nhưng chất lượng giảm, và đến Sprint 8 thì nợ kỹ thuật (technical debt) bùng nổ, Velocity sụp xuống còn 15 vì đội phải đi sửa bug.
Bài học: Velocity tăng đột biến không tự nhiên là tin tốt. Nếu nó đi kèm với việc nới lỏng Definition of Done hoặc thay đổi thang đo, thì đó là Velocity "ảo". Một đội khỏe mạnh có Velocity ổn định và bền vững, không phải tăng vọt rồi sụp đổ.
Ví dụ 3: Đội outsourcing và bài toán nhân sự thay đổi
Một công ty gia công phần mềm ở Đà Nẵng có một đội ổn định với Velocity trung bình 50. Khách hàng Nhật yêu cầu thêm việc, công ty bổ sung 2 lập trình viên mới vào đội (từ 6 lên 8 người). Manager kỳ vọng Velocity sẽ tăng tương ứng lên ~67.
Thực tế Sprint kế tiếp Velocity lại giảm xuống 42. Vì sao? Vì người mới cần thời gian onboard, và các thành viên cũ phải dành thời gian hướng dẫn, review code cho người mới. Phải mất 3 đến 4 Sprint, Velocity mới dần ổn định ở mức ~62 — cao hơn trước nhưng không phải tăng tuyến tính như kỳ vọng.
Bài học: Mỗi khi cấu trúc đội thay đổi (thêm/bớt người), Velocity lịch sử trở nên kém tin cậy. Bạn cần "reset" kỳ vọng và thu thập lại dữ liệu vài Sprint trước khi forecast đáng tin. Velocity là thuộc tính của một đội cụ thể và ổn định, không phải của từng cá nhân cộng lại.
Hướng dẫn từng bước
Đây là quy trình thực tế để bạn xây dựng và dùng Velocity cho forecasting.
Bước 1 — Đảm bảo nền tảng ước lượng nhất quán. Velocity chỉ đáng tin khi đội ước lượng Story Points theo một thang đo ổn định (xem lại Bài 24 về Planning Poker). Nếu thang đo của đội cứ "trôi" theo từng Sprint, mọi forecast đều vô nghĩa.
Bước 2 — Định nghĩa "Done" rõ ràng và giữ nguyên. Velocity chỉ tính các hạng mục đạt Definition of Done. Nếu DoD thay đổi giữa chừng, Velocity các Sprint không còn so sánh được với nhau.
Bước 3 — Ghi lại Velocity từng Sprint. Sau mỗi Sprint Review, ghi tổng điểm các story đã Done. Lưu vào một bảng đơn giản, hoặc dùng tính năng Velocity Chart có sẵn trong Jira, Linear.
Bước 4 — Tính Average Velocity sau ít nhất 3 Sprint. Lấy trung bình 3 đến 6 Sprint gần nhất. Càng nhiều dữ liệu, forecast càng đáng tin. Đồng thời ghi nhận khoảng dao động (min – max).
Bước 5 — Forecast bằng khoảng, không bằng điểm. Tính cả ba kịch bản:
- Số Sprint = Tổng điểm còn lại ÷ Velocity thấp nhất (bi quan).
- Số Sprint = Tổng điểm còn lại ÷ Average Velocity (kỳ vọng).
- Số Sprint = Tổng điểm còn lại ÷ Velocity cao nhất (lạc quan).
Bước 7 — Cập nhật lại sau mỗi Sprint. Forecasting không phải làm một lần. Mỗi Sprint kết thúc, bạn có thêm một điểm dữ liệu mới — hãy cập nhật Average Velocity và điều chỉnh dự báo. Đây gọi là "rolling forecast".
Bước 8 — Truyền đạt forecast kèm độ tin cậy. Khi báo cáo, luôn nói rõ "khoảng" và "giả định". Ví dụ: "Với Velocity hiện tại và giả định không có việc lớn phát sinh, chúng ta hoàn thành trong 5 đến 7 Sprint."
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng Velocity để ép tiến độ hoặc đánh giá đội. Khi quản lý biến Velocity thành KPI để khen thưởng hay khiển trách, đội sẽ lập tức "chơi" con số bằng cách thổi phồng điểm. Velocity ngay lập tức mất giá trị làm công cụ dự báo. Hãy giữ Velocity là công cụ lập kế hoạch nội bộ, không phải thước đo hiệu suất.
Lỗi 2 — So sánh Velocity giữa các đội. Như đã nói, Story Points là tương đối. Câu "Đội Hà Nội Velocity 60 còn đội Sài Gòn chỉ 40, đội Sài Gòn yếu hơn" là một kết luận sai về bản chất.
Lỗi 3 — Forecast bằng một con số duy nhất. Đưa ra "đúng 6 Sprint" tạo cảm giác chắc chắn giả tạo. Khi trễ dù chỉ một Sprint, uy tín của bạn sụp đổ. Luôn dùng khoảng.
Lỗi 4 — Tính điểm cho story làm dở. "Story này làm gần xong rồi, cho 80% điểm nhé" — tuyệt đối không. Done là Done, chưa Done là 0. Việc cho điểm dở dang làm Velocity bị thổi phồng và sai lệch.
Lỗi 5 — Quên rằng backlog co giãn. Bạn forecast 100 điểm còn lại, nhưng trong quá trình làm phát sinh thêm 40 điểm. Nếu không trừ hao, dự báo luôn lạc quan quá mức. Hãy theo dõi cả tỷ lệ "scope creep" (phình phạm vi).
Mẹo 1 — Dùng Velocity Chart trực quan. Một biểu đồ cột Velocity qua các Sprint giúp bạn và stakeholder nhìn ngay ra xu hướng ổn định hay biến động.
Mẹo 2 — Loại bỏ Sprint bất thường. Nếu một Sprint có sự kiện đặc biệt (cả đội đi training 3 ngày, Tết, sự cố lớn), hãy ghi chú và cân nhắc loại nó khỏi phép tính trung bình để tránh làm méo dữ liệu.
Mẹo 3 — Khi mới bắt đầu, đừng forecast vội. Đội mới hoặc dự án mới chưa có lịch sử Velocity. Hãy thu thập ít nhất 3 Sprint trước khi đưa ra bất kỳ dự báo nào, và nói thẳng với stakeholder rằng giai đoạn đầu chỉ là ước tính sơ bộ.
Bài tập thực hành
Bài tập 1 — Tính Average Velocity và forecast. Đội của bạn có Velocity 6 Sprint gần nhất: 28, 32, 30, 26, 34, 30. Backlog cho release tiếp theo còn 150 Story Points. a) Tính Average Velocity. b) Forecast số Sprint cần thiết theo ba kịch bản (bi quan / kỳ vọng / lạc quan). c) Nếu mỗi Sprint là 2 tuần, bạn sẽ báo cáo mốc thời gian nào cho stakeholder và vì sao?
Bài tập 2 — Phát hiện Velocity ảo. Một đội có Velocity 5 Sprint: 20, 22, 21, 35, 40. PO thấy hai Sprint cuối tăng mạnh và rất vui. Hãy liệt kê ít nhất 3 câu hỏi bạn sẽ đặt ra để kiểm chứng xem đây là cải thiện thật hay Velocity ảo.
Bài tập 3 — Trừ hao phát sinh. Backlog còn 200 điểm, Average Velocity là 40. Nhưng lịch sử cho thấy mỗi Sprint thường phát sinh thêm khoảng 25% công việc ngoài kế hoạch (bug, yêu cầu mới). Hãy ước lượng số Sprint thực tế cần thiết khi tính đến yếu tố phát sinh này.
Bài tập 4 — Tình huống nhân sự. Đội bạn Velocity ổn định 45. Tháng sau, 1 thành viên chủ chốt nghỉ thai sản 6 tháng. Hãy viết một đoạn ngắn (3 đến 4 câu) giải thích cho stakeholder vì sao forecast hiện tại cần điều chỉnh và bạn sẽ làm gì với dữ liệu Velocity.
Tóm tắt
- Velocity là tổng Story Points mà đội hoàn thành (đạt Definition of Done) trong một Sprint. Chỉ tính việc đã Done, không tính việc dở dang.
- Velocity là chỉ số nội bộ để lập kế hoạch, không phải thước đo hiệu suất và không dùng để so sánh giữa các đội.
- Average Velocity (trung bình 3 đến 6 Sprint) cùng khoảng dao động là nền tảng cho forecasting.
- Forecasting dùng Velocity quá khứ để dự báo tương lai: Số Sprint = Tổng điểm còn lại ÷ Velocity. Luôn forecast bằng khoảng kèm độ tin cậy, không bằng một con số tuyệt đối.
- Hãy trừ hao cho công việc phát sinh và cập nhật rolling forecast sau mỗi Sprint.
- Cảnh giác với Velocity ảo (tăng vọt do lạm phát điểm hoặc nới lỏng DoD) và với những thay đổi cấu trúc đội làm dữ liệu lịch sử mất giá trị.