Làm sao sắp xếp ưu tiên User Story trên Backlog

Tại sao cần sắp xếp ưu tiên User Story

Trong vai trò 1 Product Owner, bạn sẽ phải thường xuyên xác định ưu tiên Product Backlog để tối ưu. Việc sắp xếp ưu tiên xem những User Story nào cần phải được làm trước nhằm đảm bảo nhóm đang làm việc đúng việc vào đúng thời điểm. Cho dù dựa trên tài chính, khả năng hay con người, các lựa chọn của Product Owner sẽ luôn có tác động đến việc nhóm có thể tiến về phía trước nhanh như thế nào

Mục tiêu của quá trình này là sắp xếp ưu tiên hoàn thành và chuyển giao càng nhiều giá trị trong một đơn vị thời gian càng tốt. Nhiều khi một User Story có giá trị cao nhưng thời gian/chi phí phát triển lại dài và ngược lại.

Các phương pháp ưu tiên, về cơ bản là giúp Product Owner có thể cân bằng giữa giá trị mang lại và chi phí phát triển. Dưới đây là một số phương pháp sắp xếp ưu tiên thường được sử dụng.‍

HiPPO (highest paid person’s opinion)

Quyết định mức độ ưu tiên dựa trên quan điểm của người được trả lương cao nhất, hoặc người có chức vị cao nhất. Điều này xuất phát từ định kiến: người có lương cao hoặc chức vị cao thường là chuyên gia nên ý kiến của họ thường là đúng.

Ưu điểm của phương pháp này thường là quá trình sắp xếp ưu tiên được thực hiện nhanh. Tuy nhiên ngày nay, sản xuất sản phẩm thường là phức tạp và là sự tổng hợp quan điểm của nhiều bên; nên nếu chỉ dựa theo quan điểm của người có lương cao nhất có thể sẽ phiến diện.‍

FIFO (first in / first out, or entry sequenced) — in other words no effort to priorities or order work at all

Cách này rất đơn giản, công việc nào đến trước được làm trước, không cần thiết phải sắp xếp mức độ ưu tiên. Phương pháp này phù hợp với các team vận hành, tiếp nhận xử lý các yêu cầu dịch vụ.

Force Ranked (or Stack Ranked) — manually moved based on whatever

Cách này dựa trên sự thống nhất, biểu quyết của cả nhóm. Để thực hiện theo cách này, cần có danh sách các tiêu chí để nhóm có căn cứ đánh giá và ra quyết định tốt hơn.

Các tiêu chí càng rõ ràng càng tốt. Ví dụ: tiêu chí có thể là chi phí phát triển User Story, hoặc tiềm năng kinh doanh của User Story tạo ra trong năm tới. Mỗi tiêu chí có trọng số tương ứng với mức độ quan trọng. Mỗi thành viên của nhóm sẽ đánh số điểm các User Story trên BackLog, tổng hợp kết quả lại để ra số điểm cuối cùng.

Khuyến cáo số lượng User Story trên BackLog không nên quá 10 trong một lần đánh giá để tránh quá tải. Tất cả User Story trong BackLog được hiển thị trên bảng trắng, nhờ đó người tham gia sẽ có cái nhìn tổng quát và so sánh để để xếp hạng ưu tiên.

Phương án này cũng có thời gian thực hiện ưu tiên hóa nhanh nhưng chậm hơn phương pháp HiPPO. Phương pháp này giúp có quan điểm nhiều chiều hơn, nhưng sẽ đòi hỏi bản thân cả nhóm cần có tinh thần chủ động đóng góp và tinh thần phản biện.

MoSCoW (must have, should have, could have, won’t have this time)

Phương pháp này được sử dụng để giúp các bên liên quan chính hiểu được tầm quan trọng của các hạng mục trên BackLog. Từ viết tắt, MoSCoW, là viết tắt của: must-haves, Should-haves, can-haves, và sẽ Won't have.

