Ưu tiên backlog khi việc nào cũng gấp: chọn cách nào?

Năm việc “gấp” trong một buổi sáng

Đây là tình huống minh họa. Bạn là PO của một app bán trà online. Sáng thứ Hai, trước giờ họp sprint, bạn nhận năm yêu cầu từ năm người khác nhau. Ai cũng dùng chữ “gấp”.

• Kinh doanh muốn có mã giảm giá riêng cho khách thân thiết để chạy đợt khuyến mãi cuối tháng.
• Kế toán báo đối tác cổng thanh toán sẽ ngừng hỗ trợ phiên bản kết nối cũ vào ngày 30.
• Chăm sóc khách hàng than nhiều khách gọi hỏi vì không nhận được email xác nhận đơn.
• Giám đốc vừa xem app của đối thủ và muốn làm lại trang chủ cho hiện đại hơn.
• Marketing muốn thêm đăng nhập bằng Zalo để khách mới đăng ký nhanh hơn.

Team chỉ làm được hai, cùng lắm ba việc trong sprint tới. Bạn phải chọn. Và quan trọng không kém, bạn phải nói cho bốn người còn lại vì sao việc của họ chưa được làm, theo cách họ chấp nhận được.

Bài này không dạy cách xử lý từng yêu cầu riêng lẻ. Phần đó đã có ở bài về feature request. Bài này nói về lúc nhiều yêu cầu cùng tranh nhau một chỗ: chọn phương pháp nào để so, tách gấp thật khỏi gấp do cảm giác, và trình bày đánh đổi sao cho mọi người cùng nhìn thấy.

• Xử lý một feature request từ stakeholder

Vì sao ưu tiên backlog lại khó với PO mới?

Backlog là danh sách mọi việc team có thể làm cho sản phẩm, xếp theo thứ tự. Scrum Guide ghi rõ Product Owner chịu trách nhiệm sắp thứ tự này, và PO là một người, không phải một hội đồng. Nghe thì đơn giản. Thực tế khó vì mấy lý do.

• Mỗi người chỉ thấy phần việc của mình. Kinh doanh thấy doanh số, chăm sóc khách hàng thấy cuộc gọi, giám đốc thấy đối thủ. Không ai sai, nhưng không ai nhìn thấy cả năm việc cùng lúc, trừ PO.
• Chữ “gấp” bị dùng cho mọi thứ. Khi ai cũng nói gấp, chữ đó mất nghĩa. Bạn cần cách khác để biết việc nào thật sự không chờ được.
• Người mới thường chưa có quyền lực về chức danh. Người gửi yêu cầu có thể là sếp hoặc người có thâm niên hơn. Không có lý do rõ ràng, quyết định của bạn rất dễ bị lật.
• Ưu tiên một việc nghĩa là đẩy lùi việc khác. Phần đẩy lùi thường không được nói ra, nên stakeholder chỉ thấy “PO không làm việc của mình”.

Vì vậy, mục tiêu không phải tìm ra một thứ tự hoàn hảo. Mục tiêu là có một thứ tự đủ hợp lý, mà bạn giải thích được trong hai phút, và mọi người hiểu mình cần làm gì nếu muốn thay đổi nó.

Value vs effort, MoSCoW hay RICE: chọn cái nào?

Có rất nhiều phương pháp ưu tiên. Với người mới, ba cách dưới đây là đủ. Chúng không loại trừ nhau. Điều cần biết là mỗi cách trả lời một câu hỏi khác.

Value vs effort là cách đơn giản nhất. Bạn chấm mỗi việc theo hai trục: giá trị mang lại và công sức phải bỏ ra, rồi đặt chúng vào bốn ô. Cách này nhanh và dễ vẽ lên bảng trắng trong cuộc họp.

MoSCoW chia việc thành Must have (bắt buộc), Should have (nên có), Could have (có thì tốt) và Won't have (lần này không làm). Theo ProductPlan, cách này do Dai Clegg đặt ra khi làm ở Oracle. Điểm mạnh nhất của nó là nhóm Won't have: nói rõ ngay từ đầu những gì sẽ không có, để không ai bất ngờ lúc phát hành. Điểm yếu là nó không xếp hạng bên trong từng nhóm, nên cần thêm một cách khác nếu có nhiều việc cùng là Must.

