Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Product Owner và trên bàn bạn đang có mười hạng mục, tất cả đều "quan trọng". Sếp muốn tính năng A, khách hàng lớn nhất đòi tính năng B, đội kỹ thuật cảnh báo nếu không làm C thì hệ thống sẽ sập trong vài tháng tới, còn marketing thì khẳng định D sẽ giúp tăng trưởng. Ai cũng đúng theo cách của họ. Và bạn — người duy nhất được trao quyền sắp xếp thứ tự Product Backlog — phải đưa ra một con số, một thứ tự rõ ràng.
Đây chính là khoảnh khắc mà cảm tính phản bội bạn. Khi mọi thứ đều "quan trọng", việc chọn theo giọng nói to nhất, theo người có chức vụ cao nhất, hay theo cái mà bạn thấy thoải mái nhất sẽ dẫn đến những quyết định tệ. WSJF — Weighted Shortest Job First — ra đời để giải quyết đúng vấn đề này: cho bạn một cách định lượng, có thể tranh luận và bảo vệ được, để xác định nên làm gì trước.
WSJF là một kỹ thuật được phổ biến rộng rãi bởi khung SAFe (Scaled Agile Framework), nhưng tư tưởng cốt lõi của nó — ưu tiên những công việc mang lại nhiều giá trị nhất trong thời gian ngắn nhất — vượt ra ngoài SAFe và áp dụng được cho bất kỳ Product Owner nào. Trong bài này, tôi sẽ giảng cho bạn không chỉ công thức, mà cả tư duy kinh tế đằng sau nó, để bạn dùng WSJF như một công cụ tư duy chứ không phải một bảng tính máy móc.
Khái niệm cốt lõi
Tư tưởng nền tảng: tối đa hóa giá trị trên một đơn vị thời gian
Nếu bạn chỉ nhớ một câu từ bài này, hãy nhớ câu này: làm những việc cho nhiều giá trị nhất với chi phí thực hiện nhỏ nhất, trước tiên. Đó là lý do tên gọi "Weighted Shortest Job First" — công việc ngắn nhất (nhưng có trọng số theo giá trị) thì làm trước.
Trực giác này rất giống cách bạn xếp hàng tại quầy thanh toán: nếu mục tiêu là phục vụ nhiều khách nhất trong thời gian ngắn nhất, bạn ưu tiên khách ít hàng trước. WSJF mở rộng ý tưởng đó cho backlog: thay vì "ít hàng", ta dùng "kích thước công việc", và thay vì coi mọi khách như nhau, ta cân nhắc giá trị mỗi việc mang lại.
Công thức WSJF
Công thức chính rất gọn:
WSJF = Cost of Delay / Job Size
Trong đó:
- Cost of Delay (CoD) — Chi phí của sự trì hoãn: nếu ta KHÔNG làm việc này ngay, ta mất bao nhiêu giá trị theo thời gian? Đây là phần "tử số", càng lớn càng nên ưu tiên.
- Job Size — Kích thước công việc: việc này tốn bao nhiêu công sức để hoàn thành? Đây là phần "mẫu số", càng nhỏ thì WSJF càng cao.
Phân rã Cost of Delay thành ba thành phần
SAFe đề xuất tính CoD bằng tổng của ba yếu tố:
CoD = User-Business Value + Time Criticality + Risk Reduction & Opportunity Enablement
- User-Business Value (Giá trị người dùng / kinh doanh): Tính năng này mang lại bao nhiêu giá trị cho người dùng và doanh nghiệp? Khách hàng có sẵn lòng trả tiền cho nó không? Nó giúp giữ chân khách, tăng doanh thu, hay giảm chi phí vận hành?
- Time Criticality (Tính cấp thiết về thời gian): Giá trị có suy giảm theo thời gian không? Có một thời điểm cụ thể (mùa lễ, hạn tuân thủ pháp lý, đối thủ sắp ra mắt) khiến việc trễ trở nên đắt giá? Nếu làm sớm hay muộn cũng như nhau thì điểm này thấp; nếu "trễ một tháng là mất cơ hội" thì điểm này cao.
- Risk Reduction & Opportunity Enablement (Giảm rủi ro & Mở ra cơ hội): Việc này có giúp giảm rủi ro kỹ thuật/kinh doanh, hay mở đường cho những cơ hội tương lai không? Ví dụ: dựng một nền tảng hạ tầng cho phép các tính năng sau triển khai nhanh hơn.
Thang đo Fibonacci điều chỉnh
Đây là chìa khóa thực hành mà nhiều người làm sai. Bạn KHÔNG ước lượng các con số tuyệt đối kiểu "tính năng này đáng 4,2 triệu đô". Thay vào đó, bạn dùng thang Fibonacci điều chỉnh: 1, 2, 3, 5, 8, 13, 20 và chấm điểm tương đối giữa các hạng mục.
Vì sao dùng Fibonacci? Vì khoảng cách giữa các số tăng dần phản ánh đúng sự bất định: khi việc càng lớn, ta càng khó phân biệt chính xác, nên thang đo nhảy bậc (5 rồi 8 rồi 13) thay vì tăng đều. Cách làm chuẩn là: trong mỗi cột (User-Business Value chẳng hạn), tìm hạng mục nhỏ nhất, gán cho nó số 1, rồi chấm các hạng mục còn lại tương đối so với nó. Làm tương tự cho từng cột.
Một bảng WSJF điển hình có dạng:
| Hạng mục | Value | Time Crit. | Risk/Opp | CoD (tổng) | Job Size | WSJF |
|---|---|---|---|---|---|---|
| A | 8 | 5 | 3 | 16 | 5 | 3,2 |
| B | 13 | 3 | 2 | 18 | 13 | 1,4 |
| C | 3 | 8 | 8 | 19 | 3 | 6,3 |
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử "ChợViệt" trước mùa Tết
Giả định một sàn TMĐT Việt Nam tên ChợViệt, đội PO đang đứng trước bốn hạng mục lớn ba tháng trước Tết:
- A. Tích hợp ví MoMo/ZaloPay: nhiều khách bỏ giỏ hàng vì thiếu phương thức thanh toán quen thuộc.
- B. Tính năng livestream bán hàng: marketing rất muốn, nhưng quy mô lớn.
- C. Gợi ý quà Tết theo lịch sử mua hàng: giá trị tốt nhưng phải xong trước Tết mới có ý nghĩa.
- D. Refactor hệ thống tồn kho: đội kỹ thuật cảnh báo nguy cơ bán vượt hàng khi tải tăng đột biến dịp Tết.
| Hạng mục | Value | Time Crit. | Risk/Opp | CoD | Job Size | WSJF |
|---|---|---|---|---|---|---|
| A (MoMo/ZaloPay) | 8 | 5 | 2 | 15 | 3 | 5,0 |
| B (Livestream) | 13 | 3 | 3 | 19 | 20 | 0,95 |
| C (Gợi ý quà Tết) | 5 | 13 | 2 | 20 | 8 | 2,5 |
| D (Refactor tồn kho) | 3 | 8 | 13 | 24 | 8 | 3,0 |
Bài học: WSJF cứu đội khỏi cái bẫy "làm cái hoành tráng nhất trước". Nó cũng cho PO một lập luận có số liệu để nói với marketing rằng livestream sẽ được làm, nhưng sau Tết, vì làm ngay bây giờ sẽ chiếm chỗ của ba việc hiệu quả hơn.
Ví dụ 2 — Startup fintech và ràng buộc tuân thủ pháp lý
Một startup fintech tại TP.HCM cung cấp ví trả góp. Họ có hai hạng mục cạnh tranh nhau giành Sprint tiếp theo:
- X. Tính năng "chia nhỏ hóa đơn": khách rất thích, dự kiến tăng tỷ lệ chuyển đổi.
- Y. Cập nhật quy trình eKYC theo thông tư mới của Ngân hàng Nhà nước: nếu không xong trước thời hạn pháp lý, công ty có nguy cơ bị xử phạt và treo giấy phép.
Diễn giải: Đây là tình huống kinh điển cho thấy vì sao Cost of Delay phải gồm cả Time Criticality và Risk. Nếu chỉ nhìn "khách thích gì", đội sẽ làm X và đẩy công ty vào rủi ro pháp lý. WSJF buộc các yếu tố ẩn — hạn chót pháp lý, rủi ro mất giấy phép — hiện ra thành con số và thắng một cách thuyết phục.
Bài học: WSJF rất mạnh trong việc làm nổi bật những công việc "không hào nhoáng" nhưng sống còn, như tuân thủ pháp lý hay giảm nợ kỹ thuật rủi ro cao.
Ví dụ 3 — Đội nền tảng nội bộ ở một ngân hàng số khu vực Đông Nam Á
Một ngân hàng số ở Singapore có đội platform phục vụ nhiều đội sản phẩm. PO của đội platform có ba hạng mục:
- P. Xây dựng SDK đăng nhập dùng chung: mỗi đội sản phẩm hiện tự code đăng nhập, tốn thời gian lặp lại.
- Q. Tối ưu thời gian phản hồi API tra cứu số dư: đang chậm gây phàn nàn nhẹ.
- R. Dashboard giám sát nội bộ: đội vận hành mong muốn.
Diễn giải: Thú vị là Q (việc nhỏ, cải thiện nhanh) lại có WSJF cao nhất và nên làm trước — một "quick win" rõ ràng. P, dù có giá trị chiến lược lớn về dài hạn nhờ Opportunity Enablement, lại tốn công nên xếp sau. WSJF không nói P không quan trọng; nó nói hãy giành quick win của Q trước rồi mới đầu tư vào P.
Bài học: Yếu tố "Risk Reduction & Opportunity Enablement" chính là nơi tư duy nền tảng/chiến lược được đưa vào công thức một cách định lượng, tránh việc đội platform luôn bị các tính năng "long lanh" của đội sản phẩm khác lấn át.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn chạy như một workshop ngắn 60–90 phút với những người liên quan:
- Chọn tập hạng mục so sánh được. Đừng đem một epic 6 tháng so với một story 2 ngày. WSJF cho kết quả tốt nhất khi các hạng mục cùng cấp độ — thường là các feature hoặc epic ngang nhau.
- Chấm cột User-Business Value theo cột dọc. Tìm hạng mục có giá trị nhỏ nhất, gán 1, rồi chấm tương đối các hạng mục khác theo thang 1, 2, 3, 5, 8, 13, 20.
- Chấm cột Time Criticality. Lặp lại cách chấm tương đối. Hỏi: "Giá trị có giảm theo thời gian không? Có hạn chót cứng không?"
- Chấm cột Risk Reduction & Opportunity Enablement. Hỏi: "Việc này giảm rủi ro gì? Mở ra cơ hội gì cho tương lai?"
- Cộng ba cột để ra Cost of Delay cho mỗi hạng mục.
- Chấm cột Job Size riêng biệt. Đây là ước lượng công sức tương đối, cũng theo Fibonacci. Lưu ý: Job Size không hẳn là story points của team, mà là ước lượng quy mô thực hiện ở mức epic/feature.
- Tính WSJF = CoD / Job Size cho từng hạng mục.
- Sắp xếp giảm dần theo WSJF và dùng kết quả này làm ĐẦU VÀO cho việc ordering Product Backlog của bạn — không phải mệnh lệnh tuyệt đối.
Lỗi thường gặp & mẹo
Lỗi 1 — Chấm điểm theo hàng ngang thay vì cột dọc. Nếu bạn chấm hết một hạng mục (Value, Time, Risk, Size) rồi mới sang hạng mục khác, bạn dễ bị "neo" vào ấn tượng tổng thể. Hãy chấm từng cột cho tất cả hạng mục trước, rồi mới sang cột tiếp.
Lỗi 2 — Coi WSJF là cỗ máy ra quyết định tự động. WSJF cho ra một con số, nhưng bạn vẫn là Product Owner. Con số là để bắt đầu cuộc tranh luận, không phải để kết thúc tư duy. Nếu giác quan của bạn mâu thuẫn với bảng, hãy quay lại xem mình chấm yếu tố nào sai — thường là Time Criticality hoặc Risk bị bỏ sót.
Lỗi 3 — Quên rằng WSJF cần tái tính định kỳ. Cost of Delay thay đổi theo thời gian (đặc biệt Time Criticality). Một hạng mục hôm nay WSJF thấp, ba tháng sau khi tới gần hạn chót có thể leo lên đầu bảng. Hãy chạy lại WSJF khi bối cảnh thay đổi đáng kể.
Lỗi 4 — Dùng số tuyệt đối thay vì tương đối. Đừng cố quy ra tiền hay ngày công thật. Sức mạnh của Fibonacci điều chỉnh nằm ở so sánh tương đối nhanh, đủ tốt để xếp thứ tự.
Lỗi 5 — Để Job Size bị thao túng. Vì Job Size nằm ở mẫu số, có người sẽ cố tình ước lượng việc mình thích là "nhỏ" để đẩy WSJF lên. Hãy để đội kỹ thuật chấm Job Size một cách độc lập với người bảo vệ giá trị.
Mẹo vàng: WSJF đặc biệt hữu ích khi bạn cần giải thích một quyết định ưu tiên cho stakeholder. Thay vì nói "tôi thấy nên làm cái này trước", bạn chỉ vào bảng và nói "cái này có WSJF cao gấp đôi vì giá trị tương đương nhưng làm nhanh hơn nhiều". Đó là sự khác biệt giữa một PO bị tranh cãi và một PO được tin tưởng.
Bài tập thực hành
Hãy áp dụng WSJF cho tình huống sau. Bạn là PO của một ứng dụng giao đồ ăn tại Hà Nội. Bạn có bốn hạng mục:
- Đặt món theo nhóm (group order) — người dùng yêu cầu nhiều, quy mô lớn.
- Sửa lỗi tính phí giao hàng sai trong giờ cao điểm — gây khiếu nại và hoàn tiền, làm nhanh.
- Tích hợp cổng thanh toán mới trước khi đối tác cũ ngừng hợp đồng trong 6 tuần — có hạn chót cứng.
- Chương trình tích điểm khách hàng thân thiết — marketing đề xuất, giá trị dài hạn.
- Lập bảng với các cột Value, Time Criticality, Risk/Opportunity, Job Size, dùng thang Fibonacci điều chỉnh.
- Chấm điểm theo cột dọc, tính CoD và WSJF cho từng hạng mục.
- Xếp thứ tự bốn hạng mục theo WSJF giảm dần.
- Viết 3–4 câu giải thích cho stakeholder vì sao hạng mục đứng đầu lại được làm trước, và vì sao "group order" — thứ nhiều người muốn nhất — có thể không đứng đầu.
Tóm tắt
WSJF — Weighted Shortest Job First — là một kỹ thuật ưu tiên định lượng giúp Product Owner trả lời câu hỏi khó nhất của nghề: làm gì trước? Công thức cốt lõi là WSJF = Cost of Delay / Job Size, trong đó Cost of Delay được phân rã thành ba yếu tố cộng lại: User-Business Value, Time Criticality, và Risk Reduction & Opportunity Enablement. Bạn chấm điểm tương đối theo thang Fibonacci điều chỉnh (1, 2, 3, 5, 8, 13, 20), theo từng cột dọc để tránh thiên kiến, rồi tính WSJF và xếp thứ tự giảm dần.
Sức mạnh thật sự của WSJF không nằm ở con số cuối cùng, mà ở chỗ nó buộc cả nhóm phải nói rõ ràng về giá trị, tính cấp thiết, rủi ro và chi phí — biến những cảm tính mơ hồ thành một cuộc tranh luận có cấu trúc. Nó giúp bạn phát hiện những quick win bị bỏ quên, bảo vệ những việc sống còn nhưng không hào nhoáng, và quan trọng nhất, cho bạn một lập luận có thể bảo vệ được trước stakeholder. Hãy nhớ: WSJF là đầu vào cho quyết định ordering của bạn, không phải mệnh lệnh thay thế tư duy của một Product Owner giỏi.