Đôi khi, W (Won't Have) được sử dụng để đại diện cho những điều ước (Wish) của các bên liên quan thay vì phải làm ngay bây giờ.

Vì phương pháp này có sự phân loại rõ ràng chứ không chỉ là điểm số như Force Ranked nên việc nhóm của bạn thảo luận một cơ cấu thống nhất khi ra quyết định là quan trọng. Do đó trước khi phân tích MoSCoW, cần phải chuẩn bị:

• Đầu tiên, các bên liên quan cần thống nhất xác định các yếu tố và tiêu chí ưu tiên.
• Thảo luận về cách sẽ giải quyết bất kỳ sự bất đồng nào trong việc ưu tiên.
• Cuối cùng, bạn cũng sẽ muốn đạt được sự đồng thuận về tỷ lệ phần trăm tài nguyên mà bạn muốn phân bổ cho mỗi danh mục.
  

Sẽ rất tuyệt nếu kết quả cuối cùng chỉ có 20% là Must Have, nếu nhiều hơn, dường như nhóm của bạn không phù hợp với phương pháp này.

Highest Cost of Delay

Đây là một trong những cách xác định độ ưu tiên dựa theo giá trị và sự khẩn cấp. Nghĩa là bạn càng trì hoãn việc thực hiện một User Story, chi phí thiệt hại của nó càng lớn. Chi phí thiệt hại chính là giá trị mà User Story không tạo ra được khi chưa được hoàn thành.

Chi phí trì hoãn thường bị gây ra bởi

• Lợi thế cạnh tranh: nếu User Story/sản phẩm ra sau đối thủ cạnh tranh, thiệt hại sẽ là mất thị phần.
• User Story được sử dụng trực tiếp trong hoạt động kinh doanh tác động đến dòng tiền. Hoàn thành trễ sẽ gây ảnh hưởng lớn đến mức độ tín nhiệm.
  

Các căn cứ để tính chi phí trì hoãn bao gồm:

• Giá trị với người dùng: Giá trị tương đối mang lại cho khách hàng hoặc doanh nghiệp là gì? Có thể tác động đến doanh thu, kinh doanh như thế nào? Nếu trì hoãn, sẽ gây thiệt hại do không tạo được giá trị
• Thời gian: Có thời hạn cố định không? Khách hàng sẽ đợi hay chuyển sang giải pháp khác?
• Giảm rủi ro, tăng cơ hội: User Story tạo ra các cơ hội, khả năng kinh doanh mới, giảm rủi ro phát sinh hoặc sớm phát hiện rủi ro.
  

Ví dụ:

Nếu bạn làm xong toàn bộ hết 23 tuần rồi mới đưa vào áp dụng cả 4 User Story, Phần giá trị thiệt hại do mỗi tuần trì hoãn = $2,000 + $1,500 + $6,000 + $8,500 = $18,000. Cho 23 tuần trì hoãn sẽ là: $414,000

Nếu cứ làm theo thứ tự bình thường, xong User Story nào đưa vào sử dụng luôn, chi phí thiệt hại do trì hoãn sẽ là:

• Thiệt hại do trì hoãn A = 2 weeks x $2,000 = $4,000
• Thiệt hại do trì hoãn B = (2 + 4) weeks x $1,500 = $9,000
• Thiệt hại do trì hoãn C = (2 + 4 + 7) * $6,000 = $78,000
• Thiệt hại do trì hoãn D = (2 + 4 + 7 + 10) * $8,500 = 195,500
• Tổng cộng: $286,500.

Bây giờ, nếu ưu tiên User Story nào có Delay of Cost cao nhất làm trước, sắp xếp lại theo thứ tự này là: DCAB thì thiệt hại do trì hoãn sẽ là:

• Thiệt hại do trì hoãn D = 10 weeks x $8,500 = $85,000
• Thiệt hại do trì hoãn C = (10 + 7) weeks x $6,000 = $102,000
• Thiệt hại do trì hoãn A = (10 + 7 + 2) * $2,000 = $38,000
• Thiệt hại do trì hoãn B = (10 + 7 + 2 + 4) * $1,500 = $34,500
• Tổng cộng: $259,500.

WSJF (Weighted Shorted Job First)

Cách này sắp xếp mức độ ưu tiên dựa theo tỷ số giữa Chi phí do trì hoãn và Thời gian để làm ra User Story đó. Tỷ số nhỏ nhất sẽ quyết định User Story nào được làm trước.

Theo cách này áp dụng vào ví dụ trên trong Cost of Delay, thứ tự cần làm sẽ là: BDCA.

Nếu tính Cost of Delay sẽ là:

• Thiệt hại do trì hoãn B = 4 weeks x $1,500 = $6,000
• Thiệt hại do trì hoãn D = (4 + 10) weeks x $8,500 = $119,000
• Thiệt hại do trì hoãn C = (4 + 10 + 7) * $6,000 = $126,000
• Thiệt hại do trì hoãn A = (4 + 10 + 7 + 2) * $2,000 = $46,000
• Tổng cộng: $297,000.
  

Tuy tổng thiệt hại lớn hơn phương án chọn Cost of Delay cao nhất, nhưng bù lại, ngươì dùng sớm cóUser Story B để dùng đầu tiên sau 4 tuần thay vì phải đợi 10 tuần nếu đưa vào làm User Story D trước tiên.

Cách này sẽ cân bằng giữa lợi ích do thiệt hại vì trì hoãn và lợi ích do sớm có sản phẩm đưa đến tay người dùng.

Value Flow Rate

Phương pháp này không sử dụng đơn vị là Value - tiền và Duration - thời gian như trong Cost of Delay và WSJF. Phương pháp này sử dụng các đánh giá abstract của Team thể hiện dưới dạng Points, gồm có Value Points và Duration Points. Tỷ số giữa Value Points / Duration Points sẽ quyết định User Story nào cần được ưu tiên làm trước.

Việc lảng tránh sử dụng đơn vị tiền tệ và thời gian sẽ giúp hạn chế các định kiến cá nhân. Ví dụ một developer giỏi thường làm một User Story với thời gian ngắn, trong khi Developer khác ít kinh nghiệm sẽ cần nhiều thời gian hơn. Nếu về mặt chuyên môn, sự phức tạp về giải pháp để làm một User Story là giống nhau.

Kết luận

Mỗi phương pháp đều có ưu điểm và hạn chế riêng. Do đó, tùy vào bối cảnh khác nhau, trình độ khác nhau mà vận dụng phương pháp xác định ưu tiên cũng rất khác nhau.

Tuyển dụng Product Owner: Định hình hướng đi của giải pháp bán lẻ quốc tế. Môi trường làm việc từ xa, quản lý linh hoạt theo Agile