RICE do Intercom giới thiệu, gồm Reach (bao nhiêu người bị ảnh hưởng trong một khoảng thời gian), Impact (mỗi người được tác động nhiều hay ít, chấm theo thang 3, 2, 1, 0,5 và 0,25), Confidence (bạn tin các ước lượng đến đâu, thường là 100%, 80% hoặc 50%) và Effort (công sức, tính bằng người-tháng). Điểm bằng Reach nhân Impact nhân Confidence, chia cho Effort. Chính Intercom cũng nói điểm RICE không nên dùng như một luật cứng.

Một cách chọn thực tế: dùng value vs effort khi bạn mới vào và chưa có dữ liệu, MoSCoW khi có một mốc phát hành cần chốt phạm vi, RICE khi backlog dài và bạn cần so nhiều ý tưởng một cách bớt cảm tính. Dù chọn cách nào, giá trị lớn nhất là buộc mọi người nói ra giả định của mình.

Làm sao tách gấp thật khỏi gấp do cảm giác?

Trước khi chấm điểm bất cứ thứ gì, hãy lọc ra những việc có hạn chót thật. Những việc này không nên đem ra so điểm với các việc khác, vì hậu quả của việc trễ hạn không nằm trong công thức nào.

Gấp do cảm giác vẫn là thật với người gửi. Chăm sóc khách hàng mệt vì nghe khách phàn nàn cả ngày, giám đốc lo vì thấy đối thủ đẹp hơn. Bạn không cần phủ nhận cảm giác đó. Bạn chỉ cần không để nó tự động thay đổi kế hoạch của cả team. Thay vào đó, đưa việc đó vào nhóm so điểm và để lý do của nó được cân bằng lý do của các việc khác.

Các bước ưu tiên backlog có thể giải thích được

Ghép các phần trên lại, bạn có một quy trình bốn bước. Với năm, mười yêu cầu, toàn bộ có thể làm trong một buổi chiều.

Ở bước 1, mỗi yêu cầu cần được làm rõ tới mức nói được vấn đề trong một câu. Nếu chưa làm được, hãy quay lại hỏi người gửi trước khi chấm điểm. Chấm điểm một yêu cầu mơ hồ chỉ cho ra một con số mơ hồ.

Ở bước 3, phần công sức nên do kỹ sư ước lượng, không phải PO đoán. Phần giá trị và số người bị ảnh hưởng nên dựa vào dữ liệu nếu có: số cuộc gọi hỗ trợ, số đơn mỗi tháng, số khách đang dùng tính năng liên quan. Nếu không có, ghi rõ “ước đoán” và hạ mức tin cậy xuống.

Làm sao cho stakeholder thấy được đánh đổi?

Nhiều căng thẳng về ưu tiên đến từ việc người khác không nhìn thấy cái giá của một lựa chọn. Khi giám đốc nói “làm trang chủ trước đi”, câu đó nghe như một việc thêm vào. Thực chất nó là một việc khác bị đẩy ra. Việc của PO là làm cho phần bị đẩy ra hiện lên.

• Nói bằng cặp. Thay vì “team không làm được”, hãy nói “nếu làm trang chủ trong sprint này thì việc sửa email xác nhận lùi sang sprint sau, thêm vài trăm khách nữa sẽ gặp lỗi”.
• Để mọi người thấy cùng một danh sách. Một bảng chung, ai cũng xem được, tốt hơn năm cuộc trao đổi riêng với năm người.
• Ghi rõ giả định. Mỗi con số đi kèm nguồn hoặc chữ “ước đoán”. Người khác có thể phản bác giả định, thay vì phản bác bạn.
• Nói rõ điều gì sẽ làm thay đổi thứ tự. Ví dụ: “nếu kinh doanh có số liệu cho thấy đợt khuyến mãi mang lại nhiều đơn hơn dự tính, mình xem lại vào thứ Sáu”.

Khi một stakeholder vẫn không đồng ý, đừng cố thắng trong cuộc trao đổi đó. Đưa ra đánh đổi rõ ràng, và nếu cần, đưa lên người có quyền quyết định cao hơn kèm đủ thông tin. Cách nói “chưa” mà vẫn giữ quan hệ có trong bài riêng về nói không với stakeholder.

