Mở đầu — vì sao bài này quan trọng
Hãy thành thật với nhau: đã bao nhiêu lần bạn ngồi trong một buổi estimation, cả team căng não tranh luận xem một task là 5 hay 8 story point, rồi đến cuối Sprint con số đó hóa ra chẳng đúng với thực tế? Estimation — ước lượng — là một trong những hoạt động tiêu tốn nhiều thời gian và gây nhiều tranh cãi nhất trong Agile. Và rồi xuất hiện một phong trào dám đặt câu hỏi gai góc: "Nếu chúng ta ngừng estimate hoàn toàn thì sao?"
Đó chính là #NoEstimates — một trong những cuộc tranh luận sôi nổi và dễ gây hiểu lầm nhất trong cộng đồng Agile suốt hơn một thập kỷ qua. Nhiều người nghe tên là phản ứng ngay: "Vô lý! Không estimate thì làm sao stakeholder biết khi nào xong?" Người khác lại tôn sùng nó như viên đạn bạc giải phóng team khỏi mọi gánh nặng. Cả hai phản ứng đều sai.
Bài này quan trọng vì với tư cách một Project Manager hay Scrum Master, bạn sẽ liên tục bị kẹp giữa hai áp lực: stakeholder muốn cam kết chắc chắn về thời gian và chi phí, còn team thì mệt mỏi vì những con số ước lượng vô nghĩa. Hiểu sâu cuộc tranh luận #NoEstimates không phải để bạn chọn phe, mà để bạn có một bộ công cụ tư duy: khi nào estimate có giá trị, khi nào nó là lãng phí, và những lựa chọn thay thế nào tồn tại. Đây là tư duy phản biện về một thực hành mà phần lớn người làm Agile xem là điều hiển nhiên.
Khái niệm cốt lõi
#NoEstimates thực sự là gì (và không phải là gì)
Trước hết, cần đính chính một hiểu lầm phổ biến nhất: #NoEstimates KHÔNG có nghĩa là "không bao giờ ước lượng bất cứ thứ gì". Cái tên — vốn là một hashtag được tạo ra để gây chú ý trên Twitter khoảng năm 2012 — đã vô tình làm hại chính phong trào, vì nó nghe quá tuyệt đối.
Bản chất của #NoEstimates là một câu hỏi mang tính thách thức: "Liệu chúng ta có thể đưa ra quyết định kinh doanh tốt mà cần ít, hoặc không cần, các estimate truyền thống dựa trên giờ công hay story point?" Đó là lời mời gọi đặt câu hỏi về thói quen, chứ không phải một mệnh lệnh cấm đoán.
Nguồn gốc phong trào
Phong trào gắn liền nhất với tên tuổi Vasco Duarte (tác giả cuốn sách NoEstimates), cùng với những tiếng nói như Woody Zuill và Neil Killick, từ khoảng năm 2012. Lập luận của họ xoay quanh ba điểm về sự lãng phí của estimation truyền thống:
- Estimate thường sai nghiêm trọng. Nghiên cứu và kinh nghiệm thực tế cho thấy phần lớn các ước lượng lệch trên 50% so với thực tế. Phần mềm là công việc tri thức (knowledge work) với độ bất định cao; càng cố ước lượng chính xác cho cái chưa biết, ta càng tự lừa dối.
- Estimate tốn thời gian. Hãy tính thử: một team 7 người dành 2 tiếng mỗi tuần cho refinement và estimation, nhân với 52 tuần — đó là gần 730 giờ công mỗi năm chỉ để đoán. Nếu kết quả đoán không cải thiện quyết định, đó là lãng phí ròng.
- Estimate dễ bị lạm dụng thành cam kết. Đây là điểm đau nhất. Một estimate (dự đoán) thường bị quản lý biến thành commitment (cam kết). Khi team "đoán" 3 tuần, con số đó lập tức trở thành deadline, và nếu trễ thì team bị quy trách nhiệm — dù bản chất đó chỉ là phỏng đoán ban đầu.
Lập luận phản biện: tại sao estimate vẫn có giá trị
Để công bằng, phía ủng hộ estimation cũng có lý lẽ mạnh. Estimate phục vụ những mục đích thật:
- Ra quyết định đầu tư. Một doanh nghiệp cần biết feature này "cỡ vài ngày" hay "cỡ vài tháng" để quyết có làm không. Đó là quyết định "go/no-go" thực sự cần một cảm nhận về quy mô.
- Phối hợp phụ thuộc. Khi đội Marketing cần biết khi nào tính năng ra mắt để chuẩn bị chiến dịch, một dự báo thời gian là cần thiết.
- Hợp đồng và ngân sách. Trong nhiều bối cảnh — đặc biệt outsourcing tại Việt Nam — khách hàng cần con số để ký hợp đồng và phê duyệt ngân sách.
Giải pháp thay thế mà #NoEstimates đề xuất
Điểm cốt lõi cần nhớ: #NoEstimates không bỏ trống chỗ của dự báo, mà thay nó bằng cách tiếp cận dựa trên dữ liệu thực tế (empirical) thay vì phỏng đoán:
- Đếm số lượng (counting) thay vì ước lượng kích thước. Thay vì gán point cho từng story, ta chỉ cần chia công việc thành các phần nhỏ và tương đối đồng đều, rồi đếm xem mỗi tuần team hoàn thành được bao nhiêu phần. Đây là khái niệm throughput — số item hoàn thành trong một khoảng thời gian.
- Dự báo bằng dữ liệu lịch sử. Nếu team trung bình hoàn thành 8 story mỗi tuần và backlog còn 40 story, ta dự báo khoảng 5 tuần — dựa trên dữ liệu thật, không phải đoán.
- Right-sizing. Rèn kỹ năng chẻ nhỏ công việc sao cho mỗi item đủ nhỏ (ví dụ làm xong trong 1-2 ngày). Khi các item đủ đồng đều, việc đếm trở nên đáng tin cậy hơn cả việc estimate point.
Tình huống thực tế
Ví dụ 1: Startup fintech tại TP.HCM thoát khỏi "địa ngục story point"
Một startup fintech ở Quận 1, TP.HCM — gọi là PayNhanh — có một team 6 developer xây dựng app ví điện tử. Mỗi buổi Sprint Planning kéo dài gần 3 tiếng, phần lớn thời gian dành cho tranh cãi Planning Poker. Tệ hơn, velocity dao động dữ dội: Sprint thì 32 point, Sprint thì 51 point, khiến mọi dự báo cho stakeholder đều vô nghĩa.
Scrum Master quyết định thử nghiệm #NoEstimates trong 8 Sprint. Họ bỏ point hoàn toàn, thay vào đó tập trung một kỹ năng duy nhất: chẻ mọi story thành các phần đủ nhỏ để hoàn thành trong 1-2 ngày. Họ chỉ đếm số story hoàn thành mỗi tuần.
Kết quả sau 2 tháng: throughput ổn định ở mức 9-11 story/tuần (biến động thấp hơn nhiều so với velocity point trước đó). Thời gian Planning giảm từ 3 tiếng xuống 50 phút. Và quan trọng nhất, khi CEO hỏi "khi nào xong module KYC với 33 story còn lại?", team trả lời tự tin: "Khoảng 3-4 tuần, dựa trên throughput thật của 8 tuần qua."
Bài học: Giá trị lớn nhất không đến từ việc "bỏ estimate", mà đến từ kỷ luật chẻ nhỏ công việc đồng đều. Khi các item đủ nhỏ và giống nhau, việc đếm cho dự báo tốt hơn cả việc đoán point.
Ví dụ 2: Công ty outsourcing Đà Nẵng — nơi #NoEstimates không phù hợp (nguyên bản)
Ngược lại, hãy xét một công ty gia công phần mềm tại Đà Nẵng ký hợp đồng fixed-price với khách hàng Nhật Bản. Một Scrum Master trẻ, hào hứng sau khi đọc về #NoEstimates, đề xuất bỏ estimation cho toàn bộ dự án.
Vấn đề lập tức xuất hiện. Khách hàng Nhật cần con số rõ ràng để ký hợp đồng trị giá 2,4 tỷ đồng và phê duyệt với ban giám đốc của họ. Mô hình "đếm throughput" của #NoEstimates đòi hỏi dữ liệu lịch sử của chính team đó trên chính loại công việc đó — thứ mà một dự án mới hoàn toàn chưa có. Không có dữ liệu lịch sử, không thể dự báo bằng đếm.
Công ty buộc phải quay lại estimation truyền thống cho giai đoạn báo giá hợp đồng, rồi mới chuyển sang theo dõi throughput khi dự án chạy được vài Sprint và đã có dữ liệu.
Bài học: #NoEstimates phụ thuộc mạnh vào dữ liệu lịch sử ổn định và quan hệ tin cậy linh hoạt. Trong bối cảnh hợp đồng fixed-price, dự án mới chưa có lịch sử, hay khách hàng yêu cầu cam kết cứng, estimation truyền thống vẫn cần thiết — ít nhất ở giai đoạn đầu.
Ví dụ 3: Team sản phẩm nội bộ tại một ngân hàng — đường lai (hybrid)
Một team phát triển nội bộ tại một ngân hàng lớn ở Hà Nội đã chọn con đường thực dụng nhất: lai giữa hai trường phái. Họ vẫn estimate ở mức thô (T-shirt sizing: S/M/L) cho mục đích lập roadmap quý và quyết định ưu tiên đầu tư — vì lãnh đạo cần cảm nhận quy mô để chọn giữa các sáng kiến. Nhưng ở cấp Sprint, họ bỏ point chi tiết, chỉ chẻ nhỏ story và theo dõi throughput cùng cycle time để dự báo ngắn hạn.
Sau 2 quý, Product Owner báo cáo rằng họ tiết kiệm khoảng 40% thời gian dành cho estimation mà vẫn giữ được khả năng dự báo cho cả lãnh đạo lẫn team.
Bài học: Trong thực tế, hầu hết các team trưởng thành không chọn cực đoan. Họ dùng estimate thô ở cấp chiến lược (nơi cần cảm nhận quy mô để ra quyết định lớn), và dùng dữ liệu empirical ở cấp thực thi (nơi cần dự báo chính xác ngắn hạn).
Hướng dẫn từng bước
Nếu bạn muốn thử nghiệm cách tiếp cận #NoEstimates một cách có trách nhiệm, đây là lộ trình:
- Đặt lại câu hỏi mục đích. Trước khi bỏ estimate, hãy hỏi từng loại estimate hiện có phục vụ quyết định nào. Estimate nào không dẫn tới một quyết định cụ thể — đó là ứng viên đầu tiên để loại bỏ.
- Rèn kỹ năng chẻ nhỏ (story splitting). Đây là nền tảng. Tập chia mọi backlog item thành các phần đủ nhỏ để hoàn thành trong 1-2 ngày. Đây là kỹ năng cần luyện, không phải tự nhiên có. Nếu một story không chẻ nhỏ được, đó là tín hiệu nó chưa được hiểu rõ.
- Bắt đầu thu thập dữ liệu throughput. Mỗi tuần (hoặc mỗi Sprint), đơn giản đếm số item đã Done. Ghi lại liên tục. Cần ít nhất 6-10 chu kỳ để có dữ liệu đủ tin cậy cho dự báo.
- Đo cycle time song song. Cycle time là thời gian từ lúc bắt đầu làm một item đến lúc hoàn thành. Theo dõi nó giúp bạn phát hiện item bị tắc nghẽn và dự báo thời gian hoàn thành từng phần.
- Dự báo bằng phép tính đơn giản — hoặc Monte Carlo. Cách cơ bản: số item còn lại chia cho throughput trung bình. Cách nâng cao: chạy mô phỏng Monte Carlo dựa trên phân bố throughput lịch sử để đưa ra dự báo theo xác suất ("85% khả năng xong trước ngày X").
- Trình bày dự báo dưới dạng dải xác suất, không phải một con số cứng. Thay vì "xong ngày 15", hãy nói "nhiều khả năng xong trong khoảng 12-18, với độ tin cậy cao nhất quanh ngày 15". Điều này phản ánh trung thực bản chất bất định.
- Đánh giá lại sau vài chu kỳ. So sánh: cách mới có giúp ra quyết định tốt hơn với ít công sức hơn không? Nếu có, mở rộng. Nếu không, giữ lại phần estimation có giá trị.
Lỗi thường gặp & mẹo
Lỗi 1: Hiểu #NoEstimates là "không cần kế hoạch". Đây là hiểu lầm tai hại nhất. #NoEstimates vẫn cần dự báo, vẫn cần roadmap — nó chỉ thay phương pháp dự báo từ đoán sang đo. Đừng dùng cái tên làm cái cớ để trốn tránh trách nhiệm dự báo.
Lỗi 2: Bỏ estimate nhưng quên chẻ nhỏ. Nếu bạn ngừng estimate mà không rèn kỹ năng chia story thành các phần đồng đều, throughput của bạn sẽ nhiễu loạn và vô dụng. Right-sizing là điều kiện tiên quyết, không phải tùy chọn.
Lỗi 3: Áp dụng cho dự án chưa có dữ liệu lịch sử. Như ví dụ Đà Nẵng, dự báo bằng đếm cần dữ liệu quá khứ. Dự án mới hoặc team mới ghép chưa có nền tảng này.
Lỗi 4: Biến #NoEstimates thành cuộc thánh chiến. Đừng tranh cãi ý thức hệ với stakeholder. Họ không quan tâm bạn theo phe nào — họ quan tâm có dự báo đáng tin để ra quyết định. Hãy nói ngôn ngữ của họ.
Mẹo: Cách thuyết phục stakeholder hoài nghi tốt nhất là chạy thử nghiệm song song. Trong vài Sprint, vừa estimate như cũ vừa theo dõi throughput. Cho họ thấy dự báo bằng dữ liệu thật chính xác ngang hoặc hơn estimate — bằng chứng thuyết phục hơn mọi lý thuyết.
Mẹo: Phân biệt rõ hai từ với stakeholder: estimate (dự đoán, có thể sai) và commitment (cam kết, phải giữ). Phần lớn xung đột về estimation đến từ việc lẫn lộn hai khái niệm này.
Bài tập thực hành
- Kiểm toán estimate. Liệt kê mọi hoạt động estimation team bạn đang làm (Planning Poker, ước lượng giờ, T-shirt sizing...). Với mỗi cái, viết ra quyết định cụ thể mà nó phục vụ. Đánh dấu cái nào không dẫn tới quyết định rõ ràng — đó là lãng phí tiềm năng.
- Mô phỏng dự báo bằng throughput. Lấy dữ liệu 8 Sprint gần nhất của team (hoặc tự tạo số giả định: ví dụ 9, 11, 8, 10, 12, 7, 10, 9 item/Sprint). Tính throughput trung bình. Nếu backlog còn 50 item, hãy dự báo số Sprint cần thiết. So sánh với cách dự báo bằng velocity point trước đây.
- Luyện chẻ nhỏ. Chọn một story lớn trong backlog hiện tại. Chẻ nó thành các phần, mỗi phần làm xong trong tối đa 2 ngày. Ghi lại bạn chẻ được bao nhiêu phần và phần nào khó chẻ nhất — phần khó chẻ thường là phần bạn hiểu chưa rõ.
- Viết kịch bản thuyết phục. Soạn một đoạn 5 câu giải thích cho một sếp hoài nghi tại sao bạn muốn thử dự báo bằng throughput thay vì point — nhấn mạnh lợi ích cho họ (dự báo đáng tin, tiết kiệm thời gian), không phải cho team.
Tóm tắt
#NoEstimates không phải mệnh lệnh "cấm ước lượng", mà là một câu hỏi phản biện mạnh mẽ: liệu ta có thể ra quyết định tốt với ít estimate truyền thống hơn? Khởi nguồn từ Vasco Duarte và những người khác khoảng năm 2012, phong trào chỉ ra ba điểm đau của estimation: thường sai nghiêm trọng, tốn thời gian, và dễ bị biến thành cam kết oan ức.
Giải pháp thay thế cốt lõi là chuyển từ phỏng đoán kích thước sang đo lường thực tế: chẻ nhỏ công việc đồng đều, đếm throughput, và dự báo bằng dữ liệu lịch sử thay vì cảm tính. Nhưng như các ví dụ PayNhanh, công ty Đà Nẵng và ngân hàng Hà Nội cho thấy, #NoEstimates không phải viên đạn bạc: nó tỏa sáng khi team có dữ liệu lịch sử ổn định và quan hệ linh hoạt, nhưng kém phù hợp với hợp đồng fixed-price hay dự án mới chưa có dữ liệu.
Với tư cách PM hay Scrum Master, bài học thực dụng nhất là tư duy hybrid: dùng estimate thô ở cấp chiến lược nơi cần cảm nhận quy mô, và dùng dữ liệu empirical ở cấp thực thi nơi cần dự báo chính xác. Đừng chọn phe — hãy chọn công cụ phù hợp với từng quyết định. Và luôn nhớ phân biệt giữa một dự đoán và một cam kết: phần lớn nỗi đau estimation đến từ việc lẫn lộn hai điều đó.