Mọi hạng mục đều "ưu tiên cao": xếp thứ tự backlog bằng chi phí trì hoãn (cost of delay) và WSJF
Khi mọi stakeholder đều nói hạng mục của mình là quan trọng nhất, Product Owner cần một cách so sánh có căn cứ. Chi phí trì hoãn hỏi "mỗi tuần chưa làm, ta mất gì", còn WSJF chia chi phí trì hoãn cho độ lớn công việc. Bài viết hướng dẫn cách tính, ví dụ và các giới hạn cần biết.
Tình huống liên quan

Rút ngắn 4 ngày tốn bao nhiêu: nén tiến độ bằng crashing theo chi phí biên và chi phí gián tiếp
Khi khách hàng muốn bàn giao sớm hơn, câu hỏi đúng không phải là "có làm được không" mà là "mỗi ngày rút ngắn tốn thêm bao nhiêu". Bài viết đi qua một ví dụ số đầy đủ: chọn hoạt động nén theo chi phí biên, theo dõi đường găng đổi chỗ và tìm điểm dừng khi tính cả chi phí gián tiếp và tiền phạt.

Sếp hỏi "bao giờ xong 40 hạng mục còn lại?": dự báo bằng mô phỏng Monte Carlo trên throughput thay vì cộng story point
Thay vì ngồi ước lượng lại từng hạng mục rồi chia cho velocity trung bình, đội có thể dùng chính lịch sử throughput của mình để mô phỏng hàng nghìn tương lai và trả lời sếp bằng một xác suất: 85% khả năng xong trong 10 tuần. Bài viết hướng dẫn cách làm, cách đọc kết quả và những giới hạn cần nói rõ.
Cho lập trình bắt đầu khi thiết kế mới xong một nửa: tính lợi và rủi ro làm lại của fast-tracking
Fast-tracking rút ngắn tiến độ bằng cách cho các hoạt động vốn nối tiếp chạy chồng lên nhau. Không tốn thêm tiền ngay, nhưng phải trả bằng rủi ro làm lại. Bài viết lượng hoá đánh đổi đó bằng giá trị kỳ vọng và gợi ý cách chọn mức chồng lấn hợp lý.

Ngày ra mắt đã chốt trước Tết, phạm vi thì chưa: lập kế hoạch phát hành bằng dải velocity "chắc có – có thể có – không kịp"
Khi ngày phát hành không được dời, câu hỏi đúng không còn là "bao giờ xong" mà là "đến ngày đó sẽ có những gì". Dùng velocity thấp và cao của chính đội để vạch hai đường trên backlog đã sắp thứ tự, PM chia phạm vi thành ba vùng và cập nhật sau mỗi sprint. Bài viết hướng dẫn cách tính và cách trình bày với nhà tài trợ.