• Nói không với stakeholder mà không mất lòng

Ví dụ: chấm điểm năm yêu cầu trong app bán trà

Quay lại năm yêu cầu sáng thứ Hai. Đây là ví dụ minh họa, mọi con số đều là giả định để bạn thấy cách tính. Reach tính theo số khách trong một quý, Effort theo người-tháng do kỹ sư ước lượng.

Cách đọc bảng này quan trọng hơn con số. Việc nâng cấp cổng thanh toán có điểm thấp nhất bảng, vì khách không thấy gì thay đổi (Impact 0,25) và việc tích hợp tốn công. Nhưng nó đã qua ba câu hỏi lọc: có ngày cụ thể, có thông báo của đối tác, không có cách tạm. Vì vậy nó làm trước, vì sau ngày 30 khách không thanh toán được. Bảng vẫn chấm nó để bạn thấy: nếu chỉ nhìn điểm, bạn sẽ xếp nó cuối cùng. Khi làm thật, việc có hạn chót thật được tách riêng từ đầu, không cần đem ra so điểm.

Sửa lỗi email xác nhận đứng thứ hai vì công sức nhỏ và có bằng chứng rõ từ số cuộc gọi hỗ trợ. Mã giảm giá đứng thứ ba. Nó có một mốc là đợt khuyến mãi cuối tháng, nhưng đó là mốc do công ty tự đặt, có thể dời, và kinh doanh có cách tạm là gửi mã chung qua email. Vì vậy nó không được xếp là hạn chót thật.

Đăng nhập Zalo và trang chủ có mức tin cậy thấp. Hướng tốt hơn là thu thêm dữ liệu trước khi làm: đo xem bao nhiêu khách bỏ dở ở bước đăng ký, hay trang chủ hiện tại có làm khách rời đi không. Nếu số liệu tốt hơn giả định, điểm sẽ tăng và thứ tự sẽ đổi. Đó là điều bạn nói với marketing và giám đốc, thay vì một câu “chưa làm” trống không.

Kết quả: sprint tới làm việc nâng cấp thanh toán và sửa email xác nhận. Nếu còn chỗ, làm phần nhỏ nhất của mã giảm giá. Hai việc còn lại có hẹn ngày xem lại kèm dữ liệu cần thu.

Mẫu ghi chú ưu tiên một trang

Sau khi chốt thứ tự, gửi cho mọi stakeholder liên quan một ghi chú ngắn. Một trang là đủ. Mục tiêu là ai đọc cũng biết việc của mình đang ở đâu, vì sao, và cần gì để thay đổi. Bạn copy mẫu dưới đây rồi sửa theo cách xưng hô trong team.

Ưu tiên sprint [số] ([ngày bắt đầu] đến [ngày kết thúc])

Mục tiêu của sprint: [một câu, một mục tiêu, ví dụ: khách thanh toán được bằng cổng mới trước hạn chót của đối tác]

Sẽ làm:
1. [Việc] vì [lý do ngắn, kèm bằng chứng hoặc hạn chót]
2. [Việc] vì [lý do]

Nếu còn chỗ:
3. [Việc] vì [lý do]

Chưa làm trong sprint này:
- [Việc] vì [lý do]. Xem lại vào [ngày]. Cần thêm: [dữ liệu hoặc điều kiện]
- [Việc] vì [lý do]. Xem lại vào [ngày]. Cần thêm: [dữ liệu hoặc điều kiện]

Giả định chính:
- [Con số hoặc giả định], nguồn: [dữ liệu / người xác nhận / ước đoán]

Điều gì sẽ làm thay đổi thứ tự:
- [Ví dụ: có thêm khách lớn gặp lỗi, đối tác dời hạn chót]

Nếu anh/chị thấy thứ tự này chưa hợp lý, phản hồi em trước [ngày, giờ] kèm lý do hoặc số liệu để mình cân nhắc lại.

Phần “Chưa làm” là phần quan trọng nhất của ghi chú. Mỗi dòng cần một ngày xem lại và một điều kiện cụ thể. Không có hai thứ đó, người gửi sẽ nhắn hỏi lại mỗi tuần. Phần “Giả định chính” giúp cuộc tranh luận chuyển sang con số, không còn là chuyện ai nói to hơn.

