Estimate sai không đáng sợ — vòng feedback dài mới đáng sợ

Planning poker xong. Story “export PDF” — 8 point, “chắc xong sprint này”. Ba tuần sau demo: file ra đúng format, khách mở được, nhưng in ra trắng trang vì font embed sai.

Estimate không sai hoàn toàn. Team ship được thứ gì đó. Sai ở chỗ ba tuần mới biết — và lúc biết thì đã gắn thêm report khác, email template, queue worker cùng batch.

Ước lượng sai là bình thường. Quan trọng là feedback loop bao lâu.

Estimate sai — ai cũng từng

Planning fallacy không phải đặc sản của junior. Senior cũng lệch — chỉ lệch ít hơn một chút trên domain quen, và biết sớm hơn khi lệch.

Lý do estimate trượt:

• Unknown unknowns — integration thứ ba, policy browser, quota API
• Giả định ẩn — “chắc DB đủ nhanh”, “chắc QA pass một lèo”
• Scope creep ngụy trang — thêm “nhỏ thôi” không vào ticket

Đòi estimate hoàn hảo trước khi code giống đòi dự báo thời tiết chính xác đến giờ — tháng sau. Có thể làm tốt hơn. Không thể làm đúng mãi.

Vấn đề không phải “sai”. Vấn đề là sai bao lâu rồi mới phát hiện.

Feedback loop là gì?

Feedback loop = thời gian từ lúc giả định đến lúc bằng chứng phủ nhận hoặc xác nhận giả định đó.

Giả định: “Font embed ổn trên mọi PDF reader.” Bằng chứng: khách mở file trên Windows 10 + Acrobat cũ.

Loop ngắn: ship slice in thử ngày 2, khách thật báo ngày 3, sửa ngày 4.

Loop dài: build cả pipeline export tuần 3, QA nội bộ pass vì máy dev font đủ, demo tuần 4, khách báo tuần 5.

Cùng một bug. Khác giá sửa và lượng code dính chưởng.

Hình 1. Trái: học sớm, chỉnh rẻ. Phải: học muộn, sunk cost và niềm tin sprint đã gãy.

Loop dài làm estimate “tệ hơn” — retroactively

Estimate ban đầu có thể chỉ lệch 30%. Nhưng nếu ba tuần không có tín hiệu, team tiếp tục xây trên giả định sai. Retro thấy estimate “tệ” — thật ra là observability của giả định tệ.

Hình 2. Vạch vàng = plan. Đường xanh = thực tế. Khoảng trống không check = lệch tích lũy.

Đo loop bằng câu hỏi thẳng:

Story này, lần cuối team nhận tín hiệu từ prod / khách / metric là khi nào?

Nếu câu trả lời là “cuối sprint” — loop = cả sprint. Dù daily standup vẫn xanh.

Ba loại loop hay bị bỏ quên

1. Loop kỹ thuật — code merge, deploy staging, chạy trên data thật (masked). Không tính “PR approved” là xong.

2. Loop sản phẩm — người dùng (hoặc proxy: CS, sales, design) thấy luồng end-to-end, không phải component lẻ.

3. Loop vận hành — metric, log, alert cho biết feature được dùng và fail thế nào.

Team giỏi estimate vẫn lệch nếu chỉ rút loop (1) mà bỏ (2) và (3). CI xanh ≠ khách hài lòng.

Rút loop — không cần đổi framework

Không phải lúc nào cũng “bỏ estimate”. Rút loop trước:

Cách	Loop rút từ … → …
Vertical slice — một luồng mỏng end-to-end	tuần → ngày
Feature flag / dark launch	release train → vài giờ sau merge
Demo với data & môi trường giống prod	cuối sprint → giữa sprint
Canary / % traffic	big bang → có metric sớm
Dogfood nội bộ	khách đầu tiên phát hiện → team phát hiện trước

Hình 3. Slice mỏng: sai ở slice 1, sửa trước khi xây slice 2. Batch: sai ở cuối, kéo theo cả khối.

Ví dụ export PDF: slice 1 = một template, một font, upload S3, link tải — không queue, không email đẹp. Khách in thử tuần 1. Embed font fix tuần 1. Rồi mới thêm batch, branding, audit log.

Estimate 8 point có thể vẫn 8. Nhưng rủi ro gom ở tuần 1 thay vì tuần 5.

Estimate vẫn có việc — đừng vứt

Rút loop không có nghĩa bỏ planning. Estimate vẫn cần cho:

• Cam kết ngoài team — hợp đồng, launch marketing, phụ thuộc team khác
• Capacity — bao nhiêu story song song, ai on-call
• So sánh phương án — build vs buy, monolith vs tách service

Khác biệt: estimate là giả thuyết có date, không phải lời thề. Revisit khi loop trả về bằng chứng mới — giống ADR có “revisit trigger”, không phải dogma.

Trigger gợi ý:

• Sau mỗi slice ship — còn X point không, hay scope phải cắt?
• Metric / support ticket vượt ngưỡng sau 48h canary
• Reality gap > một tuần tiến độ trên burndown mà không có blockers rõ

Retro đúng câu hỏi

Thay vì “sao estimate sai?” — câu hay thành chuyện đay đá:

• Loop dài nhất trên story này là ở đâu? (spec freeze? QA queue? chờ khách?)
• Lần gần nhất nhận tín hiệu thật là khi nào?
• Slice tiếp theo có thể nhỏ hơn thế nào để check tuần sau?

Estimate sai lần này expected. Loop dài khiến sai đắt — đó mới là incident process.

Takeaway

Ước lượng lệch không phải dấu hiệu team kém. Dấu hiệu team mature là biết mình lệch sớm — và sửa rẻ.

Đừng săn estimate hoàn hảo trên board. Rút feedback loop: slice mỏng, ship sớm, metric sớm, demo trên môi trường giống prod. Sprint đỏ vì estimate sai một lần — đau. Sprint đỏ vì ba tuần không ai hỏi “khách in được chưa?” — đó là cách nuôi sunk cost bằng standup xanh.

Hỏi sprint tới: story lớn nhất, bao lâu nữa mới có tín hiệu thật? Nếu câu trả lời > một tuần — cắt slice, không cắt người estimate.