Mở đầu — vì sao bài này quan trọng
Nếu bạn từng ngồi trong một buổi họp với sếp và bị hỏi: "Đội của em làm được bao nhiêu trong Sprint tới? Cam kết đi!", thì bạn đã chạm đúng vào tâm điểm của bài học này. Velocity (tốc độ), Throughput (thông lượng) và Forecasting (dự báo) là ba khái niệm mà rất nhiều người làm Scrum dùng hàng ngày nhưng hiểu sai bản chất — và đó cũng chính là lý do PSM I thích "gài" thí sinh ở khu vực này.
Điểm mấu chốt bạn cần khắc cốt ghi tâm ngay từ đầu: Velocity và Throughput KHÔNG nằm trong Scrum Guide. Chúng là những công cụ bổ trợ (complementary practices), không phải artifact, không phải commitment, không phải metric bắt buộc. Scrum Guide 2020 thậm chí còn chủ động bỏ mọi đề cập đến velocity để nhấn mạnh rằng Scrum không quy định cách đo lường tiến độ. Nhưng — và đây là chỗ tinh tế — chúng lại là cách rất phổ biến để Developers tự forecast lượng công việc họ có thể đưa vào một Sprint trong Sprint Planning.
Trong bài này, chúng ta sẽ phân biệt rạch ròi ba khái niệm, hiểu vì sao Scrum dùng từ "forecast" (dự báo) chứ tuyệt đối không dùng "commit" (cam kết cứng) cho phạm vi công việc, và cách dùng những con số này một cách lành mạnh thay vì biến chúng thành cây gậy quản lý. Đây là kiến thức vừa thi cử vừa thực chiến.
Khái niệm cốt lõi
Velocity là gì
Velocity là tổng kích thước ước lượng (thường là story points) của các Product Backlog Item đã đạt "Done" trong một Sprint. Lưu ý ba chữ quan trọng: "đã Done". Một item làm xong 90% nhưng chưa đạt Definition of Done thì đóng góp 0 điểm vào velocity — không có khái niệm "điểm một nửa". Đây là điểm thi rất hay xuất hiện.
Ví dụ, đội của bạn kéo vào Sprint các item có tổng 40 điểm. Cuối Sprint, các item đạt Done cộng lại được 32 điểm. Velocity của Sprint đó là 32, không phải 40.
Có bốn đặc tính của velocity mà bạn phải nắm:
- Velocity mang tính xu hướng (trend), không phải con số tuyệt đối từng Sprint. Một Sprint velocity 32 rồi Sprint sau 28 không có nghĩa đội "tệ đi". Bạn nhìn trung bình của 3–5 Sprint gần nhất để có cảm giác đáng tin.
- Velocity đặc thù theo từng đội (team-specific). 30 điểm của đội A ở Hà Nội hoàn toàn khác 30 điểm của đội B ở TP.HCM, vì thang điểm do mỗi đội tự định nghĩa. Vì vậy tuyệt đối không so sánh velocity giữa các đội — đây là một anti-pattern kinh điển và cũng là bẫy trong đề thi.
- Velocity không phải mục tiêu (target). Khi quản lý ép "tăng velocity 20%", đội sẽ phản ứng bằng cách... thổi phồng điểm ước lượng (point inflation). Con số đẹp lên nhưng giá trị thực không đổi. Đây là biểu hiệ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 là công cụ nội bộ của Developers, dùng để hỗ trợ chính họ forecast trong Sprint Planning — không phải báo cáo cho cấp trên hay đo lường hiệu suất cá nhân.
Throughput là gì
Throughput là số lượng item (work item) hoàn thành trong một khoảng thời gian — ví dụ "8 item mỗi Sprint" hoặc "12 item mỗi tuần". Khác với velocity ở chỗ throughput đếm số lượng, không quan tâm kích thước ước lượng của từng item.
Throughput thường gắn với tư duy flow (luồng) và Kanban hơn, và nó có một ưu điểm lớn: bạn không cần estimate (ước lượng) gì cả. Chỉ cần các item được chia nhỏ tương đối đồng đều, bạn chỉ việc đếm. Đây là nền tảng của trào lưu #NoEstimates (sẽ bàn kỹ ở Bài 32) — thay vì tốn công cãi nhau "cái này 5 hay 8 điểm", cứ chẻ nhỏ item cho đều rồi đếm throughput.
So sánh nhanh để bạn không nhầm:
- Velocity = tổng điểm của item Done / Sprint (gắn với estimation).
- Throughput = số lượng item Done / đơn vị thời gian (không cần estimation).
Forecasting và vì sao Scrum không "commit"
Đây là phần "linh hồn" của bài. Trong Scrum, Developers forecast (dự báo) lượng công việc đưa vào Sprint, chứ không commit (cam kết) phạm vi đó.
Sự phân biệt này không phải chơi chữ. Nó là một thay đổi triết lý có chủ đích:
- Trước phiên bản 2011, Scrum Guide dùng từ "commit" cho Sprint Backlog. Đội cam kết hoàn thành đúng một danh sách item. Hệ quả: khi gặp bất ngờ (việc khó hơn dự kiến, có rủi ro kỹ thuật mới phát hiện), đội buộc phải cắt chất lượng để "giữ lời hứa", hoặc rơi vào tâm lý thất bại.
- Từ 2011, từ "commit" được đổi thành "forecast" cho phạm vi Sprint. Cái duy nhất đội thực sự cam kết là Sprint Goal (mục tiêu Sprint — một commitment, xem Bài 22), chứ không phải cam kết hoàn thành 100% các item đã chọn.
Nói cách khác: Velocity và Throughput cho ta cơ sở để forecast tốt hơn, nhưng bản thân việc đưa item vào Sprint mãi mãi là một forecast, không bao giờ là một commitment về phạm vi. Nếu một câu hỏi PSM I gợi ý rằng đội "phải hoàn thành mọi item đã cam kết" thì gần như chắc chắn đó là đáp án sai.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "tăng velocity"
Giả định một đội phát triển tính năng thanh toán tại một sàn TMĐT lớn ở Việt Nam (gọi là đội Payments của Tiki). Trong 4 Sprint gần nhất, velocity lần lượt là 34, 31, 36, 33 — trung bình khoảng 33–34 điểm. Đội forecast khá ổn định.
Một quản lý cấp trung mới về, nhìn dashboard và tuyên bố: "Quý này tôi muốn velocity lên 45. Tăng 30% năng suất." Đội im lặng làm theo. Ba Sprint sau, dashboard hiện 44, 46, 45 — đẹp như tranh. Nhưng số tính năng thực sự giao cho khách hàng lại giảm, và số bug rò rỉ ra production tăng.
Chuyện gì đã xảy ra? Đội đơn giản là thổi điểm: việc trước đây cho 3 điểm giờ cho 5, việc 5 điểm giờ cho 8. Velocity là một con số tương đối do chính đội định nghĩa, nên ép nó tăng chẳng khác gì ép cái thước co giãn ra dài hơn — số đo đổi, vật thật không đổi. Tệ hơn, áp lực chạy theo số khiến đội bỏ bớt bước review và test, làm chất lượng tụt.
Bài học: Velocity là thước đo để đội tự dùng, không phải KPI để áp từ trên xuống. Vai trò của Scrum Master ở đây (xem Bài 39) là giúp tổ chức hiểu rằng "tăng velocity" là một mục tiêu vô nghĩa; thứ đáng theo đuổi là giá trị giao cho khách hàng và chất lượng (DoD), không phải con số điểm.
Tình huống 2 — Startup Singapore chuyển từ Velocity sang Throughput
Một startup fintech ở Singapore có đội 6 developer. Họ mất quá nhiều thời gian trong mỗi buổi refinement để cãi nhau "task này 3 hay 5 điểm". Có buổi tranh luận về point ăn mất 40 phút. Scrum Master nhận ra estimation đang tạo ra waste (lãng phí) nhiều hơn giá trị nó mang lại.
Đội thử một thí nghiệm: thay vì cố estimate chính xác, họ tập trung chẻ nhỏ mọi item về kích thước gần tương đương (mỗi item làm xong trong khoảng 0,5–2 ngày), rồi bỏ luôn story point, chuyển sang đếm throughput. Sau 5 Sprint, dữ liệu cho thấy throughput dao động 9–11 item/Sprint, trung bình 10. Để forecast Sprint tới, họ chỉ cần chọn khoảng 10 item đã được refine đủ nhỏ ở đầu bảng Product Backlog.
Kết quả: thời gian refinement giảm một nửa, độ chính xác của dự báo không hề tệ đi (thậm chí ổn định hơn, vì kích thước item đồng đều), và đội bớt căng thẳng vì không còn những cuộc cãi vã về điểm.
Bài học: Velocity không phải con đường duy nhất để forecast. Throughput là một lựa chọn hợp lệ và đôi khi tốt hơn, đặc biệt khi đội chịu khó chia item nhỏ và đều. Quan trọng là forecast dựa trên dữ liệu lịch sử thực tế (empirical), bằng đơn vị nào không quan trọng bằng việc nó giúp đội phán đoán tốt hơn.
Tình huống 3 — Đội mới thành lập và cái bẫy "Sprint đầu tiên"
Một công ty gia công phần mềm ở Đà Nẵng vừa lập một đội Scrum hoàn toàn mới cho một dự án khách hàng Nhật. Trong Sprint Planning đầu tiên, Product Owner hỏi: "Velocity của đội mình là bao nhiêu để em biết kéo bao nhiêu việc?" Câu trả lời thành thật: chưa có. Đội chưa chạy Sprint nào thì lấy đâu ra dữ liệu lịch sử.
Đội xử lý đúng cách: ở Sprint đầu, họ không dựa vào velocity (vì không tồn tại) mà dựa vào thảo luận về năng lực (capacity) và độ tự tin của Developers — bao nhiêu người, bao nhiêu ngày làm việc thực, có ai nghỉ phép không, có rủi ro kỹ thuật nào chưa rõ. Họ forecast một lượng nhỏ vừa phải, cố tình thận trọng. Sau 3 Sprint, velocity bắt đầu hình thành một range (vùng) đáng tin: 18–24 điểm. Lúc này họ mới dùng nó như một dữ liệu tham khảo cho forecast.
Bài học: Velocity/Throughput là thước đo hồi cứu — cần thời gian tích lũy mới có ý nghĩa. Đội mới, đội vừa thay đổi thành viên, hay đội đổi loại công việc đều phải coi velocity cũ là không đáng tin. Đừng bao giờ "mượn" velocity của đội khác để gán cho đội mình. Và lưu ý: dù có hay không có velocity, việc đưa item vào Sprint vẫn luôn là forecast, do Developers quyết định (không phải PO hay Scrum Master áp).
Hướng dẫn từng bước
Dưới đây là cách dùng velocity/throughput để hỗ trợ forecast trong Sprint Planning một cách lành mạnh:
- Thu thập dữ liệu lịch sử. Ghi lại velocity (hoặc throughput) của 3–5 Sprint gần nhất. Đừng dùng dữ liệu quá cũ hoặc từ giai đoạn đội còn khác về cấu trúc.
- Tính một vùng (range), không phải một con số. Thay vì nói "velocity của đội là 33", hãy nói "đội thường hoàn thành 30–36 điểm". Range phản ánh đúng bản chất bất định và giúp tránh ảo giác chính xác.
- Bắt đầu Sprint Planning từ Sprint Goal, không từ velocity. Trật tự đúng là: PO trình bày mục tiêu kinh doanh → đội cùng định hình Sprint Goal → rồi mới chọn item phục vụ mục tiêu đó. Velocity chỉ là một "thanh chắn" tham khảo để đội không kéo quá tay.
- Để Developers — và chỉ Developers — quyết lượng việc. Họ là người làm nên họ là người duy nhất có quyền forecast bao nhiêu là khả thi. PO không được ép thêm item; Scrum Master không quyết thay.
- Điều chỉnh theo bối cảnh Sprint cụ thể. Sprint này có người nghỉ lễ Tết? Có một việc rủi ro kỹ thuật cao? Hãy forecast thấp hơn velocity trung bình. Velocity là điểm khởi đầu, không phải mệnh lệnh.
- Coi forecast là sống, không phải khắc đá. Trong Daily Scrum, nếu thực tế cho thấy forecast quá lạc quan hoặc quá thận trọng, đội điều chỉnh phạm vi (thương lượng với PO) miễn là không phá Sprint Goal.
- Sau Sprint, cập nhật dữ liệu và lặp lại. Mỗi Sprint xong, velocity mới được ghi nhận, range được tinh chỉnh. Đây chính là vòng inspect–adapt áp dụng cho chính việc dự báo của đội.
Lỗi thường gặp & mẹo
Lỗi 1 — Tưởng velocity nằm trong Scrum Guide. Không. Velocity, throughput, story point, burndown đều là practice bổ trợ. Trong đề thi, nếu một câu khẳng định "Scrum yêu cầu đo velocity" thì đó là sai.
Lỗi 2 — So sánh velocity giữa các đội. Velocity là tương đối và đặc thù từng đội. So sánh đội A 40 điểm "giỏi hơn" đội B 25 điểm là vô nghĩa và độc hại. Tránh tuyệt đối.
Lỗi 3 — Dùng velocity làm KPI/đánh giá cá nhân. Biến thước đo thành mục tiêu sẽ phá hỏng nó (point inflation, cắt chất lượng). Velocity là công cụ tự định hướng của Developers.
Lỗi 4 — Lẫn lộn "forecast" với "commit". Đội forecast phạm vi, chỉ commit Sprint Goal. Nếu cuối Sprint chưa xong hết item nhưng đạt Sprint Goal, đó vẫn là Sprint thành công.
Lỗi 5 — Cho điểm bộ phận (partial credit). Item chưa Done = 0 điểm velocity. Không có "làm được 80% thì tính 80% điểm".
Lỗi 6 — Tin vào velocity của đội mới sau 1 Sprint. Cần 3–5 Sprint mới có range đáng tin.
Mẹo thi cử: Khi gặp câu về dự báo/đo lường, hãy chọn đáp án nào (a) gọi nó là forecast của Developers, (b) thừa nhận velocity là optional/complementary, (c) nhấn mạnh xu hướng thay vì con số tuyệt đối, và (d) bảo vệ chất lượng (DoD). Đáp án nào nói về "cam kết phạm vi cứng", "tăng velocity là mục tiêu", hay "so sánh giữa các đội" thường là bẫy.
Mẹo thực chiến: Khi sếp đòi "cam kết", hãy dịch sang ngôn ngữ xác suất: "Dựa trên dữ liệu, đội tự tin khoảng 80% sẽ giao được nhóm tính năng A trong 2 Sprint tới, và chúng tôi cập nhật con số này mỗi Sprint." Đó là forecast có trách nhiệm, vừa minh bạch (transparency) vừa không hứa điều bất định.
Bài tập thực hành
- Phân biệt khái niệm: Tự viết một câu định nghĩa cho mỗi từ — velocity, throughput, forecast — bằng ngôn ngữ của bạn, mỗi câu nêu rõ "đo cái gì" và "có nằm trong Scrum Guide không".
- Tính velocity: Một Sprint, đội kéo vào 6 item: 8, 5, 5, 3, 3, 2 điểm. Cuối Sprint, item 8 điểm và một item 3 điểm chưa đạt Done, còn lại đều Done. Velocity của Sprint này là bao nhiêu? (Đáp án: 5+5+3+2 = 15 điểm; hai item chưa Done không tính.)
- Forecast bằng throughput: Throughput 5 Sprint gần nhất của một đội là 9, 11, 10, 8, 12 item. Hãy đưa ra một range forecast hợp lý cho Sprint tới và giải thích vì sao bạn không nên hứa một con số chính xác.
- Tình huống ra quyết định: Sếp yêu cầu bạn (Scrum Master) ép đội tăng velocity 25% trong quý tới và dùng velocity để xếp hạng từng developer. Hãy viết 4–5 câu bạn sẽ phản hồi, dựa trên các nguyên tắc trong bài.
- Soi đáp án "by the book": Tìm 3 phát biểu sai phổ biến về velocity (ví dụ: "velocity bắt buộc trong Scrum") và viết lại cho đúng tinh thần Scrum Guide.
Tóm tắt
- Velocity = tổng điểm của các item đã Done trong một Sprint; nhìn theo xu hướng, đặc thù từng đội, không so sánh, không phải mục tiêu.
- Throughput = số lượng item Done trên một đơn vị thời gian; không cần estimation, hợp với tư duy flow và #NoEstimates.
- Cả hai đều là practice bổ trợ, KHÔNG nằm trong Scrum Guide, và đều là thước đo empirical (dựa trên lịch sử thực tế).
- Developers dùng chúng để forecast — chứ không commit — lượng công việc trong Sprint Planning. Thứ duy nhất được commit là Sprint Goal.
- Forecast là phán đoán xác suất, sống động, được điều chỉnh qua Daily Scrum; nó tôn trọng bản chất phức tạp và bất định của phát triển sản phẩm.
- Biến velocity thành KPI sẽ phá hỏng nó (point inflation, cắt chất lượng) — đây là anti-pattern và là bẫy thi quen thuộc.