Lỗi thường gặp khi ưu tiên backlog

• Để điểm số quyết thay. Công thức chỉ phản ánh giả định bạn đưa vào. Nếu kết quả trông sai, hãy xem lại giả định, đừng nhắm mắt làm theo.
• Chấm điểm hạn chót thật như mọi việc khác. Việc có ngày và hậu quả cụ thể cần được tách ra trước, nếu không nó có thể bị xếp sau một việc điểm cao hơn.
• Ưu tiên theo chức danh người gửi. Yêu cầu của sếp vẫn cần qua cùng câu hỏi như mọi người. Nếu sếp vẫn muốn làm trước, hãy nói rõ việc nào bị lùi và để sếp quyết với đủ thông tin.
• Đổi phương pháp liên tục. Tuần này RICE, tuần sau MoSCoW làm stakeholder không so được các quyết định với nhau. Chọn một cách, dùng ổn định ít nhất vài sprint.
• Tự ước lượng công sức. PO đoán công sức thay kỹ sư thì dễ đoán sai, và team không thấy mình là một phần của quyết định.
• Chỉ báo việc được làm. Không nói việc nào bị lùi thì stakeholder sẽ tự hiểu là bị quên.

Tóm tắt

• Ưu tiên backlog là một quyết định cần giải thích được. Phương pháp chỉ giúp cuộc trao đổi bớt cảm tính.
• Value vs effort hợp để so nhanh, MoSCoW hợp để chốt phạm vi một đợt phát hành, RICE hợp khi nhiều ý tưởng cạnh tranh và có chút dữ liệu.
• Tách hạn chót thật ra trước bằng ba câu hỏi: có ngày cụ thể không, hậu quả có kiểm chứng được không, có cách tạm không.
• Làm cho đánh đổi hiện lên: nói bằng cặp “làm việc này thì việc kia lùi”, dùng một danh sách chung, ghi rõ giả định.
• Gửi ghi chú ưu tiên một trang sau mỗi lần chốt, với ngày xem lại và điều kiện cho từng việc chưa làm.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

Ai quyết thứ tự ưu tiên trong backlog?

Theo Scrum Guide, Product Owner chịu trách nhiệm sắp thứ tự Product Backlog. Stakeholder góp thông tin và lý do, còn PO đưa ra thứ tự cuối cùng và giải thích được nó.

Nên dùng RICE hay MoSCoW khi mới làm PO?

MoSCoW hợp khi cần chốt phạm vi cho một đợt phát hành có hạn. RICE hợp khi có nhiều ý tưởng cần so với nhau và bạn có chút số liệu về số người bị ảnh hưởng. Người mới có thể bắt đầu bằng value vs effort rồi chuyển dần.

Làm sao biết một yêu cầu gấp thật hay không?

Hỏi: nếu tháng này chưa làm thì chuyện gì xảy ra, vào ngày nào, và ai chịu hậu quả. Gấp thật thường có một mốc ngày và một hậu quả cụ thể như hợp đồng, quy định hay hệ thống ngừng chạy.

Nguồn kiểm tra

• Scrum Guide 2020: Product Owner
• Intercom: RICE prioritization
• ProductPlan: MoSCoW prioritization

Bài liên quan

• User story là gì? Cách viết cho người mới, kèm mẫu và ví dụ: Mẫu “Là…, tôi muốn…, để…” là phần dễ. Bài này chỉ cách chọn đúng người dùng, đúng vấn đề và cắt story đủ nhỏ, kèm ví dụ trước và sau.
• Acceptance criteria là gì? Cách viết để QA kiểm thử được: Cách viết acceptance criteria rõ đến mức QA đọc xong là biết phải thử gì, kèm ví dụ mã giảm giá và mẫu dùng ngay.
• Cách nói không với sếp và stakeholder mà không mất lòng: Ba cách nói không thay cho một chữ “không”, cách xử lý khi người yêu cầu là sếp hoặc CEO, lúc nào nên escalate, kèm hội thoại mẫu và tin nhắn theo từng cấp.
• Sprint planning là gì? PO cần chuẩn bị gì trước buổi họp: Checklist chuẩn bị 1 đến 2 ngày trước sprint planning, cách dẫn phần “làm gì” và cách viết Sprint Goal, kèm mẫu dùng ngay.