Mở đầu — vì sao bài này quan trọng
Nếu bạn từng là Designer, bạn đã quen với việc làm việc trong sprint: nhận task trên Jira, tham gia daily, giao mockup theo từng vòng lặp. Nhưng khi chuyển sang vai trò BA, bạn sẽ nhanh chóng nhận ra một sự thật gây bối rối: Scrum Guide — tài liệu gốc định nghĩa Scrum — không hề nhắc đến chữ "Business Analyst" một lần nào. Scrum chỉ có ba vai chính thức: Product Owner (PO), Scrum Master (SM), và Developers. Vậy BA đứng ở đâu?
Đây không phải câu hỏi hàn lâm. Đây là câu hỏi sinh tử với sự nghiệp của bạn. Trong 90% doanh nghiệp Việt Nam làm Agile — từ các product company như MoMo, Tiki, VNG cho tới các outsourcing house như FPT Software, KMS, NashTech — BA vẫn tồn tại và là một mắt xích cực kỳ quan trọng. Nhưng vì Scrum không "cấp" cho bạn một chỗ ngồi chính thức, bạn phải tự hiểu mình đang đóng vai gì, ranh giới trách nhiệm ở đâu, và làm sao để không giẫm chân PO hay Dev.
Bài này sẽ giúp bạn định vị bản thân trong hai framework Agile phổ biến nhất tại Việt Nam: Scrum (theo sprint cố định) và Kanban (luồng liên tục). Hiểu rõ điều này, bạn sẽ biết cách "chèn" giá trị của mình vào đúng nơi, thay vì cảm giác lửng lơ giữa PO và team — một cảm giác mà rất nhiều Designer mới chuyển BA gặp phải trong 3 tháng đầu.
Khái niệm cốt lõi
Vì sao Scrum không có role BA?
Scrum ra đời từ tư duy tối giản: càng ít vai, càng ít điểm nghẽn giao tiếp. Người tạo ra Scrum tin rằng Product Owner nên là người duy nhất chịu trách nhiệm về "cái gì cần làm và tại sao" (the what & why), còn Developers lo "làm thế nào" (the how). Trong lý thuyết, PO sẽ tự viết requirement, tự refine backlog, tự trò chuyện với stakeholder.
Nhưng thực tế Việt Nam khác lý thuyết. PO thường là một business leader bận rộn — có thể là trưởng phòng sản phẩm kiêm nhiệm, hoặc một người phía khách hàng (ở mô hình outsourcing) ngồi tận Nhật Bản, Singapore. Họ không có thời gian, không có kỹ năng viết user story chi tiết, không thạo elicitation. Đó chính là khoảng trống mà BA lấp vào.
Ba vai trò thực tế của BA trong Scrum
Trong thực tế, BA thường đóng một trong ba vai (đôi khi lai giữa các vai này tùy dự án):
1. Proxy Product Owner (PO ủy quyền). Đây là vai phổ biến nhất tại Việt Nam, đặc biệt trong outsourcing. PO thật ở phía khách hàng chỉ đưa ra định hướng cấp cao và ngân sách; BA đóng vai "cánh tay nối dài", thay PO refine backlog, viết acceptance criteria, ưu tiên story, và trả lời câu hỏi của Dev hàng ngày. Bạn ra quyết định thay PO trong phạm vi đã được ủy quyền, và chỉ escalate những quyết định lớn (thay đổi scope, ngân sách, timeline).
2. Requirement specialist / BA hỗ trợ PO. Ở mô hình này, PO là người thật sự cầm quyền quyết định, nhưng BA là chuyên gia làm việc "phía sau" — elicit yêu cầu từ nhiều stakeholder, phân tích quy trình nghiệp vụ, viết tài liệu chi tiết, chuẩn bị backlog để PO chỉ việc phê duyệt và ưu tiên. BA ở đây giống một "kiến trúc sư yêu cầu", còn PO là "chủ đầu tư".
3. BA kiêm Team facilitator / bridge. BA đóng vai cầu nối giữa business và tech ngay trong team, giúp Dev hiểu đúng nghiệp vụ, giúp QA viết test case đúng logic, tham gia làm rõ story ngay tại chỗ. Đây là vai hợp nhất với người có nền Design vì bạn vốn quen làm việc trực tiếp với engineer.
BA trong các nghi thức (ceremonies) của Scrum
Dù đóng vai nào, BA đều tham gia sâu vào các ceremony:
- Backlog Refinement (Grooming): Đây là "sân nhà" của BA. Bạn dẫn dắt việc làm rõ story, bổ sung acceptance criteria, tách story lớn thành nhỏ.
- Sprint Planning: BA giải thích chi tiết từng story để Dev estimate; làm rõ những chỗ mơ hồ trước khi team commit.
- Daily Standup: BA lắng nghe blocker liên quan đến yêu cầu, sẵn sàng làm rõ ngay để Dev không bị kẹt.
- Sprint Review: BA thường là người demo hoặc chuẩn bị nội dung demo, đối chiếu kết quả với acceptance criteria.
- Retrospective: BA tham gia như một thành viên team, góp ý cải tiến quy trình làm việc.
BA trong Kanban
Kanban khác Scrum ở chỗ: không có sprint, không có role cố định, làm việc theo luồng liên tục (continuous flow). Công việc được kéo (pull) qua các cột trên board — ví dụ: Backlog → Analysis → Ready for Dev → In Dev → Testing → Done — với giới hạn WIP (Work In Progress) cho mỗi cột.
Trong Kanban, BA thường "sở hữu" các cột đầu luồng: Backlog và Analysis. Nhiệm vụ của bạn là đảm bảo luôn có đủ item đã được phân tích rõ ràng, sẵn sàng để Dev "kéo" vào làm — không để Dev phải chờ vì thiếu yêu cầu rõ. Ở đây, chỉ số quan trọng với BA là lead time (thời gian từ lúc yêu cầu vào board đến lúc hoàn thành) và tránh để cột Analysis trở thành nút thắt cổ chai. Kanban đặc biệt hợp với đội maintenance, support, hoặc các team nhận yêu cầu không đều đặn.
Tình huống thực tế
Tình huống 1: BA làm Proxy PO tại một outsourcing house ở TP.HCM
Một công ty outsourcing tại Quận 7 (giả định tên KTech, ~200 nhân sự) nhận dự án xây dựng app quản lý kho cho một khách hàng Nhật. PO thật là ông Tanaka ngồi ở Tokyo, chênh 2 múi giờ, chỉ họp được 2 buổi/tuần vào chiều muộn giờ Việt Nam.
Chị Mai — vừa chuyển từ UI Designer sang BA sau 4 năm làm design — được giao vai Proxy PO. Trong sprint đầu, chị mắc lỗi kinh điển: mỗi khi Dev hỏi "logic tính tồn kho thế nào khi hàng bị hư?", chị đều trả lời "để em hỏi anh Tanaka đã". Kết quả: 6 story bị block, sprint chỉ hoàn thành 40% cam kết, velocity tụt thảm hại.
Bài học chị rút ra và cách khắc phục: chị đề nghị Tanaka ký một "decision authority matrix" — bảng ghi rõ loại quyết định nào chị được tự quyết (UI wording, edge case nghiệp vụ nhỏ, thứ tự ưu tiên trong sprint) và loại nào phải escalate (thay đổi scope, thêm tính năng lớn). Sang sprint 3, tỉ lệ story bị block giảm còn 1-2, velocity ổn định ở mức 32 story point. Bài học: làm Proxy PO mà không có quyền quyết định thì bạn chỉ là "người chuyển thư", không phải BA. Phải chủ động xin ủy quyền rõ ràng.
Tình huống 2: BA hỗ trợ PO tại một product company
Tại một fintech giả định tên PayFast (mô phỏng môi trường như MoMo/ZaloPay), anh Hùng — cựu Product Designer — chuyển sang làm BA cho squad thanh toán. PO của squad là chị Linh, một người rất mạnh về business nhưng cực bận vì phụ trách 3 squad cùng lúc.
Anh Hùng đóng vai requirement specialist. Trước mỗi buổi refinement, anh dành 2 ngày đi phỏng vấn team vận hành, team chăm sóc khách hàng, đọc log lỗi để hiểu vì sao tỉ lệ giao dịch thất bại ở bước OTP lên tới 8%. Anh chuẩn bị sẵn 12 user story kèm acceptance criteria và flow chi tiết. Chị Linh chỉ mất 30 phút để review, điều chỉnh ưu tiên và phê duyệt — thay vì phải tự ngồi viết cả buổi.
Kết quả sau 2 sprint: tỉ lệ thất bại ở bước OTP giảm từ 8% xuống 3%, và điều quan trọng hơn — chị Linh tin tưởng giao gần như toàn bộ việc chuẩn bị backlog cho anh Hùng. Bài học: khi bạn làm PO "nhẹ gánh", bạn tạo ra giá trị mà PO nhìn thấy ngay. Đừng chờ được giao việc — hãy chủ động lấp khoảng trống mà PO không có thời gian làm.
Tình huống 3: BA trong team Kanban làm maintenance
Một ngân hàng số giả định (mô phỏng môi trường như Cake, Timo) có một team maintenance nhận yêu cầu chỉnh sửa từ nhiều phòng ban: khi thì phòng risk yêu cầu đổi ngưỡng cảnh báo, khi thì marketing đòi thêm field vào form đăng ký. Yêu cầu đến không đều, không thể chia sprint gọn gàng — nên team dùng Kanban.
Chị Trang, BA của team, phụ trách cột Analysis với WIP limit là 3. Ban đầu chị "ôm" quá nhiều: nhận hết mọi yêu cầu vào phân tích cùng lúc, khiến cột Analysis lúc nào cũng có 7-8 item dở dang, không cái nào xong hẳn. Lead time trung bình lên tới 12 ngày.
Sau khi được Scrum Master (đóng vai Kanban flow master) nhắc, chị áp dụng đúng WIP limit: chỉ phân tích tối đa 3 item, item nào chưa rõ thì kéo stakeholder vào giải quyết dứt điểm trước khi nhận cái mới. Lead time giảm còn 5 ngày sau một tháng. Bài học: trong Kanban, kỷ luật WIP quan trọng hơn tốc độ. BA giỏi không phải là người nhận nhiều nhất, mà là người giữ luồng chảy đều nhất.
Hướng dẫn từng bước
Khi bạn gia nhập một team Agile với vai trò BA, hãy làm theo trình tự sau để định vị nhanh:
Bước 1 — Xác định framework và vai của bạn. Hỏi thẳng SM/PO: team đang chạy Scrum hay Kanban? Bạn được kỳ vọng đóng vai nào trong ba vai kể trên? Đừng đoán — hiểu lầm vai trò là nguyên nhân số một gây xung đột.
Bước 2 — Làm rõ ranh giới quyền quyết định. Nếu là Proxy PO, xin một decision authority matrix. Nếu hỗ trợ PO, thống nhất quy trình: bạn chuẩn bị tới đâu, PO duyệt tới đâu. Viết ra giấy, đừng để miệng.
Bước 3 — Nắm lịch ceremony và xác định vai của mình trong từng buổi. Đặc biệt chuẩn bị kỹ cho Refinement — đây là nơi BA tỏa sáng. Đến buổi refinement với story đã viết sẵn, đừng đến tay không.
Bước 4 — Thiết lập "Definition of Ready" (DoR). Thống nhất với team một checklist: một story phải thỏa điều kiện gì mới được đưa vào sprint (có acceptance criteria rõ, có mockup nếu cần, không còn câu hỏi mở lớn). BA là người gác cổng DoR.
Bước 5 — Với Kanban, thiết lập WIP limit cho cột Analysis và bám sát lead time. Ưu tiên hoàn thành dứt điểm hơn là bắt đầu nhiều việc.
Bước 6 — Duy trì "just-in-time" analysis. Trong Agile, đừng phân tích toàn bộ backlog từ đầu (đó là tư duy Waterfall). Chỉ làm rõ chi tiết những story sắp được làm trong 1-2 sprint tới. Story xa hơn giữ ở mức thô.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến mình thành "người chuyển thư". Nhiều BA mới chỉ nhận câu hỏi từ Dev rồi chuyển cho PO, nhận câu trả lời rồi chuyển lại. Đó không phải BA, đó là email server. Hãy tự trang bị đủ hiểu biết nghiệp vụ để trả lời được đa số câu hỏi tại chỗ.
Lỗi 2 — Viết tài liệu quá dày theo kiểu Waterfall. Người mới chuyển BA hay có xu hướng viết BRD 50 trang. Trong Agile, tài liệu vừa đủ để team làm việc là được — ưu tiên hội thoại trực tiếp và acceptance criteria ngắn gọn hơn là văn bản đồ sộ.
Lỗi 3 — Giẫm chân PO về quyền ưu tiên. Việc quyết "làm gì trước" (prioritization) về nguyên tắc thuộc PO. BA có thể phân tích, đề xuất, nhưng đừng tự ý đảo thứ tự backlog nếu chưa được ủy quyền.
Lỗi 4 — Phân tích trước quá xa (over-analysis). Đừng làm rõ chi tiết story còn nằm cách đây 5 sprint — yêu cầu sẽ thay đổi, công sức của bạn đổ sông đổ biển.
Mẹo tận dụng nền Design: Kỹ năng làm mockup và visual thinking của bạn là vũ khí. Trong buổi refinement, một wireframe nhanh làm rõ ý tưởng gấp mười lần một đoạn văn. Dev hiểu ngay, câu hỏi giảm hẳn. Đây là lợi thế mà BA thuần nghiệp vụ không có.
Mẹo với velocity và lead time: Đừng coi các chỉ số này là để "đánh giá" ai. Với BA, chúng là công cụ chẩn đoán: velocity tụt bất thường thường báo hiệu story chưa đủ rõ khi vào sprint — tức là khâu chuẩn bị của bạn có vấn đề.
Bài tập thực hành
Bài 1 — Tự định vị. Nếu bạn đang đi làm, hãy viết ra: team bạn dùng Scrum hay Kanban? Bạn đang đóng vai nào trong ba vai BA? Nếu chưa đi làm, chọn một trong ba tình huống trên và viết một decision authority matrix mẫu với ít nhất 5 loại quyết định, phân loại "BA tự quyết" hay "escalate PO".
Bài 2 — Viết Definition of Ready. Soạn một checklist DoR gồm 5-7 tiêu chí để một user story đủ điều kiện đưa vào sprint. Giải thích ngắn vì sao mỗi tiêu chí quan trọng.
Bài 3 — Chẩn đoán tình huống. Một team Scrum có velocity dao động thất thường: sprint 1 đạt 40 point, sprint 2 chỉ 18, sprint 3 đạt 45. Với vai trò BA, hãy liệt kê 3 giả thuyết vì sao velocity không ổn định và 3 hành động bạn sẽ làm để cải thiện.
Bài 4 — Thiết kế Kanban board. Vẽ một Kanban board cho team maintenance 5 người (2 Dev, 1 QA, 1 BA, 1 SM), đề xuất các cột và WIP limit hợp lý cho từng cột. Giải thích vì sao bạn đặt WIP limit như vậy cho cột Analysis.
Tóm tắt
Scrum không định nghĩa role BA, nhưng thực tế Việt Nam luôn cần BA lấp khoảng trống mà PO không đủ thời gian hoặc kỹ năng để lo. Bạn sẽ đóng một trong ba vai: Proxy PO (ủy quyền quyết định — phổ biến trong outsourcing), requirement specialist hỗ trợ PO (phổ biến trong product company), hoặc team bridge/facilitator. Điều tối quan trọng là làm rõ ranh giới quyền quyết định ngay từ đầu, để không thành "người chuyển thư" và không giẫm chân PO.
Trong Scrum, sân nhà của BA là buổi Backlog Refinement, và bạn là người gác cổng Definition of Ready. Trong Kanban, bạn sở hữu cột Analysis đầu luồng, phải giữ kỷ luật WIP limit và bám sát lead time để luồng công việc chảy đều. Dù ở framework nào, hãy áp dụng tư duy just-in-time analysis — chỉ làm rõ chi tiết những gì sắp làm, không phân tích trước quá xa. Và đừng quên: nền Design cho bạn một lợi thế thật sự — khả năng dùng wireframe để làm rõ yêu cầu nhanh gấp nhiều lần văn bản thuần. Đó là điểm khác biệt biến bạn từ một BA bình thường thành một BA mà cả Dev lẫn PO đều muốn làm việc cùng.