Mở đầu — vì sao bài này quan trọng
Có một hiểu lầm phổ biến ở các bạn mới vào nghề BA: "Estimation (ước lượng) là việc của developer và project manager, mình chỉ cần viết requirement là xong." Sai lầm này khiến rất nhiều BA junior đứng ngoài những cuộc họp quan trọng nhất của một dự án, và tệ hơn, không hiểu vì sao đội của mình cứ liên tục trễ deadline.
Thực tế, BA là người ngồi giữa hai thế giới: một bên là stakeholder (bên liên quan) muốn biết "khi nào xong, tốn bao nhiêu", một bên là đội phát triển đang cố gắng làm ra sản phẩm. Khi sếp hỏi "Tính năng thanh toán qua ví MoMo bao giờ ra mắt được?", người đầu tiên bị nhìn thường là BA. Nếu bạn không hiểu cách đội ước lượng công việc, bạn sẽ hoặc là hứa bừa (rồi vỡ trận), hoặc là ú ớ không trả lời được (mất uy tín).
Trong bài này, chúng ta sẽ học hai kỹ thuật ước lượng phổ biến và dễ tiếp cận nhất cho người mới: Story Point và T-shirt Sizing. Đây không phải là kỹ năng để bạn tự ngồi đoán con số. Đây là kỹ năng để bạn tham gia vào cuộc trò chuyện ước lượng cùng cả đội, hiểu ngôn ngữ họ dùng, và biến những con số đó thành thông tin có ích cho stakeholder. Nắm được nó, bạn sẽ tự tin hơn hẳn trong ba tình huống: lập kế hoạch sprint, dự báo ngày giao hàng cho roadmap, và trả lời câu hỏi "bao giờ xong" một cách có căn cứ.
Khái niệm cốt lõi
Estimation là ước lượng, không phải cam kết chính xác
Điều đầu tiên và quan trọng nhất bạn cần khắc cốt ghi tâm: estimate là một phỏng đoán có cơ sở, không phải một lời hứa đóng dấu. Khi đội nói "tính năng này tốn 8 point", họ không nói "tôi cam kết đúng 8 point không sai một ly". Họ đang nói "dựa trên hiểu biết hiện tại, độ khó của việc này tương đương với những việc chúng tôi từng làm mà chấm 8 point".
Sự khác biệt này cực kỳ quan trọng khi bạn giao tiếp với stakeholder. Estimate luôn đi kèm với sự không chắc chắn, và nhiệm vụ của BA là truyền tải cả con số lẫn mức độ tin cậy của con số đó.
Tại sao không ước lượng bằng giờ (hours)?
Bạn có thể thắc mắc: sao không nói thẳng "việc này mất 16 giờ" cho dễ hiểu? Vấn đề là ước lượng bằng giờ có ba nhược điểm chết người:
- Mỗi người làm nhanh chậm khác nhau. Một task bạn Nam senior làm 4 giờ thì bạn Linh fresher có thể mất 12 giờ. Vậy con số nào là "đúng"?
- Con người rất tệ trong việc đoán thời gian tuyệt đối nhưng lại khá giỏi so sánh tương đối. Bạn khó nói chính xác quãng đường từ nhà đến công ty là bao nhiêu mét, nhưng bạn dễ dàng nói "đường đến công ty xa gấp đôi đường đến chợ".
- Con số giờ tạo áp lực cam kết. Khi bạn nói "16 giờ", sếp nghe thành "2 ngày là xong", rồi trách móc khi trễ.
Story Point là gì?
Story Point (điểm truyện) là một đơn vị trừu tượng thể hiện tổng hợp ba yếu tố của một hạng mục công việc (thường là user story):
- Khối lượng công việc (effort) — làm nhiều hay ít.
- Độ phức tạp (complexity) — logic rắc rối, nhiều nhánh xử lý.
- Sự không chắc chắn / rủi ro (uncertainty) — có điều gì chưa rõ, phụ thuộc bên thứ ba, công nghệ mới chưa từng dùng.
Velocity và cách dùng point để dự báo
Point chỉ thực sự hữu ích khi gắn với velocity (vận tốc) — tổng số point mà đội hoàn thành được trong một sprint. Ví dụ, sau vài sprint bạn quan sát thấy đội của mình đều đặn hoàn thành khoảng 30 point mỗi sprint (2 tuần). Bây giờ nếu backlog còn 120 point, bạn có thể dự báo: cần khoảng 4 sprint, tức 8 tuần nữa. Đây chính là cách point biến thành forecast ngày giao hàng — thứ mà stakeholder thực sự quan tâm.
T-shirt Sizing là gì?
T-shirt Sizing dùng cỡ áo — XS, S, M, L, XL — thay cho con số. Đây là kỹ thuật ước lượng thô, nhanh, phù hợp cho giai đoạn sớm khi requirement còn mơ hồ, hoặc để phân loại nhanh một danh sách dài các tính năng ở tầm roadmap. Vì không có con số, nó tránh được cái bẫy "so đo từng point", giúp cả đội quyết định nhanh. Sau này khi tính năng được đưa vào sprint và làm rõ hơn, đội mới chuyển sang chấm story point chi tiết.
Tình huống thực tế
Tình huống 1: Sprint planning tại một fintech ở TP.HCM
Mai là BA fresher tại một công ty fintech (giả định tên Tikop) làm ứng dụng đầu tư tích lũy. Trong buổi sprint planning, đội bàn về story "Cho phép người dùng liên kết tài khoản ngân hàng qua OTP". Ban đầu Mai nghĩ đây là việc nhỏ, chắc 3 point. Nhưng một developer lên tiếng: "Việc này phải tích hợp API của ba ngân hàng khác nhau, mỗi ngân hàng có định dạng OTP riêng, lại còn phải xử lý trường hợp OTP hết hạn. Mình nghĩ là 13." Một bạn khác nói: "Ừ, mà bên VPBank sandbox hay lỗi lắm, rủi ro cao, mình đồng ý 13."
Diễn giải: Con số nhảy từ 3 lên 13 không phải vì "code nhiều hơn", mà vì độ phức tạp (ba định dạng) và rủi ro (sandbox không ổn định). Mai học được rằng một story trông đơn giản trên giấy tờ có thể "nặng" hơn nhiều khi nhìn từ góc kỹ thuật.
Bài học: BA đừng bao giờ tự chấm point một mình rồi ép đội theo. Point là kết quả của cuộc đối thoại, và chính cuộc đối thoại đó giúp BA phát hiện những rủi ro ẩn mà lúc viết requirement mình chưa thấy — ở đây là sự bất ổn của sandbox ngân hàng.
Tình huống 2: Roadmap quý cho một sàn thương mại điện tử
Hùng là BA tại một sàn TMĐT tầm trung ở Hà Nội. Giám đốc sản phẩm cần lên roadmap cho quý tới với 8 tính năng lớn: chatbot hỗ trợ, tích hợp giao hàng nhanh, chương trình khách hàng thân thiết, bộ lọc tìm kiếm nâng cao... Ở giai đoạn này, requirement mới chỉ là vài dòng mô tả, chưa có user story chi tiết. Nếu bắt đội chấm story point ngay thì vô nghĩa vì thiếu thông tin.
Hùng tổ chức một buổi T-shirt sizing 60 phút. Cả đội nhanh chóng gán: chatbot = XL (công nghệ mới, chưa ai từng làm), tích hợp giao hàng = L, khách hàng thân thiết = M, bộ lọc nâng cao = S. Chỉ trong một buổi, họ có bức tranh tổng thể về độ nặng của từng tính năng.
Diễn giải: Nhờ đó, giám đốc sản phẩm quyết định đẩy hai tính năng cỡ S và M lên làm trước để có "quick win", còn cái XL thì tách ra làm một đợt nghiên cứu (spike) riêng trước khi cam kết.
Bài học: Đúng công cụ cho đúng giai đoạn. T-shirt sizing dùng cho tầm roadmap khi thông tin còn ít; story point dùng cho tầm sprint khi đã làm rõ chi tiết. Ép dùng story point quá sớm chỉ tạo ra những con số giả tạo, gây hiểu lầm.
Tình huống 3: Khi con số bị hiểu sai thành cam kết cứng
Tại một công ty outsource ở Đà Nẵng, BA junior tên Trang nghe đội ước lượng module quản lý kho là 40 point, velocity đội khoảng 20 point/sprint. Trang nhanh nhảu nói với khách hàng: "Chắc chắn 2 sprint, tức 4 tuần là xong ạ." Đến sprint thứ hai, phát sinh yêu cầu mới về báo cáo tồn kho theo lô, cộng thêm một developer nghỉ ốm một tuần. Kết quả trễ một sprint. Khách hàng nổi giận vì "đã hứa 4 tuần".
Diễn giải: Lỗi không nằm ở con số 40 point — con số đó hợp lý. Lỗi nằm ở chỗ Trang biến một ước lượng thành lời cam kết tuyệt đối, bỏ qua yếu tố không chắc chắn và rủi ro nhân sự.
Bài học: BA giỏi luôn truyền đạt estimate kèm khoảng tin cậy: "Dựa trên velocity hiện tại, dự kiến khoảng 4–5 tuần, với giả định phạm vi không đổi và đội đủ người." Cách nói này vừa cho stakeholder con số họ cần, vừa bảo vệ đội khỏi bị quy trách nhiệm oan.
Hướng dẫn từng bước
Đây là quy trình một buổi ước lượng story point điển hình mà bạn, với vai trò BA, sẽ tham gia và thường là người chuẩn bị:
Bước 1 — Chuẩn bị story rõ ràng. Trước buổi họp, đảm bảo mỗi story có mô tả và acceptance criteria (tiêu chí chấp nhận) đủ rõ. Đây là phần việc cốt lõi của BA. Story mơ hồ thì ước lượng sẽ loạn.
Bước 2 — Chọn một story tham chiếu (baseline). Cả đội cùng chọn một story quen thuộc, độ khó vừa phải, gán cho nó một mốc, ví dụ 3 point. Về sau mọi story khác đều so với mốc này: "việc này khó gấp đôi baseline thì chấm 5–8".
Bước 3 — Đọc và làm rõ story. BA đọc story, đội đặt câu hỏi. Đây là lúc bạn giải đáp thắc mắc về nghiệp vụ. Nếu có quá nhiều điều chưa rõ, có thể story chưa sẵn sàng để ước lượng.
Bước 4 — Ước lượng đồng thời (Planning Poker). Mỗi người chọn một con số Fibonacci một cách kín đáo (qua thẻ bài hoặc app như Planning Poker, Jira), rồi cùng lật ra một lúc. Việc lật đồng thời tránh chuyện người sau bị ảnh hưởng bởi người trước.
Bước 5 — Thảo luận điểm chênh lệch. Nếu người chấm 3, người chấm 13, đó là tín hiệu vàng. Hai người này đang hiểu story khác nhau. Cho họ giải thích. Thường thì người chấm cao đã thấy một rủi ro mà người chấm thấp bỏ sót. BA nên lắng nghe kỹ vì đây chính là lúc lộ ra requirement gap.
Bước 6 — Chốt con số đồng thuận. Sau thảo luận, đội chấm lại và hội tụ về một con số. Không cần tuyệt đối nhất trí, chỉ cần đủ đồng thuận.
Bước 7 — Ghi lại và tính velocity. Cuối sprint, cộng point các story đã hoàn thành để có velocity. Sau 3–4 sprint, bạn có velocity trung bình đủ ổn định để dự báo roadmap.
Lỗi thường gặp & mẹo
Lỗi 1: Quy đổi cứng point ra giờ. Nhiều bạn cố lập bảng "1 point = 4 giờ". Điều này phá hỏng toàn bộ ý nghĩa của point và kéo đội quay lại cái bẫy ước lượng thời gian tuyệt đối. Point là tương đối, hãy để nó tương đối.
Lỗi 2: BA tự chấm point thay đội. Point phải do người trực tiếp làm việc chấm (developer, tester). BA facilitate (điều phối) và làm rõ nghiệp vụ, không áp đặt con số.
Lỗi 3: So sánh velocity giữa các đội. Point của đội A không tương đương point của đội B, vì baseline mỗi đội khác nhau. Đừng bao giờ nói "đội kia làm 50 point còn đội mình chỉ 30, đội mình yếu". Đây là so sánh vô nghĩa và gây độc hại.
Lỗi 4: Coi estimate là cam kết bất di bất dịch. Như tình huống 3 đã chỉ ra, luôn kèm khoảng và giả định khi báo cáo.
Mẹo hay:
- Với story chấm 13 point trở lên, hãy đề xuất tách nhỏ (split) story ra. Việc quá to là dấu hiệu bạn chưa hiểu rõ nó, và nó khó lọt gọn vào một sprint.
- Dùng T-shirt sizing để "sàng lọc thô" backlog lớn trước, sau đó mới chấm point chi tiết cho những gì sắp làm.
- Khi stakeholder ép "cho con số chắc chắn", hãy đưa dạng khoảng: "khoảng 4 đến 6 tuần" thay vì một mốc cứng. Trung thực về sự không chắc chắn giúp bạn giữ uy tín lâu dài.
Bài tập thực hành
Bài 1 — Chấm point tương đối. Cho một story baseline: "Người dùng đăng nhập bằng email và mật khẩu" = 3 point. Hãy tự ước lượng point cho ba story sau và viết một câu lý giải cho mỗi con số: (a) "Người dùng đăng nhập bằng Google"; (b) "Người dùng đăng nhập bằng vân tay trên app di động"; (c) "Người dùng đặt lại mật khẩu qua email". Gợi ý: xét cả effort, độ phức tạp và rủi ro.
Bài 2 — T-shirt sizing một roadmap. Giả sử bạn là BA cho một app đặt đồ ăn. Hãy gán cỡ áo (XS–XL) cho 5 tính năng và giải thích ngắn: theo dõi tài xế theo thời gian thực, đánh giá món ăn, lưu địa chỉ giao hàng, chatbot AI gợi ý món, chia hóa đơn nhóm.
Bài 3 — Dự báo bằng velocity. Backlog của bạn còn 96 point. Velocity ba sprint gần nhất lần lượt là 22, 26, 24 point (mỗi sprint 2 tuần). Hãy tính velocity trung bình, dự báo số sprint và số tuần cần để hoàn thành, rồi viết một câu báo cáo cho sếp có kèm khoảng tin cậy.
Bài 4 — Xử lý tình huống. Sếp hỏi bạn: "Đội ước lượng 60 point, velocity 20, vậy đúng 6 tuần là xong nhé?" Hãy viết một câu trả lời vừa đưa được con số, vừa nêu rõ giả định và rủi ro để không biến estimate thành cam kết cứng.
Tóm tắt
Estimation không phải việc riêng của developer — nó là công cụ giao tiếp cốt lõi mà BA cần thành thạo để tham gia sprint planning, xây roadmap và trả lời stakeholder một cách có căn cứ. Hai kỹ thuật nền tảng bạn vừa học: Story Point đo độ lớn tương đối của công việc dựa trên effort, độ phức tạp và rủi ro, dùng dãy Fibonacci và gắn với velocity để dự báo ngày giao hàng; T-shirt Sizing là cách phân loại nhanh cho giai đoạn sớm khi thông tin còn mơ hồ. Nguyên tắc vàng: estimate là phỏng đoán có cơ sở chứ không phải cam kết cứng, point là tương đối chứ đừng quy ra giờ, và người làm việc mới là người chấm point — BA điều phối và làm rõ nghiệp vụ. Khi báo cáo cho stakeholder, luôn kèm khoảng tin cậy và các giả định. Nắm vững điều này, bạn sẽ chuyển từ một BA đứng ngoài cuộc sang một BA thực sự làm chủ được câu hỏi khó nhất mọi dự án: "Bao giờ thì xong?"