Vai trò của BA trong quy trình Scrum

Vậy BA ngồi ở đâu, làm gì? Đây là câu hỏi khiến nhiều bạn mới bối rối khi vào dự án Scrum đầu tiên. Bài này trả lời câu hỏi đó.

Bài này giả định bạn đã nắm cơ bản về Scrum. Nếu chưa, đọc bài "Giới thiệu các mô hình phát triển phần mềm: Waterfall, Agile, Scrum" trước.

1. BA ngồi ở đâu trong Scrum Team?

Scrum cố ý chỉ định nghĩa ba trách nhiệm, không liệt kê chức danh. Thực tế BA thường rơi vào một trong ba tình huống:

• BA là một thành viên trong nhóm Developers. Trong Scrum, "Developers" nghĩa là tất cả những ai góp phần tạo ra phần tăng trưởng của Sprint — lập trình viên, tester, designer, và cả BA. Đây là tình huống phổ biến nhất.
• BA hỗ trợ Product Owner. Product Owner bận việc kinh doanh và quyết định ưu tiên; BA đi sâu vào phân tích, làm rõ chi tiết, viết User Story và Acceptance Criteria.
• BA kiêm luôn Product Owner. Hay gặp ở công ty nhỏ hoặc dự án outsourcing, khi khách hàng ở xa và không ai làm PO toàn thời gian. Đây là tình huống khó nhất, vì hai vai này có xung đột lợi ích tự nhiên — sẽ nói ở mục 4.

Điều quan trọng: bạn không cần một chức danh trong Scrum Guide mới được phép làm việc của mình. Đừng chờ ai đó "phân vai" cho bạn. Việc của BA — làm cho yêu cầu rõ ràng để đội xây đúng thứ — luôn cần, dù Scrum có gọi tên nó hay không.

2. BA làm gì trong từng sự kiện Scrum?

Lưu ý: Backlog Refinement không phải một sự kiện chính thức trong Scrum Guide — nó là hoạt động diễn ra liên tục, không có timebox cố định. Nhưng với BA, đây lại là nơi bạn tạo ra nhiều giá trị nhất, nên phần lớn công ty vẫn đặt lịch cố định cho nó (thường 1–2 buổi mỗi Sprint).

3. Công việc cốt lõi: biến mong muốn thành thứ đội có thể xây

Viết User Story và Acceptance Criteria

Đây là sản phẩm chính của BA trong hầu hết đội Scrum. Một User Story mô tả nhu cầu từ góc nhìn người dùng, còn Acceptance Criteria (AC) nói rõ thế nào là làm đúng.

Nói cho chính xác: Scrum không bắt buộc dùng User Story hay Acceptance Criteria. Scrum Guide chỉ nói tới "Product Backlog Item", còn viết nó dưới dạng gì là do đội chọn. User Story phổ biến đến mức nhiều người tưởng là một phần của Scrum, nhưng nó đến từ Extreme Programming.

Ví dụ, thay vì ghi "làm chức năng tìm kiếm nhân viên", hãy viết:

User Story: Là nhân viên phòng HR, tôi muốn tìm nhân viên theo mã số để tra cứu nhanh khi chỉ có mã trên giấy tờ. Acceptance Criteria:

Chú ý dòng cuối. Đó chính là loại chi tiết mà nếu BA không hỏi, sẽ không ai hỏi — và đến lúc demo mới lòi ra.

Acceptance Criteria khác Definition of Done thế nào?

Hai khái niệm này bị nhầm rất nhiều, kể cả ở người đi làm vài năm.

Một hạng mục có thể đạt đủ Acceptance Criteria nhưng vẫn chưa "done" — vì chưa ai review code, hoặc chưa test trên staging. Đó là lý do đội cần cả hai.

Giữ cho backlog luôn có việc "sẵn sàng"

Một trong những cách nhanh nhất để đội mất Sprint là bước vào Planning mà các hạng mục còn mơ hồ. BA có trách nhiệm đi trước đội một bước: khi đội đang làm Sprint này, bạn đã làm rõ xong việc cho Sprint sau.

Trả lời câu hỏi trong lúc Sprint đang chạy

Dev viết code đến giữa chừng và phát hiện một trường hợp chưa ai nghĩ tới — chuyện xảy ra hằng ngày. BA là người đi hỏi cho ra câu trả lời, nhanh, để dev không phải tự đoán rồi làm sai.

4. BA và Product Owner khác nhau ở đâu?

Đây là ranh giới hay bị nhoè nhất, và cũng là nguồn mâu thuẫn phổ biến trong đội.

Cách nhớ đơn giản: PO quyết định cái gì và khi nào, BA làm rõ như thế nào.

Còn Project Manager? Trong Scrum thuần thì không có vai trò này — phần việc lập kế hoạch và theo dõi tiến độ được chia cho cả đội và Scrum Master. Nhưng ở nhiều công ty Việt Nam vẫn có PM song song với Scrum Team, lo tiến độ, ngân sách và báo cáo cho cấp trên. Khoá này có bài riêng về Project Manager ở phần sau.

