Trong hầu hết các nhóm sản phẩm, backlog là một nơi mà sự khẩn cấp đi để chết. Mọi thứ nhập hàng nó đều khẩn cấp khi nó được thêm — một khiếu nại của khách hàng, một yêu cầu bán hàng, một tính năng đối thủ cạnh tranh, một ý tưởng bên trong. Sáu tháng sau, tất cả đều vẫn ở đó, và tất cả đều vẫn cảm thấy khẩn cấp, và không ai khá chắc chắn điều nào để làm tiếp theo.
Vấn đề không phải là sự thiếu hụt các công cụ. Có hàng chục khung ưu tiên: RICE, MoSCoW, Kano, ICE, điểm số có trọng số. Vấn đề là hầu hết các khung yêu cầu một loại độ chính xác sai lệch — gán số cho những người ăn may — làm cho chúng cảm thấy chặt chẽ trong khi thực sự chỉ là rửa tiền cảm giác ruột qua một bảng tính.
Những gì thực sự hoạt động đơn giản hơn: hai chiều, thành thật được đánh giá, và kỷ luật để hành động dựa trên kết quả.
Ưu tiên sụp đổ thành hai câu hỏi. Thứ nhất: bạn cải thiện bao nhiêu kết quả mà chúng tôi quan tâm? (Tác động.) Thứ hai: nó sẽ tốn chi phí bao nhiêu để cung cấp nó? (Nỗ lực.) Mọi thứ khác hoặc là một tinh tế của những hai cái này hoặc là một sự phao buồm từ chúng.
Độ tin cậy đôi khi được thêm vào như một chiều thứ ba — "chúng tôi chắc chắn bao nhiêu về tác động?" — và nó đáng để cần ghi nhớ. Nhưng trong thực tế, hầu hết các nhóm biết khi họ đoán. Kỷ luật là gắn nhãn cho đó là thành thật, không để ghi bàn nó trên thang 1–5 và thêm nó vào một công thức.
Phần khó khăn không phải là hiểu lưới — đó là thành thật khi điền vào nó. Mọi đội có các tính năng họ muốn xây dựng mà thuộc về "Mầm mống thời gian" nhưng giữ được phân loại lại như "Các cược lớn." Khung chỉ hoạt động nếu nhóm có thể thành thật về tác động.
Tác động là chiều mà các nhóm tìm thấy khó khăn nhất để đánh giá, vì nó thường yêu cầu dự đoán tương lai. Cám dỗ là ghi bàn nó bằng số và cảm thấy khoa học về nó. Một cách tiếp cận tốt hơn là định tính nhưng có cấu trúc.
Hỏi ba câu hỏi cho mỗi tính năng được xem xét:
Các nhóm đánh giá nỗ lực thấp một cách có hệ thống. Điều này được ghi chép tốt — nó liên quan đến sự sai lạc và thiên kiến lạc quan — và nó đặc biệt là nâng cao cho các tính năng mà chạm vào nhiều hệ thống, yêu cầu phối hợp trên các đội, hoặc liên quan đến các khả năng mà nhóm chưa xây dựng.
Hai thực hành giúp. Thứ nhất, luôn luôn hỏi kỹ thuật trước khi ghi bàn nỗ lực, không phải sau. Những người quản lý sản phẩm người quản lý nỗ lực đơn phương hầu như luôn luôn đánh giá thấp. Thứ hai, sử dụng khái niệm "những điều ăn may ăn may" như một số nhân nỗ lực rõ ràng. Bất kỳ tính năng nào mà chạm vào một khu vực mã hóa mới, một API của bên thứ ba, hoặc một luồng người dùng chưa được kiểm tra gần đây xứng đáng được một điểm số nỗ lực 1.5x cao hơn công việc rõ ràng gợi ý.
Hầu hết sự khẩn cấp trong một backlog sản phẩm không phải là sự khẩn cấp thực — đó là tính gần đây. Một khách hàng than phiền tuần trước, vì vậy yêu cầu của họ cảm thấy bức xúc. Một đối thủ cạnh tranh ra mắt một cái gì đó tháng trước, vì vậy phù hợp với nó cảm thấy quan trọng. Nhưng tính gần đây không giống như tầm quan trọng, và phản ứng lại tính gần đây là một trong những cách đáng tin cậy nhất để làm công việc thực sự quan trọng trượt.
Một bài kiểm tra thực tế: hỏi bản thân mình có bạn vẫn sẽ xem xét điều này khẩn cấp nếu bạn đã nghe nói về nó sáu tháng trước thay vì tuần trước. Nếu câu trả lời là không, nó là sự sai lệch tính gần đây ở lại công việc, không phải ưu tiên chiến lược. Ghi nhật ký nó, đánh giá nó một cách bình tĩnh chống lại lưới, và chống lại kéo để theo dõi nhanh nó chỉ vì nó tươi mới.
Lưới không phải lúc nào cũng tạo ra một câu trả lời sạch sẽ. Hai mục đáp ứng trong cùng một bậc tứ giác với các điểm số tương tự, và bạn vẫn phải chọn một. Trong những trường hợp này, hai bộ gỡ lỏng là hữu ích: sự liên kết chiến lược (cái nào di chuyển bạn gần hơn đến nơi bạn muốn ở 18 tháng?) và reversibility (cái nào khó hơn để hoàn tác nếu nó sai?). Thích cái mục mà chiến lược hơn phù hợp và có khả năng đảo ngược hơn.