Mở đầu — vì sao bài này quan trọng
Nếu bạn để ý các tin tuyển dụng BA tại Việt Nam trong vài năm gần đây — từ MoMo, VNPAY, Techcombank cho tới các công ty outsourcing như FPT Software, NashTech — bạn sẽ thấy một cụm từ xuất hiện gần như ở mọi nơi: "Agile environment", "experience with Scrum", "work closely with Product Owner". Thực tế thị trường đã dịch chuyển: phần lớn dự án phần mềm hiện nay không còn chạy theo Waterfall thuần túy nữa, mà vận hành theo Scrum, Kanban, hoặc một phiên bản lai giữa chúng.
Vấn đề là rất nhiều BA bước vào môi trường Agile với một bộ thói quen của thế giới Waterfall: viết một tài liệu requirement đồ sộ 80 trang, ký duyệt, rồi "ném qua tường" cho team dev. Trong Agile, cách làm đó không chỉ kém hiệu quả mà còn gây hại — vì Agile chủ động chấp nhận rằng requirement sẽ thay đổi, và giá trị nằm ở việc giao phần mềm dùng được sớm và liên tục, chứ không phải ở độ dày của tài liệu.
Bài này tập trung trả lời một câu hỏi rất cụ thể: trong Scrum và Kanban, BA thực sự làm gì mỗi ngày, ở mỗi sự kiện, với mỗi artifact? Chúng ta sẽ không bàn về cách viết User Story (Bài 36) hay cách refine backlog (Bài 37) — những kỹ thuật đó có bài riêng. Ở đây, trọng tâm là vai trò và nhịp làm việc của BA bên trong hai khung Agile phổ biến nhất.
Khái niệm cốt lõi
BA đứng ở đâu trong Scrum?
Điều đầu tiên và cũng gây bối rối nhất: Scrum Guide chính thức chỉ định nghĩa ba vai trò (accountabilities) — Product Owner (PO), Scrum Master (SM) và Developers. Không có vai trò nào tên là Business Analyst. Điều này khiến nhiều BA mới vào Agile hoang mang: "Vậy chỗ của tôi ở đâu?"
Câu trả lời thực tế là: BA không phải một ô trống trong sơ đồ Scrum, mà là một năng lực được phân bổ vào team. Trong thực tế tại Việt Nam, BA thường rơi vào một trong ba mô hình:
- BA kiêm Product Owner: thường gặp ở các sản phẩm nội bộ hoặc startup nhỏ, nơi một người vừa hiểu nghiệp vụ vừa có quyền quyết định ưu tiên backlog.
- BA hỗ trợ Product Owner (Proxy PO / PO support): phổ biến nhất ở doanh nghiệp lớn và outsourcing. PO là người bên business (thường là sếp nghiệp vụ, rất bận, đôi khi ở nước ngoài), còn BA làm "cánh tay nối dài" — chuẩn bị backlog item, làm rõ chi tiết, trả lời câu hỏi của dev thay PO.
- BA là một Developer (theo nghĩa Scrum): trong Scrum Guide, "Developers" là bất kỳ ai trong team góp phần tạo ra Increment — bao gồm cả người phân tích nghiệp vụ. Theo nghĩa này, BA chính là một thành viên của Scrum Team, ngồi trong các sự kiện và cam kết với Sprint Goal.
Sprint là gì và BA làm gì trong mỗi sự kiện
Scrum vận hành theo các Sprint — chu kỳ cố định thường 2 tuần. Mỗi Sprint có bốn sự kiện chính, và BA có một việc rất rõ ràng cần làm ở từng sự kiện:
Sprint Planning — Đầu Sprint, team chọn các item từ Product Backlog để cam kết. Vai trò BA: đảm bảo các item được chọn đủ rõ ("Ready") — tức là dev đọc vào hiểu được phải làm gì, acceptance criteria rõ ràng, dependency đã được nhận diện. BA cũng giải thích bối cảnh nghiệp vụ "vì sao khách hàng cần cái này", giúp dev estimate chính xác hơn.
Daily Scrum — Họp 15 phút mỗi ngày. BA thường tham gia với tư cách thành viên team. Vai trò chính của BA ở đây không phải báo cáo "hôm qua tôi viết được mấy story", mà là gỡ vướng về mặt thông tin: nếu một dev nói "tôi đang kẹt vì không biết khi số dư âm thì hệ thống xử lý ra sao", BA là người cam kết làm rõ ngay trong ngày.
Sprint Review — Cuối Sprint, team demo Increment cho stakeholder. BA đóng vai trò cầu nối: giúp diễn giải phần demo theo ngôn ngữ nghiệp vụ, thu thập phản hồi từ stakeholder, và ghi nhận các yêu cầu phát sinh để đưa vào backlog.
Sprint Retrospective — Team nhìn lại cách làm việc với nhau. BA đóng góp các cải tiến về quy trình phân tích: ví dụ "story tháng này hay thiếu acceptance criteria cho luồng lỗi, sang Sprint sau ta thêm checklist".
Kanban và sự khác biệt về tư duy
Kanban không chia thời gian thành Sprint cố định. Thay vào đó, công việc chảy liên tục qua một bảng (board) với các cột như: Backlog → Analysis → Ready for Dev → In Development → Testing → Done. Hai nguyên tắc cốt lõi của Kanban là trực quan hóa luồng công việc và giới hạn Work In Progress (WIP) — tức mỗi cột chỉ được chứa tối đa một số thẻ nhất định.
Với BA, Kanban thay đổi nhịp làm việc rất rõ. Thay vì "đến Sprint Planning mới chốt scope", BA làm việc theo dòng chảy: liên tục kéo item tiếp theo từ backlog vào cột Analysis, làm rõ, rồi đẩy sang Ready for Dev đúng lúc dev sắp cần (just-in-time). Khái niệm quan trọng nhất BA cần theo dõi trong Kanban là lead time (thời gian từ lúc yêu cầu xuất hiện đến lúc giao xong) và việc tránh để cột Analysis trở thành nút thắt cổ chai làm nghẽn cả luồng.
Một cách so sánh ngắn gọn: Scrum cho BA một nhịp đập (Sprint) để đồng bộ; Kanban cho BA một dòng chảy để tối ưu. Nhiều team Việt Nam thực ra chạy "Scrumban" — dùng Sprint của Scrum nhưng áp giới hạn WIP và tư duy luồng của Kanban.
Tình huống thực tế
Ví dụ 1 — BA làm Proxy PO tại một dự án ngân hàng số (Techcombank-style)
Một BA tên Linh làm cho đối tác triển khai tính năng "chuyển tiền nhanh Napas 24/7" cho mảng mobile banking. PO chính thức là Giám đốc sản phẩm phía ngân hàng — một người cực bận, mỗi tuần chỉ dành được 1 giờ cho team. Team dev 6 người chạy Sprint 2 tuần.
Nếu Linh chờ PO để hỏi từng chi tiết, team sẽ tê liệt. Vì vậy Linh hoạt động như Proxy PO: chị tự chuẩn bị backlog item, làm rõ các quy tắc nghiệp vụ (hạn mức chuyển trong ngày, phí, xử lý khi giao dịch timeout), và chỉ mang những quyết định có tính đánh đổi business lên PO trong buổi gặp 1 giờ. Ví dụ: "Khi Napas trả về timeout sau 30 giây, ta hiển thị 'đang xử lý' rồi đối soát sau, hay báo lỗi ngay? Cái đầu mượt hơn cho khách nhưng rủi ro hơn về đối soát." Đây là loại quyết định Linh không được tự quyết.
Bài học: Vai trò Proxy PO thành công khi BA biết phân tách rõ — việc làm rõ chi tiết thì BA chủ động; việc đánh đổi giá trị business thì để PO quyết. Nhầm lẫn hai loại này là nguồn gốc của hầu hết mâu thuẫn giữa BA và PO trong dự án Agile.
Ví dụ 2 — Team support dùng Kanban tại một công ty e-commerce (Tiki/Shopee-style)
Một đội maintenance & support cho hệ thống quản lý đơn hàng. Công việc đến không đều: hôm nay một bug nghiêm trọng về tính phí ship, mai một yêu cầu nhỏ thêm bộ lọc đơn hàng. Chạy Sprint cố định không hợp lý vì độ ưu tiên thay đổi từng ngày. Họ dùng Kanban với WIP limit là 3 ở cột "Analysis".
BA tên Phúc phát hiện cột Analysis liên tục đầy 3 thẻ và bị nghẽn — dev thì rảnh chờ việc. Nhìn vào số liệu, anh thấy lead time trung bình một item đã tăng từ 4 ngày lên 9 ngày trong một tháng. Phân tích kỹ, nút thắt là: nhiều yêu cầu cần xác nhận từ phòng vận hành kho, mà phản hồi của họ mất 2-3 ngày. Giải pháp của Phúc không phải "làm nhanh hơn", mà là tạo một cột đệm "Chờ xác nhận business" tách riêng, để các thẻ đang chờ kho không chiếm chỗ WIP của việc đang thực sự phân tích được.
Bài học: Trong Kanban, công việc của BA không chỉ là phân tích từng item, mà là quan sát luồng và phát hiện nút thắt. Con số lead time là tín hiệu quý giá mà Waterfall không bao giờ cho bạn thấy.
Ví dụ 3 — BA "ôm" tài liệu kiểu Waterfall trong Sprint (phản ví dụ)
Một startup fintech tuyển một BA giàu kinh nghiệm từ mảng ngân hàng truyền thống. Anh quen viết SRS đầy đủ trước khi code. Vào Sprint đầu tiên, anh dành cả 2 tuần viết một tài liệu 60 trang đặc tả toàn bộ module ví điện tử, trong khi dev không có gì để làm vì "chờ tài liệu xong". Hết Sprint, Increment giao được = 0.
Scrum Master góp ý: thay vì đặc tả tất cả, hãy chỉ làm rõ đủ chi tiết cho 2-3 story sẽ làm trong Sprint này (luồng nạp tiền), để dev bắt tay làm ngay, rồi tiếp tục làm rõ các story sau song song. Sau khi đổi cách, đến cuối Sprint sau, team đã demo được luồng nạp tiền chạy thật.
Bài học: Đặc trưng của BA giỏi trong Agile không phải viết ít tài liệu hơn một cách máy móc, mà là làm rõ vừa đủ, đúng lúc (just enough, just in time). Tài liệu vẫn cần với những thứ phức tạp hoặc bị ràng buộc pháp lý, nhưng nó đi song song với phát triển chứ không chặn trước nó.
Hướng dẫn từng bước
Đây là cách một BA tổ chức công việc của mình trong một Sprint Scrum 2 tuần điển hình:
- Xác định mô hình vai trò của bạn. Trước khi làm gì, làm rõ với team: bạn là PO, Proxy PO, hay thành viên hỗ trợ? Bạn có quyền quyết định ưu tiên không, hay chỉ chuẩn bị? Việc này nên được thống nhất ngay từ đầu dự án để tránh va chạm về thẩm quyền.
- Làm việc "trước một bước" với backlog (look-ahead). Trong khi dev đang làm story của Sprint hiện tại, BA dành phần lớn thời gian làm rõ các story dự kiến cho Sprint kế tiếp. Quy tắc kinh nghiệm: luôn có sẵn khoảng 1.5–2 Sprint khối lượng story đã "Ready".
- Tham gia Backlog Refinement giữa Sprint. Mang các story đã chuẩn bị ra cùng team xem xét, ước lượng, và làm rõ những điểm còn mơ hồ. (Kỹ thuật chi tiết về Definition of Ready ở Bài 37.)
- Trong Sprint, ưu tiên gỡ vướng cho dev. Đặt việc trả lời câu hỏi của dev lên trên việc viết tài liệu cho tương lai. Một dev bị kẹt 1 ngày vì chờ bạn làm rõ là một tổn thất ngay lập tức cho Sprint Goal.
- Chuẩn bị và hỗ trợ Sprint Review. Trước buổi demo, kiểm tra Increment có khớp acceptance criteria không, chuẩn bị kịch bản demo theo góc nhìn nghiệp vụ, và mời đúng stakeholder cần phản hồi.
- Ghi nhận phản hồi và đưa vào backlog. Mọi yêu cầu phát sinh từ Review trở thành backlog item mới, được ưu tiên cùng PO — chứ không "lén" nhét vào Sprint đang chạy.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến BA thành "người gác cổng tài liệu". Nếu mọi câu hỏi của dev đều phải qua bạn và bạn trả lời bằng cách chỉ vào một tài liệu, bạn đang tạo nút thắt. Mẹo: khuyến khích "three amigos" — BA, dev và tester cùng ngồi làm rõ một story, để hiểu biết được chia sẻ chứ không nằm trong đầu một người.
Lỗi 2 — Đặc tả quá xa, quá sớm. Làm rõ chi tiết cho story còn 3 Sprint nữa mới làm là lãng phí, vì khả năng cao nó sẽ thay đổi. Mẹo: áp dụng nguyên tắc "tầm nhìn giảm dần độ chi tiết" — story sắp làm thì chi tiết, story xa thì chỉ cần tiêu đề và mục tiêu.
Lỗi 3 — Nhầm vai trò BA và PO về thẩm quyền. BA làm rõ requirement; PO quyết định requirement nào quan trọng hơn. Khi BA tự ý reorder backlog hoặc từ chối yêu cầu của business, mâu thuẫn nảy sinh. Mẹo: luôn hỏi "đây là quyết định làm rõ hay quyết định đánh đổi giá trị?" — nếu là vế sau, đưa lên PO.
Lỗi 4 — Trong Kanban, chỉ nhìn thẻ của mình mà bỏ qua luồng. Một BA chỉ chăm chăm phân tích nhanh thẻ của mình nhưng để cột downstream nghẽn thì không giúp gì cho throughput tổng thể. Mẹo: theo dõi cumulative flow diagram và lead time, không chỉ số lượng story bạn xử lý.
Mẹo vàng: Trong Agile, thước đo thành công của BA không phải là "tài liệu tôi viết dày bao nhiêu" mà là "team có đang giao được giá trị đều đặn và ít hiểu lầm không". Hãy tự hỏi mỗi cuối Sprint: dev có bao giờ phải dừng lại vì thiếu thông tin từ tôi không?
Bài tập thực hành
- Tự định vị vai trò. Mô tả một dự án bạn từng tham gia (hoặc tưởng tượng). Bạn ở mô hình nào trong ba mô hình: BA-PO, Proxy PO, hay BA-thành viên team? Liệt kê 3 quyết định bạn được tự quyết và 3 quyết định phải đưa lên PO.
- Lập kế hoạch một Sprint của BA. Cho một Sprint 2 tuần, vẽ lịch làm việc của riêng bạn: ngày nào tham gia sự kiện gì, ngày nào dành cho look-ahead refinement, ngày nào ưu tiên gỡ vướng. Phân bổ phần trăm thời gian hợp lý.
- Phân tích nút thắt Kanban. Giả định một board có WIP limit là 4 ở cột Analysis, và lead time trung bình tăng từ 5 lên 11 ngày trong 6 tuần. Đề xuất ít nhất 2 giả thuyết về nguyên nhân và cách bạn sẽ kiểm chứng từng giả thuyết bằng dữ liệu.
- Chuyển đổi tư duy. Lấy một tình huống "BA viết tài liệu 50 trang rồi ném cho dev". Viết lại cách tiếp cận đó theo tinh thần Agile "just enough, just in time" — bạn sẽ làm rõ cái gì trước, cái gì để sau, và phối hợp với dev/tester ra sao?
Tóm tắt
Trong Agile, BA không có một ô vai trò cố định trong Scrum Guide, nhưng lại là một năng lực thiết yếu được phân bổ vào team — thường ở dạng Product Owner, Proxy PO, hoặc thành viên Scrum Team. Điều quan trọng nhất là xác định rõ mình đang ở mô hình nào, để biết ranh giới giữa làm rõ thông tin (việc của BA) và quyết định ưu tiên giá trị (việc của PO).
Trong Scrum, BA có việc rõ ràng ở từng sự kiện: đảm bảo story "Ready" ở Planning, gỡ vướng thông tin ở Daily, làm cầu nối ở Review, cải tiến quy trình ở Retrospective — và quan trọng nhất là làm việc "trước một bước" với backlog. Trong Kanban, BA chuyển sang tư duy luồng: làm rõ just-in-time, theo dõi WIP và lead time, và chủ động phát hiện nút thắt.
Triết lý xuyên suốt là "just enough, just in time": làm rõ vừa đủ, đúng lúc, song song với phát triển — chứ không chặn trước nó bằng một tài liệu khổng lồ. Thước đo cuối cùng cho một BA Agile giỏi không phải độ dày tài liệu, mà là việc team có giao được giá trị đều đặn và ít hiểu lầm hay không.