Khi một người kiêm cả hai vai, hãy tự ý thức mình đang đội mũ nào. Cạm bẫy thường gặp là bạn hiểu rõ chi tiết kỹ thuật đến mức bắt đầu tự quyết ưu tiên theo cái nào dễ làm, thay vì theo cái nào mang lại giá trị lớn nhất.

5. Một Sprint qua con mắt BA

Lấy lại ví dụ Hệ thống Quản lý Hồ sơ Nhân viên, dự án nội bộ của một công ty đang lớn nhanh.

Trước Sprint 1 — BA ngồi với Trưởng phòng HR (đóng vai Product Owner), dựng Product Backlog ban đầu: lưu tên, số điện thoại, email, phòng ban. BA hỏi những câu HR chưa nghĩ tới: một nhân viên có thể thuộc hai phòng ban không? Số điện thoại có bắt buộc không? Nghỉ việc rồi thì xoá hay đánh dấu?

Sprint 1 (2 tuần) — Đội làm thêm, sửa, xoá thông tin cơ bản. Giữa Sprint, dev hỏi: "Email trùng nhau thì sao?" BA đi hỏi HR trong ngày, trả lời: email phải là duy nhất, trùng thì báo lỗi ngay khi nhập. Chi tiết này được ghi bổ sung vào AC.

Sprint Review — HR dùng thử và nói: "Tốt, nhưng cần thêm ảnh đại diện và thông tin liên lạc khẩn cấp." BA ghi nhận, hỏi thêm cho rõ: ảnh bắt buộc hay không, ai được xem thông tin khẩn cấp — vì đây là dữ liệu nhạy cảm.

Sprint 2 — BA viết hai yêu cầu đó thành User Story có AC đầy đủ. HR với vai trò Product Owner xếp chúng lên đầu Product Backlog. Đến buổi Sprint Planning, Developers mới là người quyết định lấy bao nhiêu việc vào Sprint, dựa trên năng lực thực tế và Sprint Goal đã thống nhất.

Đây là chỗ rất nhiều người mới hiểu sai. BA và Product Owner không "đẩy" việc vào Sprint. PO sắp thứ tự ưu tiên; Developers chọn lấy những gì họ tin là làm xong được. Nếu bạn thấy mình đang ép đội nhận thêm việc giữa Sprint, đó là dấu hiệu vai trò đang bị lệch.

Đội làm xong, demo, HR lại phát sinh yêu cầu tìm kiếm theo mã số.

Thấy nhịp chưa? Vòng lặp của BA trong Scrum là: hỏi cho rõ trước khi đội làm → giải đáp trong lúc đội làm → thu phản hồi sau khi đội xong → biến phản hồi thành yêu cầu rõ ràng cho vòng sau.

6. Những cạm bẫy fresher BA hay mắc

• Chờ được phân việc. Scrum vận hành trên sự chủ động. Không ai đến giao cho bạn một danh sách nhiệm vụ mỗi sáng.
• Viết tài liệu quá dày cho một Sprint hai tuần. Agile không cấm tài liệu, nhưng tài liệu phải phục vụ việc đang làm. Bản đặc tả 40 trang cho một tính năng làm trong 3 ngày là công sức bỏ đi.
• Biến Daily Scrum thành buổi báo cáo cho BA. Đây là buổi của Developers, để họ tự đồng bộ với nhau. Bạn nghe, ghi nhận vướng mắc, rồi đi gỡ.
• Nhận yêu cầu rồi chuyển thẳng cho dev. Nếu bạn chỉ chép lại lời khách hàng, đội không cần bạn. Giá trị của BA nằm ở những câu hỏi bạn đặt ra trước khi chuyển đi.
• Coi thay đổi yêu cầu là thất bại. Trong Scrum, phản hồi dẫn tới thay đổi là dấu hiệu vòng lặp đang chạy đúng. Cái đáng lo là im lặng suốt nhiều Sprint.
• Bỏ qua Definition of Done. Nếu đội chưa thống nhất thế nào là "xong", mọi tranh cãi cuối Sprint đều sẽ quay về đó.
• Tự đưa việc vào Sprint đang chạy. Việc mới thì đưa vào Product Backlog để PO xếp ưu tiên, đừng nhét thẳng cho dev.
• Mặc định mình được dự mọi cuộc họp. Scrum không định nghĩa vị trí BA, nên bạn tham gia sự kiện nào là do thoả thuận với đội, không phải mặc nhiên.

Tóm lại

Scrum không có ô nào ghi chữ "Business Analyst", nhưng công việc phân tích thì luôn cần. BA trong Scrum không còn là người viết một bản đặc tả khổng lồ rồi bàn giao, mà là người đi trước đội một bước để làm rõ, đi cùng đội trong Sprint để gỡ vướng, và đi sau người dùng để nghe phản hồi.

Nếu bạn nắm được nhịp đó, việc không có chức danh trong Scrum Guide chẳng còn quan trọng nữa.

Bài tiếp theo sẽ nói về vai trò của BA trong mô hình Waterfall — một nhịp làm việc rất khác.