Mở đầu — vì sao bài này quan trọng
Khi bạn còn là Designer, câu hỏi "cái này mất bao lâu?" thường có một câu trả lời khá tự nhiên: "Ba ngày cho wireframe, hai ngày cho high-fidelity, thêm một buffer để chỉnh sửa." Bạn ước lượng công việc của chính mình, dựa trên kinh nghiệm tay nghề. Nhưng khi bước sang vai trò BA (Business Analyst), estimation trở thành một câu chuyện hoàn toàn khác — và nếu bạn không hiểu nó, bạn sẽ nhanh chóng bị đánh giá là "người không nắm được nhịp của team".
Vì sao? Vì với tư cách BA, bạn không chỉ ước lượng công việc của mình. Bạn ngồi trong buổi refinement, nghe dev cãi nhau xem một story là "3 điểm" hay "8 điểm", và bạn phải hiểu họ đang nói gì. Bạn phải trả lời stakeholder khi họ hỏi "feature này bao giờ xong?" mà không dám hứa liều. Và quan trọng nhất, bạn phải biết khi nào một con số estimate là bất thường để đặt câu hỏi ngược lại — vì chính bạn là người hiểu requirement rõ nhất trong phòng.
Đây là một trong những khoảng trống kỹ năng lớn nhất khi Designer chuyển sang BA. Design gần như luôn ước lượng theo thời gian (ngày, giờ). Còn thế giới phần mềm hiện đại — đặc biệt các team Agile tại Việt Nam như ở FPT Software, MoMo, hay Techcombank — đã chuyển sang tư duy story point, một đơn vị trừu tượng khiến nhiều người mới thấy khó hiểu. Bài này sẽ giúp bạn vượt qua rào cản đó: từ "ngày" sang "story point", và hiểu vai trò thật sự của BA trong bàn estimation.
Khái niệm cốt lõi
Estimation là dự đoán, không phải cam kết
Trước tiên phải làm rõ một hiểu lầm chết người: estimate không phải là lời hứa. Estimate là một dự đoán tốt nhất dựa trên thông tin hiện có, luôn kèm theo độ bất định. Khi bạn nói "story này khoảng 5 điểm", bạn không ký hợp đồng máu rằng nó sẽ xong đúng như vậy. Bạn đang nói: "Dựa trên hiểu biết hiện tại, độ phức tạp của nó tương đương những việc chúng ta từng làm và gọi là 5 điểm."
Sự phân biệt này cực kỳ quan trọng với BA, vì bạn thường là cầu nối truyền đạt estimate lên stakeholder. Nếu bạn hiểu nhầm estimate là cam kết, bạn sẽ vô tình biến một dự đoán thành một deadline cứng, và khi team trễ, bạn là người mất uy tín.
Vì sao lại là story point, không phải ngày?
Ước lượng theo ngày nghe có vẻ trực quan hơn, nhưng nó có ba vấn đề lớn.
Thứ nhất, năng suất mỗi người khác nhau. Một task mà dev senior làm trong nửa ngày thì junior có thể mất hai ngày. Nếu estimate bằng ngày, con số phụ thuộc vào việc ai làm — và bạn không thể lập kế hoạch ổn định.
Thứ hai, con người dở tệ trong việc ước lượng thời gian tuyệt đối, nhưng lại khá giỏi trong việc so sánh tương đối. Bạn khó nói chính xác "task này mất 6.5 giờ", nhưng bạn dễ dàng nói "task này rõ ràng khó gấp đôi task kia". Story point khai thác đúng điểm mạnh này: nó đo độ phức tạp tương đối, không đo thời gian.
Thứ ba, ước lượng theo giờ tạo áp lực tâm lý và dễ bị "làm tròn để an toàn". Còn story point tách rời khỏi đồng hồ, giúp team tập trung vào bản chất công việc.
Story point thường gộp ba yếu tố: độ phức tạp (logic rắc rối tới đâu), khối lượng (bao nhiêu việc phải làm), và độ bất định/rủi ro (còn bao nhiêu điều chưa biết). Một story đơn giản nhưng cực nhiều edge case chưa rõ vẫn có thể được điểm cao vì rủi ro lớn.
Thang Fibonacci và vì sao nó tồn tại
Đa số team dùng dãy Fibonacci sửa đổi: 1, 2, 3, 5, 8, 13, 20, 40, 100. Khoảng cách giữa các số ngày càng lớn phản ánh một sự thật: việc càng lớn thì càng khó ước lượng chính xác. Bạn có thể phân biệt rạch ròi giữa "2 điểm" và "3 điểm", nhưng phân biệt "20 điểm" với "21 điểm" là vô nghĩa — cả hai đều "quá lớn, cần chẻ nhỏ". Fibonacci ép team ngừng tranh cãi những khác biệt vô nghĩa.
Velocity — chiếc cầu nối story point về lại thời gian
Đây là mảnh ghép mà nhiều Designer mới chuyển sang BA bỏ lỡ. Story point trừu tượng, nhưng nó vẫn quy về được lịch trình nhờ velocity — số điểm trung bình mà team hoàn thành trong một sprint. Nếu team của bạn đều đặn làm được 30 điểm mỗi sprint 2 tuần, và backlog còn 120 điểm, thì cần khoảng 4 sprint, tức 8 tuần. Velocity là công cụ để bạn — với vai trò BA — trả lời câu hỏi "bao giờ xong" một cách có cơ sở thay vì đoán mò.
Ba cấp độ estimation mà BA tham gia
Nói cho đủ ngữ cảnh, estimation xảy ra ở nhiều tầng: estimate thô ở mức epic/release (thường bằng T-shirt sizing: S, M, L, XL) để lập kế hoạch dài hạn; estimate ở mức story trong buổi refinement (thường bằng story point qua Planning Poker); và estimate công việc của chính BA (viết BRD, tổ chức workshop, làm UAT). BA đụng tới cả ba.
Tình huống thực tế
Ví dụ 1 — Buổi refinement tại một fintech ở TP.HCM
Linh, một UX Designer vừa chuyển sang BA tại một công ty ví điện tử ở Quận 1, tham dự buổi refinement đầu tiên. Team dùng Planning Poker. Có một story: "Người dùng có thể liên kết tài khoản ngân hàng để nạp tiền". Ba dev bốc bài: hai người ra 5, một người ra 13.
Theo bản năng Designer cũ, Linh thấy khó hiểu — "giao diện chỉ có một form đơn giản mà, sao lại 13?". Nhưng đây chính là khoảnh khắc BA phải lắng nghe. Dev ra 13 giải thích: mỗi ngân hàng có API xác thực khác nhau, phải xử lý OTP, phải chờ callback từ phía ngân hàng, và có edge case khi liên kết thất bại giữa chừng. Hai dev ra 5 chỉ nghĩ tới happy path.
Linh nhận ra requirement của mình chưa nói rõ phạm vi: hỗ trợ mấy ngân hàng? Có xử lý retry khi OTP hết hạn không? Cô đặt câu hỏi, làm rõ, và team thống nhất tách story thành hai phần nhỏ hơn.
Bài học: Sự chênh lệch estimate lớn không phải vấn đề — nó là tín hiệu vàng cho BA. Nó lộ ra requirement mơ hồ hoặc hiểu biết khác nhau về phạm vi. Vai trò của BA không phải chốt con số, mà là dùng chênh lệch đó để đào sâu và làm rõ requirement.
Ví dụ 2 — Sếp hỏi "khi nào xong" tại một agency Hà Nội
Tại một agency phần mềm ở Hà Nội, Product Owner hỏi BA tên Đức: "Module quản lý kho cho khách bên bán lẻ, bao giờ giao được?". Đức mở backlog: module còn 96 điểm chưa làm. Team có velocity ổn định 24 điểm/sprint trong 5 sprint gần nhất, sprint dài 2 tuần.
Thay vì buột miệng "khoảng một tháng rưỡi", Đức tính: 96 / 24 = 4 sprint = 8 tuần. Nhưng anh không dừng ở một con số. Anh nói với PO: "Nếu velocity giữ ổn định, khoảng 8 tuần. Nhưng có 2 story đang là 20 điểm — dấu hiệu còn nhiều điều chưa rõ. Nếu khi làm rõ mà chúng phình ra, có thể thành 9–10 tuần. Em đề xuất mình cam kết ngày cho 6 tuần đầu, còn phần cuối để dạng khoảng."
Bài học: BA giỏi không đưa một con số duy nhất mà đưa một khoảng kèm giả định. Cách nói này vừa cho stakeholder cơ sở ra quyết định, vừa bảo vệ team khỏi cái bẫy "biến estimate thành deadline cứng". Việc dùng velocity để quy đổi cũng cho thấy BA hiểu bức tranh lịch trình, không chỉ hiểu requirement.
Ví dụ 3 — Ước lượng công việc của chính BA tại một startup EdTech
Ở một startup giáo dục tại Đà Nẵng, BA tên Trang được giao chuẩn bị requirement cho tính năng lớp học trực tuyến. PM hỏi cô cần bao lâu. Trước đây là Designer, Trang hay ước lượng kiểu "chắc tuần này xong". Lần này cô liệt kê cụ thể: tổ chức 2 workshop với giáo viên (mỗi buổi chuẩn bị + chạy + tổng hợp mất 1 ngày), phỏng vấn 3 stakeholder, viết BRD, vẽ 4 process flow, và làm rõ business rule về điểm danh.
Cô ước lượng khoảng 7 ngày làm việc, nhưng cộng thêm buffer vì phải chờ lịch giáo viên — vốn hay bị dời. Cô báo PM: "Phần việc của em khoảng 7 ngày công, nhưng do phụ thuộc lịch giáo viên, thời gian thực tế có thể kéo tới 2 tuần." Đúng như dự đoán, một workshop bị dời 4 ngày, nhưng vì đã báo trước, không ai bất ngờ.
Bài học: BA cũng phải estimate công việc của chính mình, và công việc BA đặc biệt nhiều phụ thuộc (stakeholder, lịch họp, thời gian chờ phản hồi). Tách rõ "effort" (số ngày công thực làm) khỏi "duration" (thời gian thực tế trôi qua, gồm cả chờ đợi) là kỹ năng sống còn.
Hướng dẫn từng bước
Dưới đây là quy trình để bạn tham gia và hỗ trợ estimation hiệu quả với vai trò BA.
Bước 1 — Chuẩn bị story sẵn sàng để estimate. Trước buổi refinement, đảm bảo mỗi story đủ rõ để ước lượng: có mô tả, có acceptance criteria sơ bộ, có nêu các phụ thuộc đã biết. Đây là phần việc BA đóng góp lớn nhất. Story mơ hồ dẫn đến estimate rác.
Bước 2 — Chọn một story tham chiếu (reference story). Team nên thống nhất một story vừa phải, đã hoàn thành, làm mốc — ví dụ "story này chúng ta gọi là 3 điểm". Mọi ước lượng sau đó đều so với mốc này. So sánh tương đối luôn dễ và ổn định hơn ước lượng tuyệt đối.
Bước 3 — Chạy Planning Poker. Mỗi người chọn con số một cách độc lập rồi lật bài cùng lúc, để tránh hiệu ứng "neo" theo người nói đầu tiên. BA thường không bốc điểm (vì không phải người code), nhưng lắng nghe và ghi chú.
Bước 4 — Đào sâu vào chênh lệch. Khi có khác biệt lớn, để người điểm cao nhất và thấp nhất giải thích. Đây là lúc BA vào cuộc: ghi lại mọi câu hỏi requirement lộ ra, làm rõ ngay nếu được.
Bước 5 — Bốc lại và chốt. Sau thảo luận, bốc lần hai. Thường lần này sẽ hội tụ. Không cần đồng thuận tuyệt đối — chỉ cần đủ gần để chốt một con số.
Bước 6 — Chẻ nhỏ story quá lớn. Nếu một story ra 13, 20 điểm trở lên, đó là dấu hiệu cần tách. BA hỗ trợ chẻ theo luồng nghiệp vụ, theo happy path và edge case, hoặc theo từng loại người dùng.
Bước 7 — Với công việc của chính bạn: liệt kê, ước lượng effort, rồi cộng buffer cho phụ thuộc. Đừng gộp tất cả thành một con số cảm tính. Chia nhỏ, ước lượng từng phần, và luôn tách effort khỏi duration.
Lỗi thường gặp & mẹo
Lỗi 1 — Quy đổi cứng nhắc "1 điểm = X giờ". Rất nhiều người mới cố ép story point về giờ để cho dễ hiểu. Làm vậy là giết chết toàn bộ giá trị của story point và biến nó thành ước lượng thời gian trá hình. Mẹo: hãy để story point ở dạng trừu tượng, chỉ quy về thời gian ở cấp độ velocity của cả team, không ở cấp từng điểm.
Lỗi 2 — BA tự ý áp đặt con số. Vì hiểu requirement rõ nhất, BA đôi khi bị cám dỗ "chắc cái này 3 điểm thôi". Nhưng người làm mới là người ước lượng độ khó. Mẹo: BA hỏi và làm rõ, để dev quyết con số.
Lỗi 3 — Coi estimate là cam kết. Đừng bao giờ nói với stakeholder "team hứa xong trong 5 điểm". Mẹo: luôn dùng ngôn ngữ khoảng và giả định — "dựa trên velocity hiện tại, dự kiến khoảng...".
Lỗi 4 — Bỏ qua rủi ro và điều chưa biết. Estimate chỉ tính happy path là estimate lạc quan giả tạo. Mẹo: BA chủ động hỏi "điều gì có thể làm việc này khó hơn dự kiến?" để lộ rủi ro ẩn.
Lỗi 5 — Lẫn lộn effort và duration khi estimate việc của mình. Nói "3 ngày" rồi thực tế mất 2 tuần vì chờ stakeholder khiến bạn mất uy tín. Mẹo: luôn báo cả hai con số, nêu rõ phần phụ thuộc.
Mẹo tổng quát: Sau vài sprint, so sánh estimate với thực tế để hiệu chỉnh cảm giác của team. Estimation là kỹ năng cải thiện theo thời gian, không phải tài năng bẩm sinh.
Bài tập thực hành
Bài 1 — Tập tư duy tương đối. Lấy 5 tính năng bất kỳ của một app bạn hay dùng (ví dụ MoMo hoặc Shopee): đăng nhập bằng OTP, đổi ảnh đại diện, tìm kiếm sản phẩm, thanh toán qua ví, lọc đơn hàng theo trạng thái. Không ước lượng thời gian. Thay vào đó, gán mỗi tính năng một điểm Fibonacci (1, 2, 3, 5, 8) dựa trên độ phức tạp tương đối so với nhau. Viết một câu giải thích cho mỗi con số.
Bài 2 — Quy đổi velocity. Backlog của một dự án còn 150 story point. Team có velocity 3 sprint gần nhất lần lượt là 28, 32, 30 điểm; sprint dài 2 tuần. Hãy tính số sprint và số tuần cần thiết, rồi viết một câu trả lời cho stakeholder theo dạng khoảng kèm giả định.
Bài 3 — Estimate công việc BA của bạn. Giả sử bạn được giao viết requirement cho tính năng "đặt lịch hẹn với chuyên gia". Liệt kê tất cả đầu việc BA cần làm, ước lượng effort (ngày công) cho từng việc, xác định các phụ thuộc, rồi đưa ra cả con số effort và duration dự kiến.
Bài 4 — Đóng vai refinement. Cho story "Người dùng có thể hủy đơn hàng đã đặt". Viết ra ít nhất 4 câu hỏi làm rõ mà một BA giỏi nên đặt ra trước khi team estimate (gợi ý: hủy được trong điều kiện nào? hoàn tiền ra sao? đã giao hàng thì sao?).
Tóm tắt
Estimation là một kỹ năng nền tảng mà Designer chuyển sang BA bắt buộc phải làm chủ. Điểm chuyển dịch cốt lõi là từ tư duy "ước lượng thời gian của công việc mình" sang tư duy "ước lượng độ phức tạp tương đối của công việc cả team".
Những điều cần khắc cốt ghi tâm: estimate là dự đoán chứ không phải cam kết; story point đo độ phức tạp, khối lượng và rủi ro chứ không đo giờ; Fibonacci giúp ngừng tranh cãi vô nghĩa; velocity là chiếc cầu đưa story point quay về lịch trình để bạn trả lời "bao giờ xong". Với tư cách BA, ba vai trò của bạn trong estimation là: chuẩn bị story đủ rõ để estimate được, dùng chênh lệch estimate như tín hiệu để làm rõ requirement, và ước lượng chính xác công việc của bản thân bằng cách tách effort khỏi duration.
Bạn không cần là người bốc con số cao nhất trong phòng. Bạn cần là người hỏi đúng câu hỏi khiến cả phòng estimate chính xác hơn. Đó chính là giá trị mà một BA xuất thân từ Design mang lại — bạn hiểu người dùng, hiểu luồng, và giờ bạn hiểu cả nhịp của team.