Mở đầu — vì sao bài này quan trọng
Hãy thử nhớ lại buổi Sprint Planning gần nhất của bạn. Đội ngồi quây quanh, ai đó mở Planning Poker, rồi tranh luận xem story này là 5 điểm hay 8 điểm. Mười lăm phút trôi qua chỉ để quyết định một con số mà — thành thật mà nói — chẳng ai dám chắc đúng. Cuối Sprint, story 5 điểm có khi mất gấp đôi thời gian so với story 8 điểm. Vậy con số đó để làm gì?
Câu hỏi khó chịu đó chính là điểm khởi đầu của phong trào #NoEstimates. Đây không phải lời kêu gọi "đừng bao giờ ước lượng", mà là một thách thức trực diện: Nếu việc ước lượng tốn nhiều công sức nhưng không cải thiện được độ chính xác của dự báo, thì tại sao ta vẫn làm? Thay vì đoán độ lớn của từng story, #NoEstimates đề xuất một cách tiếp cận dựa trên dữ liệu thật: đếm số lượng hạng mục công việc và dùng throughput lịch sử (số việc hoàn thành mỗi đơn vị thời gian) để dự báo tương lai.
Là một Scrum Master, bạn cần công cụ này trong toolbox vì hai lý do. Thứ nhất, nó giải phóng đội khỏi những cuộc tranh cãi vô bổ về điểm số, trả lại thời gian cho việc thực sự quan trọng: hiểu rõ công việc. Thứ hai — và quan trọng hơn — nó dạy đội tư duy bằng dữ liệu thực nghiệm (empirical), đúng tinh thần cốt lõi của Scrum. Bài này nằm trong nhóm các công cụ ước lượng của khóa học (cùng Planning Poker, T-Shirt Sizing, Magic Estimation ở các bài trước), nhưng nó đại diện cho một triết lý đối lập đáng để bạn nắm vững — kể cả khi đội bạn chưa sẵn sàng áp dụng hoàn toàn.
Khái niệm cốt lõi
#NoEstimates thực sự nói gì
#NoEstimates được Vasco Duarte và Woody Zuill phổ biến rộng rãi từ khoảng năm 2012. Luận điểm trung tâm rất đơn giản: bạn có thể dự báo khi nào một tập công việc hoàn thành mà không cần ước lượng độ lớn của từng việc, chỉ cần đếm số việc và biết tốc độ hoàn thành lịch sử của đội.
Hãy hình dung bằng phép so sánh giao thông. Nếu bạn muốn biết mất bao lâu để đi 30 km, bạn có hai cách. Cách một: đo độ dốc, ổ gà, đèn đỏ của từng đoạn đường rồi cộng lại (giống story points). Cách hai: nhìn lại 10 chuyến đi tương tự, thấy trung bình mỗi chuyến 30 km mất 45 phút, và dự báo chuyến này cũng tầm đó (giống throughput). Cách hai nhanh hơn, và bất ngờ là thường chính xác không kém — bởi dữ liệu lịch sử đã tự động "hấp thụ" mọi yếu tố phức tạp mà bạn không cần phân tích thủ công.
Throughput là gì
Throughput là số lượng hạng mục công việc (story, task, bug — tùy đội định nghĩa) mà đội hoàn thành trong một khoảng thời gian cố định, thường là một Sprint hoặc một tuần.
Ví dụ, throughput của đội qua 6 Sprint gần nhất: 7, 9, 6, 8, 7, 10 items. Đây là dữ liệu thật, không phải dự đoán. Từ chuỗi số này, ta có thể trả lời câu hỏi kinh điển của stakeholder: "Bao giờ xong 40 story còn lại trong backlog?"
Giả định nền tảng: chuẩn hóa kích thước
Đây là điểm tối quan trọng mà nhiều người bỏ qua khi nói về #NoEstimates, và cũng là phần ghi chú gốc của bài này nhấn mạnh. Việc đếm item chỉ đáng tin khi các item có kích thước tương đối đồng đều. Nếu một item là "sửa lỗi chính tả" và item kế là "xây toàn bộ module thanh toán", thì đếm "2 items" hoàn toàn vô nghĩa.
Vậy làm sao đạt được sự đồng đều đó mà không cần... ước lượng? Câu trả lời là chia nhỏ công việc nhất quán (consistent story splitting). Đội rèn kỹ năng cắt mỗi story xuống một kích thước "vừa miệng" — đủ nhỏ để hoàn thành trong vài ngày. Khi mọi story đều rơi vào khoảng kích thước hẹp đó, sự khác biệt giữa chúng đủ nhỏ để định luật số lớn (law of large numbers) tự cân bằng: vài story to hơn trung bình sẽ được bù bởi vài story nhỏ hơn. Đây là lý do bạn không cần đo từng cái — bạn chỉ cần kỷ luật chia nhỏ.
Cycle time và biểu đồ — anh em của throughput
Bên cạnh throughput (đo số lượng), #NoEstimates thường đi kèm cycle time — thời gian từ lúc một item bắt đầu được làm đến khi hoàn thành. Hai chỉ số này bổ trợ nhau: throughput trả lời "bao nhiêu việc xong mỗi tuần", cycle time trả lời "mỗi việc mất bao lâu".
Công cụ dự báo mạnh nhất của trường phái này không phải phép tính trung bình đơn giản, mà là mô phỏng Monte Carlo: máy tính "rút thăm" ngẫu nhiên hàng nghìn lần từ lịch sử throughput của đội để tạo ra một phân phối xác suất. Kết quả không phải một con số duy nhất ("xong trong 8 tuần") mà là một dải xác suất ("85% khả năng xong trong 9 tuần hoặc sớm hơn"). Cách diễn đạt theo xác suất này trung thực hơn nhiều so với một deadline cứng nhắc.
Tình huống thực tế
Ví dụ 1 — Startup fintech ở TP.HCM thoát khỏi "địa ngục Planning Poker"
Một startup ví điện tử tại Quận 1, TP.HCM (gọi là VíNhanh) có đội 6 người. Mỗi Sprint Planning kéo dài 3 tiếng, trong đó gần 90 phút chỉ để chơi Planning Poker cho khoảng 12 story. Anh Scrum Master nhận ra một điều: dù tốn công như vậy, velocity (theo điểm) vẫn dao động thất thường giữa 28 và 52 điểm — gần như không dùng được để dự báo.
Anh quyết định thử nghiệm trong một quý: bỏ chấm điểm, chỉ đếm story, với điều kiện đội cam kết chia nhỏ mọi story xuống dưới 3 ngày làm việc. Sau 5 Sprint, anh thu được throughput: 8, 7, 9, 8, 8. Độ ổn định cao đến bất ngờ. Khi CEO hỏi "30 tính năng trong roadmap quý sau bao giờ xong?", thay vì cộng điểm, anh chạy một bảng tính Monte Carlo đơn giản và trả lời: "Với throughput hiện tại, 85% khả năng xong trong 4 Sprint, tức khoảng 8 tuần."
Bài học: Thời gian Planning giảm từ 3 tiếng xuống còn 75 phút. Quan trọng hơn, vì đã loại bỏ tranh cãi điểm số, đội dồn năng lượng vào việc chia nhỏ tốt hơn — và chính kỹ năng đó mới là thứ làm dự báo chính xác lên.
Ví dụ 2 — Công ty outsourcing và bài toán cam kết với khách hàng Nhật
Một công ty gia công phần mềm ở Hà Nội nhận dự án cho khách hàng Nhật Bản. Khách hàng quen với mô hình cam kết chặt và liên tục hỏi "tính năng X giao ngày nào?". Đội từng dùng story points, nhưng mỗi lần báo cáo lại phải "dịch" điểm sang ngày — một bước trung gian dễ sai và dễ bị khách chất vấn.
Đội chuyển sang theo dõi throughput theo tuần và vẽ một biểu đồ tích lũy (số story hoàn thành cộng dồn theo thời gian). Throughput trung bình là 4 story/tuần với độ dao động từ 3 đến 5. Khi khách hỏi về một gói gồm 20 story, đội không trả lời "5 tuần" (con số lạc quan dựa trên trung bình), mà nói: "Trong kịch bản thận trọng — throughput 3/tuần — gói này hoàn tất trong 7 tuần; ở kịch bản tốt là 5 tuần. Chúng tôi cam kết mốc 7 tuần." Khách hàng Nhật vốn coi trọng sự chắc chắn lại thích cách nói này hơn, vì nó minh bạch về rủi ro.
Bài học: #NoEstimates không có nghĩa là "không cam kết". Nó cho phép bạn cam kết bằng dải xác suất dựa trên dữ liệu thật, vốn đáng tin và dễ bảo vệ hơn một con số đơn lẻ rút ra từ điểm số chủ quan.
Ví dụ 3 — Khi #NoEstimates thất bại vì bỏ qua giả định chuẩn hóa
Một đội thương mại điện tử ở Đà Nẵng nghe nói #NoEstimates "nhanh và hiện đại" nên áp dụng ngay: bỏ hết ước lượng, đếm item, dùng throughput. Nhưng họ bỏ qua phần cốt lõi — kỷ luật chia nhỏ. Backlog của họ trộn lẫn đủ loại: có "đổi màu nút" nằm cạnh "tích hợp cổng thanh toán quốc tế".
Kết quả: throughput nhảy loạn xạ — 12, 3, 15, 4 — vì mỗi Sprint chứa hỗn hợp item to nhỏ khác nhau. Dự báo trở nên vô dụng, stakeholder mất niềm tin, và đội kết luận sai rằng "#NoEstimates không hoạt động".
Bài học: #NoEstimates không phải là "bỏ tư duy về kích thước", mà là chuyển công sức từ chấm điểm sang chia nhỏ nhất quán. Bỏ qua bước này thì throughput chỉ là chuỗi số nhiễu loạn. Đây chính là cái bẫy phổ biến nhất, và là lý do giả định chuẩn hóa luôn được nhắc đến đầu tiên.
Hướng dẫn từng bước
Dưới đây là quy trình áp dụng forecasting dựa trên throughput cho đội của bạn.
Bước 1 — Thống nhất "item" là gì. Cùng đội định nghĩa rõ đơn vị đếm: thường là story đã sẵn sàng làm (ready). Quyết định có đếm bug và spike hay không, và giữ định nghĩa đó nhất quán. Sự nhất quán quan trọng hơn việc chọn "đúng".
Bước 2 — Rèn kỷ luật chia nhỏ. Đặt một heuristic đơn giản, ví dụ: "Mọi story phải hoàn thành được trong tối đa 3 ngày." Story nào lớn hơn phải được tách trước khi vào Sprint. Đây là khoản đầu tư quyết định toàn bộ độ tin cậy của phương pháp.
Bước 3 — Thu thập throughput lịch sử. Ghi lại số item hoàn thành (đúng Definition of Done) mỗi Sprint hoặc mỗi tuần. Cần tối thiểu 5–6 điểm dữ liệu để chuỗi số có ý nghĩa thống kê; nhiều hơn càng tốt.
Bước 4 — Chọn cách dự báo.
- Nhanh và đơn giản: Lấy throughput trung bình và khoảng (min–max). Ví dụ trung bình 8/Sprint, dải 6–10. Còn 40 item thì cần khoảng 4–7 Sprint.
- Chính xác hơn: Chạy mô phỏng Monte Carlo. Có nhiều mẫu Google Sheets miễn phí và công cụ như ActionableAgile làm việc này. Nó cho ra câu trả lời dạng "85% khả năng xong trong N tuần".
Bước 6 — Cập nhật liên tục. Mỗi Sprint, bổ sung điểm dữ liệu mới và chạy lại dự báo. Throughput là chỉ số sống; dự báo của bạn tự động "học" khi đội thay đổi.
Lỗi thường gặp & mẹo
Lỗi: Bỏ qua chuẩn hóa kích thước. Như ví dụ 3, đây là cái chết phổ biến nhất. Mẹo: Trước khi tin throughput, hãy nhìn độ dao động của nó. Nếu dải quá rộng (ví dụ 3 đến 15), gần như chắc chắn việc chia nhỏ chưa nhất quán — sửa khâu refinement trước.
Lỗi: Hiểu #NoEstimates là "không cần suy nghĩ". Ngược lại hoàn toàn. Bạn vẫn phải tư duy sâu về phạm vi và cách chia công việc; chỉ là không quy nó thành điểm số. Công sức được dịch chuyển, không biến mất.
Lỗi: Dùng dữ liệu quá ít. Dự báo từ 2–3 Sprint là đoán mò có trang trí. Mẹo: chờ đủ ít nhất 5–6 điểm; trong lúc đó dùng tạm khoảng rộng và nói rõ với stakeholder rằng độ tin cậy sẽ tăng dần.
Lỗi: Đưa stakeholder một con số chắc nịch. "Xong trong đúng 8 tuần" là lời mời gọi thất vọng. Mẹo: luôn nói theo xác suất hoặc dải. Sự trung thực về bất định lại xây dựng niềm tin tốt hơn.
Lỗi: Áp đặt #NoEstimates lên đội chưa sẵn sàng. Nếu tổ chức đang gắn chặt với story points hoặc hợp đồng theo điểm, việc bỏ ngang gây xung đột. Mẹo: chạy song song một Sprint — vừa chấm điểm như cũ vừa âm thầm đếm item — rồi so sánh độ chính xác của hai cách dự báo. Để dữ liệu thuyết phục thay vì lý thuyết.
Mẹo bổ sung: Với đội mới, hãy bắt đầu bằng việc chỉ đếm và quan sát throughput trong vài Sprint mà chưa vội bỏ ước lượng. Khi đội thấy throughput ổn định và dự báo từ nó khớp thực tế, họ sẽ tự nguyện chuyển đổi — bền vững hơn nhiều so với áp đặt từ trên xuống.
Bài tập thực hành
Bài tập 1 — Dự báo bằng tay. Đội của bạn có throughput 6 Sprint gần nhất: 7, 5, 8, 6, 7, 9 (items). Backlog còn 45 item. a) Tính throughput trung bình. b) Dùng kịch bản thận trọng (throughput thấp nhất) và lạc quan (cao nhất) để ước lượng số Sprint cần thiết. c) Viết một câu báo cáo stakeholder theo dạng dải xác suất thay vì con số đơn lẻ.
Bài tập 2 — Kiểm tra giả định chuẩn hóa. Lấy backlog hiện tại của đội bạn (hoặc một đội bạn biết). Xem 10 story gần nhất đã hoàn thành và ước lượng thô (chỉ trong đầu) xem chúng có kích thước tương đối đồng đều không. Nếu không, hãy chọn 2 story lớn nhất và thử chia mỗi cái thành các phần nhỏ hơn, mỗi phần làm xong trong tối đa 3 ngày.
Bài tập 3 — Thiết kế thử nghiệm. Soạn một đề xuất ngắn (nửa trang) để bán ý tưởng chạy thử #NoEstimates trong một quý cho Product Owner của bạn. Nêu rõ: bạn sẽ đo gì, chạy song song với phương pháp cũ ra sao, và sau bao lâu thì đánh giá thành bại dựa trên tiêu chí nào.
Bài tập 4 — Phản biện. Liệt kê 3 tình huống mà bạn nghĩ #NoEstimates không phù hợp (gợi ý: hợp đồng cố định giá, dự án có nhiều việc một-lần-duy-nhất không lặp lại, đội quá mới chưa có lịch sử). Với mỗi tình huống, giải thích vì sao và bạn sẽ dùng công cụ nào thay thế.
Tóm tắt
#NoEstimates không phải lời kêu gọi "ngừng suy nghĩ", mà là một sự dịch chuyển công sức: thay vì đổ thời gian vào việc gán điểm cho từng story, đội đầu tư vào kỹ năng chia nhỏ công việc nhất quán rồi để throughput lịch sử làm việc dự báo. Cốt lõi nằm ở ba ý: (1) đếm item thay vì chấm điểm, (2) điều này chỉ đúng khi các item được chuẩn hóa kích thước tương đối qua chia nhỏ kỷ luật, và (3) dự báo nên được truyền đạt theo xác suất — lý tưởng là qua mô phỏng Monte Carlo — chứ không phải con số deadline cứng.
Là Scrum Master, giá trị lớn nhất bạn rút ra không hẳn là việc bỏ hẳn ước lượng, mà là tư duy đứng sau nó: tin vào dữ liệu thực nghiệm hơn dự đoán chủ quan, và trung thực về sự bất định. Kể cả khi đội bạn vẫn dùng Planning Poker, việc song song theo dõi throughput sẽ cho bạn một "thước đo thực tế" để kiểm chứng — và đó là một mũi tên rất đáng có trong toolbox của bạn.