Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa nhận một backlog có 80 item cần ước lượng trước khi lập kế hoạch quý. Nếu dùng Planning Poker để bàn từng item một, bạn và đội sẽ ngồi cả buổi chiều, mệt nhoài, và những con số cuối cùng vẫn không chính xác hơn là bao. Đây chính là lúc T-Shirt Sizing tỏa sáng.
T-Shirt Sizing (ước lượng theo cỡ áo: XS, S, M, L, XL) là một kỹ thuật ước lượng tương đối (relative estimation) cực kỳ nhanh và trực quan. Thay vì cố gắng nói "việc này mất bao nhiêu ngày" — một câu hỏi mà não bộ con người trả lời rất tệ — chúng ta hỏi "việc này to hay nhỏ so với những việc khác?". Con người ước lượng tương đối giỏi hơn ước lượng tuyệt đối rất nhiều. Bạn khó nói chính xác một quả dưa hấu nặng bao nhiêu kilogram, nhưng bạn biết ngay nó nặng hơn quả cam.
Với vai trò Scrum Master, T-Shirt Sizing là một công cụ bạn nên có sẵn trong "hộp đồ nghề". Nó đặc biệt hữu ích ở các thời điểm: refinement nhanh đầu sprint, ước lượng cả một epic lớn, lập kế hoạch roadmap, hoặc khi đội mới hình thành và chưa quen với story point. Nó cũng dễ tiếp cận với cả những stakeholder không kỹ thuật — sếp kinh doanh hiểu ngay "cỡ XL" nghĩa là "việc lớn", trong khi nói "13 story point" thì họ ngơ ngác.
Trong bài này, chúng ta tập trung riêng vào T-Shirt Sizing: ý nghĩa từng cỡ, cách quy đổi, cách chạy một phiên ước lượng, và những cái bẫy thường gặp. Các kỹ thuật ước lượng khác như Planning Poker (Bài 17), Magic/Affinity Estimation (Bài 19) hay #NoEstimates (Bài 20) sẽ được bàn riêng — ở đây ta chỉ nói về cỡ áo.
Khái niệm cốt lõi
Ý tưởng nền tảng: ước lượng tương đối, không tuyệt đối
T-Shirt Sizing mượn hệ thống cỡ áo quen thuộc — XS, S, M, L, XL — để gán "kích thước" cho từng hạng mục công việc. Điểm mấu chốt: ta không gán con số chính xác, ta gán một "rổ" (bucket) kích thước. Mỗi cỡ tương ứng với một khoảng nỗ lực, và việc phân loại diễn ra bằng cách so sánh các item với nhau hơn là tính toán độc lập.
Lý do tâm lý học đằng sau rất vững: nghiên cứu về ước lượng phần mềm liên tục cho thấy con người dở tệ trong việc đoán "bao nhiêu giờ" nhưng khá tốt trong việc xếp hạng "to hơn / nhỏ hơn". T-Shirt Sizing khai thác đúng thế mạnh đó, và bằng cách dùng các "rổ" rộng, nó cố tình loại bỏ sự chính xác giả tạo (false precision) — điều mà các con số kiểu "3.5 ngày" hay gây ra.
Các cỡ và ý nghĩa
Dưới đây là cách quy chiếu phổ biến, dựa trên dàn ý gốc của bài. Lưu ý: các mốc thời gian chỉ mang tính tham khảo để đội hình dung — bản chất vẫn là so sánh tương đối.
- XS — trivial (khoảng 1 ngày): Việc cỏn con. Sửa một chữ sai, đổi màu nút bấm, cập nhật một dòng cấu hình. Rủi ro gần như bằng không, không cần bàn nhiều.
- S — small (khoảng 2–3 ngày): Việc nhỏ, rõ ràng. Một tính năng đơn giản, một màn hình form cơ bản. Đội hiểu rõ phải làm gì.
- M — medium (khoảng 1 tuần): Việc trung bình. Có vài phần phải ghép lại, có thể chạm tới một dịch vụ khác, cần test cẩn thận. Đây thường là "kích thước trung tâm" mà mọi thứ khác được so chiếu.
- L — large (khoảng 2 tuần): Việc lớn. Nhiều thành phần, có yếu tố chưa chắc chắn, cần phối hợp giữa nhiều người. Đây là dấu hiệu nên cân nhắc tách nhỏ (split) trước khi đưa vào sprint.
- XL — extra large (lớn hơn 2 tuần, thường là cả một epic): Quá to để làm gọn trong một sprint. XL gần như luôn là tín hiệu "CẦN tách nhỏ". Đừng bao giờ commit một XL nguyên khối vào sprint; hãy coi nó là một lời mời cho buổi refinement.
Thang đo và mối quan hệ với story point
T-Shirt Sizing thường được dùng độc lập, nhưng nhiều đội ánh xạ (map) cỡ áo sang story point để dùng trong velocity về sau. Một bảng quy đổi điển hình theo dãy Fibonacci:
- XS → 1
- S → 2
- M → 3 hoặc 5
- L → 8
- XL → 13 hoặc 20
Khi nào dùng T-Shirt Sizing thay vì kỹ thuật khác
T-Shirt Sizing tỏa sáng khi: (1) cần ước lượng nhanh một lượng lớn item; (2) ước lượng ở mức epic/roadmap, nơi độ chi tiết thấp; (3) đội mới chưa quen story point; (4) có stakeholder không kỹ thuật cần hiểu kết quả. Nó kém phù hợp khi đội cần độ chi tiết cao cho việc lập sprint backlog cụ thể — lúc đó các kỹ thuật chi tiết hơn sẽ hợp lý hơn.
Tình huống thực tế
Ví dụ 1 — Tiki và backlog 60 item trước mùa sale
Một đội phát triển tại một sàn thương mại điện tử lớn ở TP.HCM (gọi là đội Checkout, lấy bối cảnh kiểu Tiki) chuẩn bị cho mùa sale 11/11. Product Owner mang đến một backlog 60 item — từ "thêm banner đếm ngược" đến "tích hợp cổng thanh toán trả góp mới". Họ chỉ có một buổi sáng để ước lượng toàn bộ nhằm quyết định cái gì kịp, cái gì không.
Scrum Master, chị Hằng, quyết định không dùng Planning Poker (sẽ mất cả ngày). Thay vào đó, chị dán năm cột XS–S–M–L–XL lên tường (bối cảnh offline) và cho đội phân loại nhanh. "Thêm banner đếm ngược" được xếp ngay vào S. "Tích hợp cổng trả góp mới" ban đầu bị quăng vào XL — cả đội đồng ý ngay đây là epic, không thể làm trong một sprint. Chỉ trong 75 phút, cả 60 item đã được phân loại.
Kết quả: PO nhìn bức tranh tổng thể thấy có tới 8 item cỡ XL và L chiếm phần lớn năng lực. Chị quyết định hoãn 5 trong số đó sang sau mùa sale, và yêu cầu tách nhỏ 3 cái còn lại trong buổi refinement tuần sau.
Bài học: T-Shirt Sizing không cần đến con số chính xác để ra quyết định lớn. Việc nhìn thấy "có quá nhiều cỡ L/XL" đã đủ để PO điều chỉnh phạm vi. Tốc độ chính là giá trị.
Ví dụ 2 — Startup fintech và cái bẫy "neo theo người to mồm"
Một startup fintech ở Hà Nội, đội 6 người, dùng T-Shirt Sizing trong refinement. Vấn đề: anh tech lead luôn lên tiếng đầu tiên và nói to: "Cái này M thôi, dễ mà." Mọi người gật theo. Sau ba sprint, đội phát hiện velocity dao động dữ dội và nhiều item "M" thực ra mất gấp đôi thời gian — vì các bạn dev backend ít nói biết rõ có những phần phức tạp mà tech lead không thấy.
Scrum Master nhận ra đây là hiện tượng "anchoring" (neo) và "groupthink". Anh đổi cách chạy: mỗi người viết cỡ mình nghĩ ra giấy note riêng, lật cùng lúc. Ở item "tích hợp eKYC", tech lead viết M nhưng hai bạn backend viết L. Cuộc thảo luận lộ ra rằng việc gọi API định danh có nhiều trường hợp lỗi cần xử lý — thông tin mà nếu không hỏi sẽ chẳng bao giờ nổi lên.
Bài học: Phải để mọi người chọn cỡ độc lập trước, rồi mới thảo luận về chỗ lệch. Chính sự bất đồng (divergence) mới là vàng — nó báo hiệu có hiểu lầm hoặc rủi ro ẩn. Nếu để người to tiếng neo đầu tiên, bạn mất hết giá trị đó.
Ví dụ 3 — Agency phần mềm và việc dịch cỡ áo cho khách hàng
Một agency phần mềm ở Đà Nẵng làm dự án outsourcing cho khách Nhật. Khách hàng business không hiểu story point, nhưng họ cần biết "tính năng này to cỡ nào để báo ngân sách". Đội dùng T-Shirt Sizing như ngôn ngữ trung gian: khi trình bày roadmap, họ nói "Module quản lý kho cỡ L, module báo cáo cỡ XL nên ta nên chia hai giai đoạn."
Để giữ tính nhất quán, đội thống nhất một "item tham chiếu vàng" (golden reference): màn hình đăng nhập đã làm xong là chuẩn "M". Mọi item mới đều so với màn đăng nhập đó. Nhờ vậy, dù dự án kéo dài 8 tháng và có thành viên mới vào, cách hiểu về cỡ vẫn ổn định.
Bài học: T-Shirt Sizing là cầu nối giao tiếp tuyệt vời với người không kỹ thuật, và một "item tham chiếu" cụ thể giúp cả đội calibrate (hiệu chỉnh) chung một thước đo, tránh việc mỗi người hiểu "cỡ M" một kiểu.
Hướng dẫn từng bước
Đây là cách chạy một phiên T-Shirt Sizing gọn gàng, dù offline hay online (Miro, Mural, FigJam):
- Chuẩn bị "rổ" và item tham chiếu. Tạo năm vùng XS, S, M, L, XL. Quan trọng nhất: chọn trước một item mà cả đội đã quen và đồng thuận là cỡ M (item tham chiếu vàng). Mọi thứ khác sẽ so với nó.
- Thống nhất ý nghĩa từng cỡ. Dành 2–3 phút nhắc lại định nghĩa: XS trivial, S nhỏ, M trung bình, L lớn, XL cần tách. Nếu đội mới, viết các mốc thời gian tham khảo ra để mọi người hình dung, nhưng nhấn mạnh rằng bản chất là so sánh tương đối.
- Đọc nhanh từng item. PO trình bày ngắn gọn từng item (1 câu mục tiêu). Không sa đà vào chi tiết kỹ thuật ở bước này.
- Mỗi người chọn cỡ độc lập. Cho mỗi người tự quyết cỡ — viết note riêng, hoặc dùng tính năng ẩn (private mode) trong công cụ online. Đây là bước chống anchoring then chốt.
- Lật cùng lúc và soi chỗ lệch. Khi cỡ nhất trí, xếp item vào rổ và đi tiếp ngay. Khi có lệch (ví dụ người nói S, người nói L), dừng lại thảo luận — đây là lúc lộ ra rủi ro hoặc hiểu lầm. Sau thảo luận, chọn lại.
- Đánh dấu XL để tách nhỏ. Bất kỳ item nào rơi vào XL (hoặc L với nhiều bất định) được flag để đưa vào buổi splitting/refinement riêng. Đừng cố ép XL vào sprint.
- Chốt và ánh xạ (nếu cần). Nếu đội dùng velocity, map cỡ sang point theo bảng đã thống nhất. Ghi lại item tham chiếu để dùng cho lần sau.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến cỡ áo thành con số chính xác. Nhiều đội bắt đầu cãi nhau "cái này M lớn hay M nhỏ?", "có nên có cỡ M+ không?". Đây là dấu hiệu bạn đang đánh mất giá trị cốt lõi là tốc độ và sự đơn giản. Giữ đúng 5 cỡ. Nếu cần chi tiết hơn, hãy dùng kỹ thuật ước lượng chi tiết hơn cho riêng item đó, đừng làm phình thang cỡ áo.
Lỗi 2 — Để một người neo cả đội. Như ví dụ fintech, người nói đầu tiên/to nhất thường định khung suy nghĩ cho cả nhóm. Luôn cho chọn cỡ độc lập trước khi lộ kết quả.
Lỗi 3 — Không có item tham chiếu. Nếu không có "thước M" chung, mỗi người dùng một thang riêng và kết quả hỗn loạn. Luôn chốt một golden reference trước khi bắt đầu.
Lỗi 4 — Coi mốc thời gian là cam kết. "M = 1 tuần" chỉ là để hình dung, không phải lời hứa giao hàng. Nếu sếp nghe "M" rồi đếm chính xác 5 ngày làm việc, bạn đã để mốc tham khảo biến thành deadline. Truyền đạt rõ ràng đây là kích thước tương đối, không phải lịch.
Lỗi 5 — Cố ước lượng item quá mơ hồ. Nếu không ai hiểu item là gì, đừng ép size. Dùng dấu "?" và đưa nó đi làm rõ (spike) trước.
Mẹo — Calibrate lại định kỳ. Sau vài sprint, cảm nhận về cỡ có thể trôi. Thỉnh thoảng lấy vài item đã làm xong, hỏi "nếu làm lại bây giờ thì nó là cỡ gì?", để hiệu chỉnh thước đo chung.
Mẹo — XL luôn là lời mời tách nhỏ. Hãy tập phản xạ: thấy XL là nghĩ ngay đến refinement, không phải commit.
Mẹo — Dùng cho mức epic, đừng dùng cho mọi thứ. T-Shirt Sizing đẹp nhất ở mức thô (epic, roadmap, refinement nhanh). Đừng cố thay thế mọi kỹ thuật ước lượng bằng nó.
Bài tập thực hành
- Tự calibrate thang đo của bạn. Lấy 5 item từ backlog đội bạn đã hoàn thành gần đây. Không nhìn lại thời gian thực tế, hãy gán cỡ XS–XL cho từng cái dựa trên trí nhớ. Sau đó đối chiếu với thời gian thực tế đã mất. Cỡ của bạn có nhất quán không? Item nào bạn đánh giá sai cỡ nhiều nhất, và vì sao?
- Chạy thử một phiên 10 item. Chọn 10 item sắp tới trong backlog. Chốt một item tham chiếu là M. Cho đội (hoặc tự bạn đóng vai) phân loại độc lập rồi lật cùng lúc. Ghi lại những item có bất đồng và bài học từ cuộc thảo luận.
- Xây bảng quy đổi của riêng đội. Viết ra bảng map cỡ áo sang story point phù hợp với đội bạn (gợi ý: dùng Fibonacci). Thảo luận với đội: XL của các bạn nên là 13 hay 20? Vì sao? Quyết định này nói lên điều gì về mức độ bất định các bạn chấp nhận.
- Săn XL. Rà soát backlog hiện tại và đánh dấu mọi item bạn cho là cỡ XL. Với mỗi item, viết một câu: "Có thể tách thành những phần nhỏ nào?" Đây là khởi đầu cho kỹ năng story splitting.
Tóm tắt
T-Shirt Sizing là kỹ thuật ước lượng tương đối nhanh và trực quan, dùng các cỡ XS, S, M, L, XL để phân loại công việc theo kích thước thay vì gán con số tuyệt đối. Nó khai thác thế mạnh tự nhiên của con người — so sánh "to hơn / nhỏ hơn" — và cố tình tránh sự chính xác giả tạo.
Những điểm cốt lõi cần nhớ: XS là việc cỏn con (~1 ngày), S nhỏ (~2–3 ngày), M trung bình (~1 tuần, thường là item tham chiếu), L lớn (~2 tuần, nên cân nhắc tách), và XL là epic cần tách nhỏ chứ không bao giờ commit nguyên khối. Các mốc thời gian chỉ để hình dung, không phải cam kết.
Để chạy hiệu quả: luôn có một item tham chiếu vàng, cho mọi người chọn cỡ độc lập trước khi thảo luận, dùng sự bất đồng để lộ rủi ro ẩn, và flag mọi XL cho refinement. T-Shirt Sizing đặc biệt mạnh khi cần ước lượng nhanh số lượng lớn, làm việc ở mức epic/roadmap, hoặc giao tiếp với stakeholder không kỹ thuật. Hãy giữ nó đơn giản — đó chính là sức mạnh của nó.