RICE/WSJF cho bạn thứ hạng. Nhưng khi cần chốt "release 2.0 gồm cái gì", bạn cần phân loại: Must / Should / Could / Won't (this time). MoSCoW biến một danh sách xếp hạng thành cam kết phạm vi mà cả team và stakeholder đồng thuận.
Ý nghĩa 4 nhóm
- Must have: Thiếu nó thì release thất bại / không dùng được / vi phạm pháp lý.
- Should have: Quan trọng nhưng có cách xoay xở tạm nếu thiếu.
- Could have: Tốt thì có, thiếu cũng không sao — "đệm" để cắt khi trễ.
- Won't have (this time): Cố ý loại khỏi release này (không phải bỏ vĩnh viễn). Ghi rõ để chặn scope creep.
AI giúp gì
AI giỏi thử thách nhãn "Must". Mọi stakeholder đều muốn gắn Must. AI đóng vai "luật sư phản biện": "Nếu thiếu item này, release có thật sự fail không, hay chỉ kém đẹp?". Nó cũng giúp diễn đạt lý do Won't để giao tiếp không gây mất lòng.
Ví dụ cụ thể
Release app đặt lịch v2. Stakeholder gắn Must cho cả 10 item.
Prompt mẫu
Vai trò: Trợ lý PO áp dụng MoSCoW cho một release. Hãy PHẢN BIỆN nghiêm khắc nhãn "Must".
Định nghĩa: Must = thiếu thì release thất bại/không dùng được/vi phạm pháp lý.
Should = quan trọng nhưng có phương án tạm. Could = có thì tốt. Won't = cố ý hoãn.
Mục tiêu release: cho phép khách tự đặt & đổi lịch online.
Danh sách item (ẩn danh):
1. Đặt lịch theo khung giờ trống
2. Nhắc lịch qua email
3. Đổi/hủy lịch
4. Thanh toán online
5. Đồng bộ Google Calendar
... (dán đủ)
Yêu cầu:
1. Đề xuất nhãn MoSCoW cho từng item, kèm 1 câu lý do.
2. Với mỗi item bạn gán Must, hỏi tôi "nếu thiếu, release có THẬT SỰ fail không?".
3. Cảnh báo nếu tổng Must quá lớn so với một release gọn.
4. Soạn giúp 1 câu giải thích nhã nhặn cho các item Won't để tôi báo stakeholder.
AI thường hạ nhiều "Must" xuống Should/Could kèm câu hỏi phản biện. Bạn dùng câu hỏi đó để họp và chốt.
MoSCoW khác gì RICE/WSJF và khi nào dùng
RICE và WSJF trả lời "thứ tự làm là gì". MoSCoW trả lời câu hỏi khác: "release này CAM KẾT gồm những gì". Bạn thường dùng nối tiếp: xếp hạng bằng RICE/WSJF để biết cái nào đáng làm trước, rồi dùng MoSCoW để vẽ đường ranh giới phạm vi cho một release cụ thể có deadline. Một item hạng cao trong RICE vẫn có thể là "Should" nếu release vẫn dùng được khi thiếu nó; ngược lại một item hạng thấp có thể là "Must" nếu nó là điều kiện pháp lý bắt buộc. Vì thế MoSCoW không mâu thuẫn mà bổ sung cho xếp hạng: nó chuyển một danh sách trừu tượng thành một cam kết mà cả team và stakeholder cùng ký vào.
Các bước làm
- Lấy top item từ RICE/WSJF làm đầu vào (MoSCoW không thay thế xếp hạng, nó đóng gói xếp hạng thành scope).
- Chạy prompt phản biện Must.
- Với mỗi Must, trả lời thẳng câu hỏi "thiếu thì có fail không?". Nếu không → hạ nhãn.
- Kiểm tra ngân sách: tổng effort của Must ≤ ~60% năng lực.
- Viết rõ danh sách Won't-this-time và lý do → dán vào release note nội bộ để chặn scope creep.
- Chốt cùng stakeholder bằng chính các câu hỏi phản biện của AI.
Template: Bảng MoSCoW release
| Item | Nhãn (M/S/C/W) | Nếu thiếu thì sao? | Effort | Lý do | Câu giải thích cho stakeholder |
Sai lầm thường gặp
- "Must" tràn lan. Nếu mọi thứ đều Must thì chẳng có gì là Must. Dùng AI phản biện, nhưng bạn quyết.
- Bỏ trống Won't. Không ghi Won't → scope creep giữa sprint. Won't là công cụ bảo vệ phạm vi.
- Để AI chốt nhãn thay bạn. AI không biết ràng buộc hợp đồng/chính trị nội bộ; nhãn cuối là của bạn.
- Ảo giác lý do pháp lý: AI có thể tuyên bố "cái này bắt buộc theo luật" mà không đúng. Kiểm chứng mọi lý do compliance với người thật.
- Phụ thuộc quá mức: Câu giải thích do AI soạn cần bạn đọc lại cho đúng giọng và sự thật trước khi gửi stakeholder.