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ợ.
Tình huống minh hoạ
Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ.
Một công ty vận tải hành khách ở miền Trung muốn ra mắt ứng dụng đặt vé xe khách trước cao điểm Tết. Ngày phát hành đã được ban giám đốc chốt và quảng cáo đã lên lịch, nên không thể dời. Từ nay đến đó, đội Scrum còn 6 sprint, mỗi sprint 2 tuần.
Product backlog của bản phát hành đã được Product Owner sắp thứ tự, tổng cộng 210 điểm. Trưởng phòng kinh doanh hỏi: "Đến ngày ra mắt, khách hàng sẽ dùng được những tính năng nào?"
Nếu lấy velocity trung bình nhân với số sprint, PM sẽ có một con số duy nhất và một lời hứa dễ vỡ. Đội chọn cách khác: lập kế hoạch phát hành theo dải velocity.
Bước 1: lấy dải velocity từ dữ liệu của đội
Velocity của 8 sprint gần nhất là: 21, 26, 18, 24, 30, 22, 25, 20 điểm. Trung bình khoảng 23 điểm, nhưng điều quan trọng hơn là độ dao động. Đội tính hai mức:
- Velocity thấp: trung bình 3 sprint thấp nhất (18, 20, 21) ≈ 20 điểm/sprint.
- Velocity cao: trung bình 3 sprint cao nhất (25, 26, 30) = 27 điểm/sprint.
Nhân với 6 sprint còn lại:
- Kịch bản thận trọng: 6 × 20 = 120 điểm.
- Kịch bản thuận lợi: 6 × 27 = 162 điểm.
Cách lấy "3 sprint thấp nhất, 3 sprint cao nhất" chỉ là một quy ước đơn giản. Đội có thể dùng phân vị hoặc mô phỏng nếu có nhiều dữ liệu hơn; điều cốt lõi là dùng dữ liệu thật của chính đội, không dùng con số mong muốn.
Bước 2: vạch hai đường lên backlog đã sắp thứ tự
Vì backlog đã được sắp theo giá trị và rủi ro, PM đếm điểm từ trên xuống và vạch hai đường:
| Vùng | Điểm cộng dồn | Ý nghĩa với kinh doanh |
|---|---|---|
| Chắc có | 0 – 120 | Tìm chuyến, chọn ghế, thanh toán qua ví điện tử, vé điện tử. Có thể đưa vào quảng cáo. |
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ý.
Thẻ nằm ở cột "Đang làm" 19 ngày mà không ai để ý: theo dõi tuổi hạng mục (work item age) để can thiệp sớm
Cycle time chỉ đo được khi việc đã xong — lúc đó đã quá muộn để cứu. Tuổi hạng mục (work item age) cho biết việc nào đang "già" ngay hôm nay. Bài viết giải thích chỉ số này, cách hiển thị trên bảng và cách dùng nó để thay đổi buổi họp hằng ngày.