Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm Finance hay Kế toán, có một sự thật bạn chưa nhận ra: bạn đã là một chuyên gia ước lượng (estimation) rồi. Mỗi lần bạn lập dự toán ngân sách cho năm tài chính, báo giá phí kiểm toán cho một khách hàng mới, hay xây dựng project plan với timeline cho dự án triển khai ERP — bạn đang làm chính xác cái việc mà một Business Analyst phải làm mỗi sprint: dự đoán nỗ lực và thời gian cho một công việc chưa xảy ra.
Vấn đề là khi chuyển sang BA, bạn sẽ va vào một bức tường thuật ngữ lạ lẫm: "story point", "velocity", "planning poker", "T-shirt sizing". Nghe rất khác với "man-day × rate" mà bạn quen. Nhiều người Finance chuyển BA bị hụt hơi ở đây — họ cố ép tư duy "giờ công × đơn giá" vào framework Agile và rồi bối rối khi team bảo "đừng quy story point ra giờ".
Tin tốt là: bản chất estimation không hề thay đổi. Cái thay đổi là đơn vị đo, cách xử lý sự không chắc chắn, và mục đích của con số. Bài này sẽ giúp bạn bắc cây cầu từ thế giới man-day của Finance sang thế giới story point của Agile — không phải bằng cách vứt bỏ kinh nghiệm cũ, mà bằng cách tận dụng nó như một lợi thế. Sau bài này, bạn sẽ estimate được effort cho công việc của một BA (viết tài liệu, phân tích, làm spec) và tham gia tự tin vào một buổi sprint planning.
Khái niệm cốt lõi
Estimation trong Finance: cái bạn đã thành thạo
Trong Finance/Kế toán, estimation luôn có ba đặc điểm:
- Quy về tiền hoặc giờ tuyệt đối. Phí kiểm toán = số man-day × đơn giá/ngày. Ngân sách = tổng các khoản chi dự kiến. Đây là con số "cứng", có thể ký hợp đồng, cam kết với khách hàng.
- Dựa trên dữ liệu lịch sử. Bạn báo giá audit năm nay dựa trên số giờ thực tế năm ngoái cho khách hàng tương tự. Đây là tư duy "benchmark" — rất gần với cách Agile dùng velocity.
- Có buffer và contingency. Kế toán nào cũng biết để dành 10-15% dự phòng cho rủi ro. Đây chính xác là khái niệm "buffer for uncertainty" trong Agile.
Tại sao Agile không dùng man-day mà dùng story point?
Story point là một đơn vị tương đối, không phải tuyệt đối. Nó không trả lời câu hỏi "việc này mất bao nhiêu giờ?" mà trả lời "việc này lớn cỡ nào so với những việc khác?".
Lý do team Agile bỏ giờ tuyệt đối nằm ở ba điểm:
- Con người ước lượng độ lớn tương đối tốt hơn thời gian tuyệt đối. Bạn khó nói chính xác "đi từ Hà Nội vào Đà Nẵng mất bao lâu" (phụ thuộc phương tiện, tắc đường, thời tiết), nhưng dễ nói "đi Đà Nẵng xa gấp đôi đi Vinh". Story point khai thác điểm mạnh này của não bộ.
- Tốc độ của mỗi người khác nhau, nhưng độ lớn công việc thì cố định. Một junior dev cần 2 ngày cho việc mà senior làm 4 giờ — nhưng độ phức tạp của việc đó là như nhau. Story point đo độ lớn, rồi để "velocity" (số point team hoàn thành mỗi sprint) tự quy đổi ra thời gian thực tế.
- Tách bạch ước lượng khỏi cam kết. Khi bạn nói "5 ngày", sếp nghe thành lời hứa. Khi bạn nói "5 point", đó là đánh giá độ phức tạp — thời gian thực do velocity quyết định.
Ba thành tố của một story point
Khi gán point cho một công việc, ta cân nhắc ba yếu tố — hãy nhớ bằng công thức Effort + Complexity + Uncertainty:
- Effort (khối lượng): việc này nhiều hay ít? Viết 1 use case hay 20 use case?
- Complexity (độ phức tạp): logic rắc rối tới đâu? Một business rule đơn giản hay một ma trận phân quyền chằng chịt?
- Uncertainty (độ bất định): ta hiểu rõ yêu cầu chưa? Stakeholder đã chốt chưa, hay còn mơ hồ?
Thang Fibonacci và T-shirt sizing
Story point thường dùng dãy Fibonacci: 1, 2, 3, 5, 8, 13, 21. Khoảng cách giữa các số ngày càng rộng để phản ánh một sự thật: việc càng lớn, ta càng khó ước lượng chính xác. Sự khác biệt giữa 1 và 2 point thì rõ, nhưng giữa 20 và 21 thì vô nghĩa — nên Fibonacci buộc ta chọn "8 hay 13" thay vì cãi nhau "11 hay 12".
T-shirt sizing (XS, S, M, L, XL) là biến thể đơn giản hơn, dùng khi ước lượng sơ bộ ở giai đoạn đầu, trước khi đủ thông tin để gán số cụ thể.
Velocity — "đơn giá" của thời đại Agile
Đây là khái niệm giúp người Finance "à há" ngay. Trong Finance, bạn có công thức: Chi phí = man-day × đơn giá. Trong Agile: Thời gian = số point ÷ velocity.
Velocity là số story point trung bình mà team hoàn thành mỗi sprint. Nếu team có velocity 30 point/sprint (sprint 2 tuần), và backlog còn 120 point, bạn biết ngay cần khoảng 4 sprint = 8 tuần. Velocity chính là "tỷ giá quy đổi" giữa point và thời gian — y như đơn giá quy đổi man-day ra tiền.
Tình huống thực tế
Tình huống 1: Nguyên kế toán trưởng và cú sốc planning poker đầu tiên — fintech tại TP.HCM
Chị Hương, 33 tuổi, từng là kế toán trưởng một công ty thương mại, mới chuyển sang vị trí BA tại một công ty fintech cho vay tiêu dùng ở TP.HCM. Sprint planning đầu tiên, team đưa ra user story: "Là một nhân viên thẩm định, tôi muốn xem lịch sử trả nợ của khách để quyết định duyệt vay."
Theo phản xạ Finance, chị Hương rút máy tính ra: "Việc này tôi viết spec mất nửa ngày, dev code mất 2 ngày, test 1 ngày, vậy 3,5 man-day." Cả team nhìn chị bối rối. Scrum Master nhẹ nhàng giải thích: "Chị ơi, mình không estimate giờ. Mình chơi planning poker — mỗi người chọn một con số point, rồi thảo luận."
Hóa ra story này phức tạp hơn chị tưởng: dữ liệu lịch sử trả nợ nằm ở ba hệ thống khác nhau (CIC, hệ thống nội bộ, đối tác), cần xử lý trường hợp khách chưa có lịch sử tín dụng. Một dev chọn 13 point, chị Hương ban đầu chọn 3. Qua thảo luận, chị nhận ra mình đã đánh giá thấp uncertainty của phần tích hợp dữ liệu. Cuối cùng cả team chốt 8 point.
Bài học: Tư duy man-day của Finance giỏi ước lượng effort thuần (viết bao nhiêu trang), nhưng dễ bỏ sót complexity kỹ thuật và uncertainty. Planning poker tồn tại chính để lôi những điểm mù này ra ánh sáng qua thảo luận tập thể. Đừng estimate một mình rồi báo số — hãy lắng nghe góc nhìn dev.
Tình huống 2: Quy đổi sai story point ra tiền — bài học từ một dự án ERP
Anh Tuấn, ex-Finance làm BA tại một công ty triển khai ERP cho các doanh nghiệp sản xuất, mắc một lỗi kinh điển. Sếp hỏi: "Module kho này bao nhiêu point?". Team trả lời 80 point. Anh Tuấn, vì phản xạ Finance, tự quy đổi: "Velocity team là 20 point/sprint, vậy 4 sprint. Mỗi sprint chi phí nhân sự khoảng 200 triệu, vậy module này tốn 800 triệu." Anh báo con số này cho khách hàng như một cam kết.
Vấn đề nảy sinh ở sprint 3: team gặp một yêu cầu compliance về quản lý lô/hạn sử dụng (batch/expiry tracking) cho ngành thực phẩm mà chưa ai lường trước. Backlog phình từ 80 lên 130 point. Khách hàng nổi giận vì "đã cam kết 800 triệu".
Bài học: Story point là công cụ lập kế hoạch nội bộ, không phải con số để ký hợp đồng cứng như phí kiểm toán. Người Finance có thói quen biến mọi ước lượng thành cam kết — đây là cái bẫy. Khi cần đưa con số cho khách, hãy dùng khoảng (range) và nêu rõ giả định: "Dựa trên hiểu biết hiện tại, ước tính 4-6 sprint, sẽ cập nhật sau mỗi sprint." Đây chính là tư duy "contingency" mà kế toán vốn đã quen, chỉ là áp dụng minh bạch hơn.
Tình huống 3: Dùng velocity để lập kế hoạch — một startup logistics tại Hà Nội
Một startup logistics ở Hà Nội cần biết khi nào ra mắt được tính năng theo dõi đơn hàng real-time để đi gọi vốn vòng tiếp theo. Chị Lan, BA xuất thân từ kiểm toán, được giao việc trả lời câu hỏi "bao giờ xong?".
Thay vì đoán mò, chị áp dụng đúng tư duy benchmark của Finance. Chị lấy dữ liệu 4 sprint gần nhất: team hoàn thành 22, 25, 19, 24 point — velocity trung bình khoảng 22,5 point/sprint. Tính năng tracking được team ước lượng tổng 90 point. Phép tính: 90 ÷ 22,5 = 4 sprint = 8 tuần. Chị báo cáo: "Nếu giữ nguyên team và không thêm việc đột xuất, tính năng sẽ sẵn sàng trong 8-10 tuần (đã tính buffer cho rủi ro)."
CEO rất hài lòng vì lần đầu có một con số dựa trên dữ liệu thật, không phải lời hứa cảm tính của dev. Đến vòng gọi vốn, con số timeline có cơ sở này giúp startup tạo niềm tin với nhà đầu tư.
Bài học: Velocity chính là "đơn giá lịch sử" của Agile. Người Finance có lợi thế tự nhiên ở đây — bạn đã quen dùng số liệu quá khứ để dự báo tương lai (như dự báo dòng tiền dựa trên kỳ trước). Hãy mang đúng kỹ năng đó vào estimation Agile.
Hướng dẫn từng bước
Đây là quy trình để bạn — một BA xuất thân Finance — estimate effort cho công việc của chính mình và tham gia estimate cùng team.
Bước 1 — Chia nhỏ công việc (decomposition). Trước khi estimate, hãy bẻ công việc lớn thành các đầu việc đủ nhỏ để hình dung. Đừng estimate "viết tài liệu cho cả module thanh toán" — hãy tách thành "viết 5 use case", "vẽ 3 process flow", "soạn business rule catalog". Kỹ năng này bạn đã có: nó giống hệt việc tách một khoản mục lớn thành các tiểu khoản trong dự toán.
Bước 2 — Chọn một "reference story" làm mốc. Lấy một công việc quen thuộc mà cả team đồng thuận là "2 point" — ví dụ "viết một use case đơn giản với một luồng chính, không có ngoại lệ phức tạp". Mọi ước lượng sau sẽ so sánh tương đối với mốc này: "việc kia khó gấp đôi cái mốc, vậy 5 point". Đây là tư duy benchmark thuần túy của Finance.
Bước 3 — Cân nhắc cả ba thành tố. Với mỗi đầu việc, tự hỏi: Effort bao nhiêu? Complexity tới đâu? Uncertainty cao không? Nếu yêu cầu còn mơ hồ, đừng ngại gán point cao — sự mơ hồ là rủi ro thật.
Bước 4 — Gán point theo Fibonacci. Chọn từ 1, 2, 3, 5, 8, 13. Nếu một việc bị gán 21 trở lên, đó là tín hiệu việc quá lớn — hãy quay lại Bước 1 và chia nhỏ tiếp.
Bước 5 — Estimate tập thể bằng planning poker. Mỗi thành viên chọn point độc lập (để tránh bị "neo" theo người nói trước). Nếu chênh lệch lớn (người 3, người 13), người chọn cao nhất và thấp nhất giải thích lý do — thường họ đang nhìn thấy một khía cạnh người kia bỏ sót. Thảo luận rồi chọn lại đến khi hội tụ.
Bước 6 — Theo dõi velocity qua các sprint. Sau mỗi sprint, ghi lại số point hoàn thành. Sau 3-4 sprint bạn có velocity ổn định để dự báo. Lập một bảng đơn giản trong Excel (công cụ ruột của bạn) theo dõi velocity — đây là báo cáo bạn làm xuất sắc nhất.
Bước 7 — Quy đổi sang timeline khi cần giao tiếp với stakeholder. Dùng công thức Số sprint = Backlog point ÷ Velocity, luôn kèm range và giả định. Không bao giờ biến point thành cam kết cứng kiểu hợp đồng.
Lỗi thường gặp & mẹo
Lỗi 1 — Cố quy đổi cứng 1 point = X giờ. Đây là lỗi số một của người Finance. Bạn sẽ rất muốn lập bảng "1 point = 4 giờ". Đừng. Velocity của mỗi team khác nhau, và quy đổi cứng làm hỏng toàn bộ ý nghĩa của point. Hãy để velocity tự làm việc quy đổi.
Lỗi 2 — Biến estimate thành lời hứa. Như tình huống anh Tuấn, đừng cam kết con số như ký hợp đồng audit. Estimate là dự báo, sẽ được tinh chỉnh. Luôn dùng range.
Lỗi 3 — Estimate một mình rồi áp đặt. Bạn có thể tự tin với phần BA (viết tài liệu), nhưng độ phức tạp kỹ thuật cần góc nhìn dev. Estimation Agile là môn thể thao đồng đội.
Lỗi 4 — Tăng point để "có thêm buffer giấu kín". Cám dỗ kế toán: phồng số lên cho an toàn. Điều này làm méo velocity và phá vỡ niềm tin. Hãy ước lượng trung thực; buffer được xử lý minh bạch ở cấp release planning, không giấu trong từng story.
Lỗi 5 — Quên rằng point chỉ tương đối trong một team. 8 point của team A không bằng 8 point của team B. Đừng so sánh velocity giữa các team để đánh giá năng suất — đó là lỗi quản lý phổ biến.
Mẹo tận dụng nền Finance:
- Biến variance analysis thành công cụ của bạn. Trong kế toán, bạn phân tích chênh lệch giữa thực tế và dự toán mỗi tháng. Hãy làm đúng vậy với estimate: sau mỗi sprint, so sánh point ước lượng và thực tế hoàn thành, tìm pattern lệch. Đây là kỹ năng vàng giúp estimate ngày càng chính xác.
- Dùng Excel/Google Sheets để dựng burndown và velocity chart. Bạn vốn là cao thủ spreadsheet — biến nó thành lợi thế trực quan hóa cho team.
- Khi mơ hồ, hãy spike trước. Nếu uncertainty quá cao để estimate, đề xuất một "spike" (việc nghiên cứu nhỏ, có giới hạn thời gian) để làm rõ trước khi estimate chính thức. Giống như bạn làm khảo sát sơ bộ trước khi báo giá một hợp đồng audit lạ.
Bài tập thực hành
Bài tập 1 — Thiết lập reference story. Lấy ba công việc BA quen thuộc: (a) viết một use case một luồng chính, (b) vẽ một process flow 10 bước có 2 nhánh rẽ, (c) soạn business rule catalog cho một module phân quyền phức tạp. Tự gán point Fibonacci cho cả ba, lấy (a) làm mốc 2 point. Viết một câu giải thích vì sao (c) cao hơn (a) theo cả ba thành tố Effort/Complexity/Uncertainty.
Bài tập 2 — Tính timeline từ velocity. Một team có velocity 4 sprint gần nhất là 18, 22, 20, 24 point (sprint 2 tuần). Backlog dự án còn 168 point. Hãy tính số sprint và số tuần cần thiết, sau đó viết một câu báo cáo cho stakeholder có kèm range và ít nhất một giả định.
Bài tập 3 — Phát hiện lỗi. Một BA mới báo cáo: "Module này 50 point, velocity 25, vậy đúng 2 sprint, em cam kết với khách hàng giao trong 4 tuần, chi phí cố định 400 triệu." Hãy chỉ ra ít nhất ba lỗi trong câu này và viết lại cách báo cáo đúng đắn.
Bài tập 4 — Variance analysis. Lập một bảng Excel với 4 sprint: cột point ước lượng, cột point thực tế hoàn thành, cột chênh lệch và % chênh lệch. Tự tạo số liệu giả định, rồi viết một đoạn ngắn phân tích pattern (team có xu hướng đánh giá thấp hay cao? ở loại việc nào?).
Tóm tắt
Estimation không phải kỹ năng mới với người Finance — bạn đã làm nó cả sự nghiệp qua dự toán ngân sách, báo giá audit và project plan. Cái cần học khi chuyển sang BA không phải là cách estimate, mà là đổi đơn vị đo và đổi cách xử lý sự không chắc chắn.
Những điểm cốt lõi cần nhớ:
- Story point đo độ lớn tương đối, không phải thời gian tuyệt đối, dựa trên ba thành tố: Effort + Complexity + Uncertainty.
- Velocity là "đơn giá" của Agile — nó quy đổi point sang thời gian, y như đơn giá quy man-day ra tiền. Đây là nơi tư duy benchmark của Finance phát huy mạnh nhất.
- Đừng quy đổi cứng point ra giờ, và đừng biến estimate thành cam kết kiểu hợp đồng — luôn dùng range và nêu giả định.
- Estimation là môn thể thao đồng đội qua planning poker; tư duy man-day của bạn giỏi đo effort nhưng cần góc nhìn dev để bắt complexity và uncertainty.
- Tận dụng lợi thế Finance: variance analysis để cải thiện độ chính xác, và Excel để trực quan hóa velocity/burndown cho cả team.