Mở đầu — vì sao bài này quan trọng
Khi còn làm Sales hay BD, bạn ước lượng (estimate) mỗi ngày — nhưng bạn ước lượng tiền. Deal này trị giá bao nhiêu? Khả năng chốt là bao nhiêu phần trăm? Tháng này forecast được bao nhiêu doanh số? Bạn đã có một bộ óc ước lượng rất nhạy: bạn nhìn một cơ hội và "cảm" được nó nặng nhẹ ra sao, rủi ro ở đâu, khi nào tiền về.
Tin tốt là: trong vai trò BA, bạn vẫn phải ước lượng mỗi ngày. Tin cần lưu ý là: đơn vị đã đổi. Bạn không còn ước lượng tiền nữa — bạn ước lượng công sức (effort) và độ phức tạp (complexity). Bao lâu để viết xong bộ requirement này? User story này "to" cỡ nào? Việc làm rõ nghiệp vụ với phòng kế toán sẽ ngốn của bạn một buổi hay ba ngày?
Nhiều ex-Sales bước vào BA rồi vấp đúng chỗ này. Họ quen với việc "deal lớn thì giá trị lớn", nên khi gặp story point, họ cố quy đổi point ra giờ, ra tiền, ra deadline cứng — và sai bét. Estimation trong môi trường Agile/phần mềm có một logic khác hẳn forecast bán hàng. Nếu bạn hiểu sai logic đó, bạn sẽ hứa những thứ team không giao được, làm mất uy tín ngay trong sprint đầu tiên.
Bài này giúp bạn chuyển bộ kỹ năng ước lượng sẵn có sang đúng "đơn vị tiền tệ" của nghề BA, để bạn vừa đỡ bỡ ngỡ, vừa tận dụng được lợi thế trực giác về rủi ro mà dân Sales vốn rất mạnh.
Khái niệm cốt lõi
Ba thứ bạn đã ước lượng trong Sales
Hãy gọi tên rõ ràng những gì bạn vốn quen, vì chúng là cầu nối:
- Deal value — giá trị bằng tiền của một cơ hội. Đây là một con số tuyệt đối, đo bằng VNĐ.
- Probability of close — xác suất chốt, thường tính theo giai đoạn phễu (qualification 20%, proposal 50%, negotiation 80%...).
- Weighted forecast — doanh số kỳ vọng = deal value × probability, cộng dồn cả pipeline. Đây là cách bạn dự báo cho cả tháng/quý dù từng deal đơn lẻ chưa chắc chắn.
Ba thứ BA phải ước lượng
Trong vai trò BA, bạn ước lượng ba loại đối tượng:
- Effort viết requirement/spec — bao lâu để bạn (BA) hoàn thành phần việc của mình: phỏng vấn stakeholder, viết BRD/SRS, vẽ process, làm rõ acceptance criteria. Đo bằng giờ hoặc ngày làm việc.
- Size của user story — story này "to" cỡ nào khi dev và team nhìn vào. Đây là nơi story point xuất hiện.
- Độ phức tạp / rủi ro của một hạng mục nghiệp vụ — việc làm rõ nghiệp vụ này có nhiều ẩn số không, có phụ thuộc bên thứ ba không, có khả năng "đào ra thêm" yêu cầu giấu mặt không.
Story point thực sự là gì — và không phải là gì
Đây là khái niệm gây hiểu lầm nhiều nhất với ex-Sales. Story point KHÔNG phải là giờ. Nó là một đơn vị tương đối, đo tổng hợp ba thứ: khối lượng công việc (volume), độ phức tạp (complexity) và độ bất định/rủi ro (uncertainty).
Hãy hình dung bằng phép so sánh quen thuộc: nếu tôi hỏi bạn "quãng đường từ Hà Nội đi Hải Phòng so với đi Sài Gòn thì cái nào xa hơn và xa gấp mấy?", bạn trả lời được ngay là Sài Gòn xa hơn, khoảng gấp 15-16 lần, mà không cần biết chính xác xe chạy mất bao nhiêu giờ (vì còn tùy tắc đường, tốc độ, dừng nghỉ). Story point đo "khoảng cách tương đối" đó. Story 2 điểm nghĩa là nó nhỏ gấp đôi một story 4 điểm, chứ không nói nó mất 2 giờ.
Vì sao team dùng point thay vì giờ? Vì giờ là con số tuyệt đối phụ thuộc vào ai làm — dev senior làm 2 giờ, dev junior làm cả ngày. Point thì độc lập với người: cả team đồng thuận story này "to" cỡ này, rồi để velocity (số point team thực sự hoàn thành mỗi sprint) tự quy đổi ra thời gian thực tế. Đây chính là cơ chế "weighted forecast" của Agile: bạn không tin một story đơn lẻ mất đúng bao lâu, nhưng tin vào tổng point team giao được mỗi sprint.
Thang Fibonacci và Planning Poker
Phần lớn team dùng dãy Fibonacci đã điều chỉnh: 1, 2, 3, 5, 8, 13, 20, 40, 100. Khoảng cách giãn dần có chủ đích — vì story càng lớn thì bạn càng không thể ước lượng chính xác, nên không có ý nghĩa khi tranh cãi giữa 21 và 22; chỉ cần biết "nó cỡ 20". Story lên tới 13 trở lên thường là tín hiệu cần chẻ nhỏ (split) trước khi đưa vào sprint.
Planning Poker là kỹ thuật estimate tập thể: mỗi người chọn một lá bài point một cách độc lập, lật cùng lúc. Nếu lệch nhau (một người 3, một người 13), người cao nhất và thấp nhất giải thích góc nhìn — thường người estimate cao đã nhìn thấy một rủi ro mà người khác bỏ sót. Đây là điểm mà ex-Sales tỏa sáng: bạn có giác quan đánh hơi rủi ro rất tốt từ thời chốt deal.
Vai trò của BA trong estimation: bạn estimate gì, team estimate gì
Một ranh giới quan trọng cần nhớ ngay: point của story là do team phát triển (dev, QA) estimate, không phải BA tự gán. BA estimate effort của chính mình (việc viết spec, làm rõ yêu cầu), và BA hỗ trợ team estimate story bằng cách cung cấp đủ thông tin để giảm bất định. Một story mơ hồ luôn bị estimate cao vì team phải "đệm" rủi ro vào. BA giỏi làm rõ requirement đến mức team estimate được con số nhỏ và tự tin hơn — đó là giá trị trực tiếp của bạn lên số liệu sprint.
Tình huống thực tế
Ví dụ 1 — Phương quy đổi point ra tiền và vỡ trận
Phương từng là BD Manager tại một công ty agency, mới chuyển sang làm BA cho một startup logistics ở TP.HCM. Sprint đầu tiên, team commit 40 story point. Sếp dự án hỏi "40 point này là bao nhiêu tiền, bao giờ xong?". Theo phản xạ Sales cũ, Phương lấy 40 point chia cho 2 tuần sprint, ước mỗi point khoảng 4 giờ, rồi tự tin báo "hai tuần nữa xong toàn bộ, tương đương 320 giờ công".
Vấn đề nảy ra ở cuối sprint: team chỉ hoàn thành 26 point. Lý do là có một story tích hợp API với đối tác vận chuyển bên ngoài bị "đào ra" hàng loạt yêu cầu ẩn — xác thực, xử lý lỗi, đối soát đơn — mà ban đầu không ai thấy. Con số 4 giờ/point Phương tự bịa hoàn toàn không có cơ sở; velocity thật của team lúc đó chưa được đo lần nào.
Bài học: đừng quy đổi point ra giờ rồi ra cam kết cứng khi chưa có velocity lịch sử. Trong 2-3 sprint đầu, velocity là chưa biết — hãy nói thẳng với sếp rằng "team đang hiệu chỉnh năng lực, sau sprint 3 tôi sẽ có con số forecast đáng tin". Đây đúng là cách một Sales giỏi nói về một pipeline mới: chưa có dữ liệu lịch sử thì không vống forecast.
Ví dụ 2 — Tuấn dùng giác quan rủi ro của Sales đúng chỗ
Tuấn, cựu Sales bảo hiểm chuyển sang làm BA tại một công ty fintech ví điện tử ở Hà Nội. Trong buổi Planning Poker, có story "Cho phép người dùng đổi số điện thoại đăng nhập". Hai dev chọn 3 point, nghĩ chỉ là sửa một field. Tuấn — dù không phải người gán point — đã lật lá 8.
Anh giải thích bằng đúng phản xạ thời bán bảo hiểm: "Số điện thoại ở đây là định danh tài khoản và gắn với OTP, KYC, lịch sử giao dịch. Đổi số là đụng tới chống gian lận và quy định định danh khách hàng. Em từng thấy khách lợi dụng đổi SĐT để chiếm tài khoản." Cả team khựng lại, kéo thêm bạn security vào, và cuối cùng story được estimate lại thành 13 point, kèm việc chẻ thành 3 story con.
Bài học: lợi thế lớn nhất của ex-Sales trong estimation là đánh hơi rủi ro nghiệp vụ và gian lận — thứ dev thuần kỹ thuật hay bỏ sót. Bạn không gán point, nhưng tiếng nói của bạn trong Planning Poker giúp team estimate sát thực tế hơn. Một con số estimate "đắt" nhưng đúng còn hơn con số rẻ rồi vỡ giữa sprint.
Ví dụ 3 — Estimate effort viết spec của chính BA
Linh làm BA tại một công ty SaaS quản lý nhân sự. Đầu quý, PM hỏi Linh: "Module chấm công mới, em cần bao lâu để xong bộ requirement?". Theo thói quen forecast pipeline, Linh không trả lời một con số duy nhất mà chia nhỏ và gắn xác suất:
- Phỏng vấn 3 nhóm stakeholder (HR, quản lý, nhân viên): 2 ngày — chắc chắn.
- Viết process AS-IS và TO-BE: 2 ngày — chắc chắn.
- Làm rõ luật tính lương ngoài giờ và ca đêm: ước 2 ngày, nhưng phụ thuộc kế toán phản hồi, rủi ro cao có thể đội lên 4-5 ngày.
- Viết SRS + acceptance criteria: 3 ngày.
Bài học: estimate effort của chính BA nên được trình bày kiểu forecast có weighting — tách phần chắc chắn khỏi phần rủi ro, và luôn kèm đề xuất hành động để thu nhỏ vùng bất định. Đây là kỹ năng Sales chính hiệu, chỉ áp vào đối tượng mới.
Hướng dẫn từng bước
Đây là quy trình thực dụng để bạn estimate trong vai trò BA:
- Phân loại bạn đang estimate cái gì. Trước mỗi lần ước lượng, tự hỏi: đây là effort viết spec của tôi (đo bằng ngày), hay size của một story cho team (đo bằng point)? Hai thứ này dùng đơn vị và logic khác nhau, đừng trộn.
- Với effort viết spec: chẻ công việc và gắn rủi ro. Liệt kê các hạng mục (elicitation, modeling, viết SRS, review). Ước mỗi hạng mục theo ngày. Đánh dấu hạng mục nào phụ thuộc bên ngoài (stakeholder bận, đối tác chậm) — đó là vùng rủi ro. Báo con số dưới dạng "khoảng" (ví dụ 7-10 ngày), không phải một số đơn cứng nhắc.
- Với story point: chuẩn bị thông tin để giảm bất định trước buổi estimate. Đây là việc của BA. Mỗi story đưa vào Planning Poker nên đã có mô tả rõ, acceptance criteria, và những phụ thuộc đã biết. Story càng rõ, team estimate càng nhỏ và càng tự tin.
- Chọn một story tham chiếu (reference story). Cả team thống nhất một story vừa-nhỏ làm mốc "2 điểm" hoặc "3 điểm". Sau này mọi story khác estimate bằng cách so với mốc này, không estimate "từ con số 0". Đây giống cách Sales định cỡ deal: "deal này so với deal X tháng trước thì to hơn hay nhỏ hơn?".
- Trong Planning Poker, lắng nghe người estimate lệch. Khi có người chọn cao hơn hẳn, đừng ép họ hạ xuống cho nhanh. Hỏi họ nhìn thấy rủi ro gì. Với vai BA, bạn vừa là người gỡ rủi ro nghiệp vụ, vừa là người ghi nhận những giả định ẩn (hidden assumption) lộ ra trong lúc tranh luận.
- Chẻ nhỏ story quá lớn. Story từ 13 point trở lên thì hầu như chắc chắn còn yêu cầu ẩn chưa làm rõ. BA dẫn dắt việc split: tách theo luồng nghiệp vụ, theo loại người dùng, hoặc theo happy-path trước / edge-case sau.
- Đo velocity thật sau mỗi sprint và dùng nó để forecast. Sau 2-3 sprint, bạn có velocity trung bình (ví dụ 28 point/sprint). Lúc này — và chỉ lúc này — bạn mới forecast được: backlog còn 140 point thì cần khoảng 5 sprint. Đây chính là weighted forecast của bạn, nhưng đo bằng point thay vì tiền.
Lỗi thường gặp & mẹo
Lỗi: quy đổi point ra giờ rồi cam kết cứng. Đây là lỗi kinh điển của ex-Sales. Point là tương đối; thời gian thực do velocity quyết định. Đừng bao giờ nói "1 point = 4 giờ" với stakeholder.
Lỗi: BA tự gán point cho story. Người làm story (dev, QA) mới là người estimate point, vì họ là người gánh độ phức tạp kỹ thuật. BA cung cấp thông tin và đặt câu hỏi, không áp số.
Lỗi: estimate cao để "thủ" rồi luôn xong sớm. Padding quá tay phá vỡ độ tin cậy của velocity và làm planning sai. Estimate trung thực, để bộ đệm nằm ở cấp sprint (không commit 100% capacity) chứ không nhồi vào từng story.
Lỗi: trộn effort của BA vào point của story. Việc bạn viết spec là một dòng công việc riêng, đừng nhét vào point của story phát triển. Nếu cần, tạo task riêng cho hoạt động phân tích.
Mẹo — dùng story tham chiếu cố định: giữ một "thư viện" vài story đã hoàn thành làm mốc cho các cỡ 2, 5, 8. Estimate bằng so sánh luôn nhanh và nhất quán hơn estimate từ đầu.
Mẹo — phát biểu rủi ro thành lời: mỗi khi estimate, nói ra giả định và rủi ro. "Con số này đúng nếu đối tác trả API đúng tài liệu." Câu "nếu" đó là vàng — nó biến estimate thành cảnh báo sớm, đúng nghề cũ của bạn.
Mẹo — tách "chắc chắn" và "bất định": khi báo cho sếp business, luôn cho một khoảng (range) thay vì một số. Range thể hiện sự trung thực và giúp họ ra quyết định tốt hơn, giống như bạn từng báo "best case / worst case" cho một deal.
Bài tập thực hành
- Quy đổi tư duy: Viết ra một bảng 3 cột — "Tôi từng estimate gì trong Sales" / "Đơn vị" / "Tương ứng trong BA là gì". Điền tối thiểu 3 dòng (deal value, probability, forecast). Mục tiêu là bạn tự thấy rõ cây cầu tư duy.
- Estimate effort spec: Giả định bạn được giao viết requirement cho tính năng "khách hàng tự hủy đơn hàng đã đặt". Chẻ công việc thành các hạng mục, ước mỗi hạng mục theo ngày, đánh dấu vùng rủi ro phụ thuộc bên ngoài, rồi viết một câu báo cáo cho PM theo dạng range + đề xuất gỡ rủi ro.
- Mô phỏng Planning Poker: Lấy 4 story sau và tự gán point theo Fibonacci, kèm một câu lý do cho mỗi cái — (a) đổi avatar người dùng; (b) tích hợp cổng thanh toán VNPay; (c) đổi màu nút "Mua"; (d) tính phí trả góp theo kỳ hạn. Sau đó tự hỏi: story nào nên chẻ nhỏ và vì sao?
- Tính forecast bằng velocity: Team có velocity 3 sprint gần nhất là 24, 30, 27 point. Backlog còn 160 point. Hãy ước số sprint cần thiết và viết một câu forecast trung thực kèm khoảng dao động (thay vì một con số cứng).
Tóm tắt
Estimation trong BA không phải kỹ năng mới với bạn — nó là kỹ năng cũ đổi đơn vị tiền tệ. Bạn từng ước lượng tiền (deal value), xác suất (probability) và dự báo tổng hợp (weighted forecast); giờ bạn ước lượng công sức (effort viết spec, đo bằng ngày), độ phức tạp tương đối (story point) và forecast tiến độ qua velocity.
Hãy nhớ ba điều cốt lõi. Một, story point là tương đối, không phải giờ — đừng quy đổi cứng ra tiền hay deadline khi chưa có velocity. Hai, BA estimate effort của mình, team estimate point của story — vai trò của bạn là làm rõ requirement để team estimate nhỏ và tự tin hơn. Ba, giác quan rủi ro từ thời Sales là lợi thế thật — tiếng nói của bạn trong Planning Poker giúp team không bỏ sót những yêu cầu ẩn và rủi ro nghiệp vụ tốn kém. Estimate trung thực, nói rõ giả định và rủi ro, báo cáo bằng khoảng thay vì số cứng — đó là cách bạn vừa giữ uy tín, vừa tỏa sáng đúng thế mạnh nền tảng của mình.