title: "BA trong dự án Agile/Scrum: Cách làm việc trong môi trường thay đổi nhanh"
series: "BA 4.0: Từ Phân tích đến Giải pháp"
part: "Phần 4 — Thực thi & Nâng cấp"
order: 11
audience: "Business Analyst (BA) mới vào nghề & đang phát triển"
reading_time: "12 phút"
tags: ["agile", "scrum", "sprint-planning", "backlog-refinement", "user-story", "ba-skills", "reso-case-study"]

BA trong dự án Agile/Scrum: Cách làm việc trong môi trường thay đổi nhanh (Dynamic environment)

Sáng thứ Hai, sprint thứ 5 của dự án Reso. Minh mở Jira, kéo board lên, và thấy một dòng chú thích của Huy để lại từ cuối tuần: "User Story #RES-114 (đặt dịch vụ spa kèm phòng) — Acceptance Criteria chưa rõ trường hợp khách huỷ dịch vụ nhưng giữ phòng. Cần BA confirm trước 10h sáng nay, không thì phải kéo ra khỏi sprint."

Nếu đây là dự án waterfall, đây đã là thảm hoạ: tài liệu yêu cầu (SRS) đã "ký" từ tháng trước, giờ phát sinh câu hỏi coi như lỗi quy trình, phải họp ban điều hành để "xin duyệt thay đổi". Nhưng đây là Reso, chạy Scrum, sprint 2 tuần, và đây không phải là sự cố — đây là một buổi sáng bình thường. Minh trả lời trong 15 phút, đính kèm một bảng nhỏ mô tả 3 nhánh xử lý khi huỷ dịch vụ, Huy đọc, đội dev tiếp tục code. Sprint không bị vỡ.

Bài viết này không nói về Scrum là gì — Minh, Huy và cả đội Reso đã dùng Scrum được hơn một tháng, ai cũng biết standup là gì, sprint là gì. Câu hỏi thật sự là: rốt cuộc BA làm gì trong một mô hình mà mọi thứ được thiết kế để "không ai làm tài liệu đầy đủ trước rồi thôi"? Nếu vai trò "viết yêu cầu rồi bàn giao" (đã nói ở bài 8) chỉ dừng ở đó, BA sẽ biến mất ngay sau sprint đầu tiên. Thực tế Reso cho thấy điều ngược lại: BA không những không biến mất, mà còn là mắt xích giữ cho tốc độ "thay đổi nhanh" của Scrum không biến thành hỗn loạn.

Sự thật cơ bản (First Principle)

Trong môi trường Agile, yêu cầu KHÔNG BAO GIỜ đứng yên. Cố "chốt cứng" toàn bộ yêu cầu ngay từ đầu — kiểu tư duy waterfall "phân tích xong, ký duyệt xong, giờ chỉ còn thực thi" — là chống lại chính bản chất của một dự án như Reso.

Nhìn lại hành trình 10 bài trước: hiểu biết thật về vấn đề của Serene Hotels không hề có sẵn từ ngày đầu. Ở bài 3, khi Minh hỏi sâu bằng kỹ thuật 5 Whys, sự thật về áp lực hoa hồng OTA mới lộ ra — nếu Minh "chốt yêu cầu" ngay từ buổi họp đầu tiên với chị Lan Anh (dựa đúng câu nói gốc "muốn một app để khách đặt phòng online"), Reso đã đi sai hướng suốt từ đầu. Ở bài 6, phạm vi dự án phải điều chỉnh khi phát hiện tích hợp PMS phức tạp hơn dự kiến. Ở bài 10, xung đột giữa các stakeholder (kinh doanh muốn nhiều tính năng, kỹ thuật muốn giữ tiến độ) buộc phải thương lượng lại độ ưu tiên.

Tất cả những thời điểm đó không phải ngoại lệ hiếm gặp — chúng là quy luật. Một dự án phần mềm càng phức tạp, càng nhiều bên liên quan, thì lượng thông tin thật sự cần thiết để xây đúng sản phẩm càng không thể biết hết ngay từ ngày 1. Scrum không "gây ra" sự thay đổi liên tục — Scrum chỉ thừa nhận một sự thật vốn đã tồn tại trong mọi dự án, và thiết kế quy trình (sprint ngắn, nghi thức lặp lại, backlog sống) để hấp thụ sự thay đổi đó thay vì chối bỏ nó.

Hệ quả trực tiếp cho vai trò BA: nếu công việc của BA chỉ là "một tài liệu, một lần, xong việc", BA đang làm việc theo tư duy waterfall trong một khung Agile — và sớm muộn công việc đó sẽ vô dụng, vì tài liệu sẽ lỗi thời trước khi sprint thứ hai kết thúc.

Phân tích

Áp bản chất "yêu cầu luôn động" đó vào Reso, ta thấy ba điểm ma sát cụ thể nếu BA vẫn giữ tư duy "giao tài liệu rồi nghỉ":

1. Backlog không phải kho lưu trữ, mà là dòng chảy. Sau khi Minh viết xong bộ User Story và Acceptance Criteria ở bài 8 (cho các luồng đặt phòng, đặt dịch vụ spa/tour/đưa đón), những story đó không "đóng băng" trong backlog. Khi tình huống bài 6 xảy ra (phát hiện PMS có giới hạn về đồng bộ tồn phòng real-time), ít nhất 3 User Story liên quan đến hiển thị tình trạng phòng phải viết lại Acceptance Criteria. Nếu không có ai liên tục rà soát và cập nhật, đội dev vẫn cắm cúi code theo AC cũ — kết quả là sản phẩm đúng tài liệu nhưng sai thực tế.

2. Sprint Planning là nơi rủi ro hiểu sai bị phát hiện — hoặc bị chôn giấu. Ở buổi Sprint Planning đưa RES-114 (đặt dịch vụ spa kèm phòng) vào sprint, nếu Minh chỉ đọc User Story cho đội nghe rồi để Huy và team tự ước lượng effort, rủi ro hiểu sai state "huỷ dịch vụ nhưng giữ phòng" sẽ nằm im cho đến giữa sprint — đúng thời điểm phát hiện ra thì tốn kém nhất để sửa. Vai trò của BA tại đây không phải là "trình bày yêu cầu" mà là chủ động dò từng góc mơ hồ trong Acceptance Criteria trước khi cả đội cam kết (commit).

3. Sprint Review là kênh phản hồi ngắn nhất tới người quyết định thật — chị Lan Anh. Một trong những rủi ro lớn nhất của dự án B2B là xây đúng theo tài liệu nhưng sai với kỳ vọng thật của sponsor, và chỉ phát hiện ra ở buổi UAT cuối cùng — khi mọi thứ đã quá muộn để sửa rẻ. Với Reso, sau mỗi 2 tuần, Sprint Review là dịp Minh mời chị Lan Anh xem trực tiếp phần đã chạy được (ví dụ: luồng đặt phòng cơ bản ở sprint 3, luồng đặt dịch vụ đi kèm ở sprint 5) và lấy phản hồi ngay — thay vì gói cả rủi ro đó lại chờ đến buổi nghiệm thu cuối dự án.

Nói ngắn gọn: cái làm cho Scrum "an toàn" trước sự thay đổi liên tục không phải là quy trình tự nó, mà là có người liên tục dịch chuyển giữa hai thế giới — thế giới nghiệp vụ của chị Lan Anh (đang thay đổi ưu tiên, đang phát hiện thêm nhu cầu) và thế giới kỹ thuật của Huy (đang cần sự rõ ràng để code đúng). Người đó chính là BA.

Giải pháp

Vai trò của BA trong Scrum không nằm ở một buổi họp duy nhất — nó trải dọc suốt vòng lặp nghi thức (ceremony) của Scrum. Dưới đây là cách áp dụng cụ thể cho từng nghi thức, dùng được cho mọi dự án Agile chứ không riêng Reso:

1. Backlog Refinement (grooming) — liên tục làm rõ và ưu tiên lại

• Đây là công việc "chạy nền" suốt sprint, không phải một sự kiện một lần. Khi có thay đổi phạm vi (như phát hiện giới hạn PMS ở bài 6, hoặc yêu cầu mới từ xung đột stakeholder ở bài 10), BA là người đầu tiên cập nhật lại User Story bị ảnh hưởng — chứ không đợi Product Owner hay Tech Lead nhắc.
• Nguyên tắc: một User Story chỉ được coi là "sẵn sàng" (Definition of Ready) khi Acceptance Criteria đã đủ rõ để đội ước lượng effort mà không cần đoán.
• Với Reso, mỗi lần refinement, Minh mang theo câu hỏi: "Story này còn phản ánh đúng vấn đề thật (giảm phụ thuộc OTA, tăng direct booking) hay đã lạc hướng thành tính năng đẹp nhưng không giải quyết gì?" — đây chính là cách kỹ năng First Principles (bài 2) và Scope Management (bài 6) được áp dụng lặp lại mỗi 2 tuần chứ không chỉ một lần đầu dự án.

2. Sprint Planning — đảm bảo đội hiểu đúng trước khi cam kết

• BA không chỉ đọc User Story cho đội nghe. BA chủ động đặt câu hỏi ngược lại đội: "Nếu khách huỷ dịch vụ spa nhưng vẫn giữ phòng, hệ thống xử lý ra sao?" — chính là tình huống RES-114 ở đầu bài.
• Nếu một Acceptance Criteria không trả lời được câu hỏi biên (edge case) mà đội đặt ra, story đó CHƯA nên vào sprint — kéo nó ra và đưa lại vào backlog refinement, thà trễ một sprint còn hơn đội cam kết trên nền hiểu sai.

3. Daily Standup — nắm vướng mắc thật của đội, không phải chỉ nghe báo cáo

• BA tham dự standup không phải cho có mặt, mà để bắt tín hiệu sớm: khi Huy nói "tôi đang vướng logic tính hoa hồng khi khách đặt qua Reso nhưng thanh toán một phần qua OTA" — đó là dấu hiệu một nghiệp vụ chưa được phân tích đủ sâu, cần BA vào cuộc ngay trong ngày, không đợi đến sprint review mới biết.

4. Sprint Review — thu thập phản hồi thật từ chị Lan Anh mỗi 2 tuần

• BA chuẩn bị trước: những gì demo hôm nay giải quyết vấn đề nghiệp vụ nào (ví dụ: "tính năng đặt dịch vụ kèm phòng giúp khách đặt trực tiếp mà không cần gọi lễ tân — đúng mục tiêu giảm phụ thuộc OTA").
• Ghi nhận phản hồi ngay tại chỗ, phân loại: cái gì là bug (đưa thẳng vào sprint sau), cái gì là thay đổi phạm vi thật sự (đưa qua quy trình Scope Management ở bài 6), cái gì chỉ là ý kiến cá nhân cần cân nhắc thêm.

5. Sprint Retrospective — BA cũng tự nhìn lại, không chỉ đội dev

• Câu hỏi cho chính BA: sprint vừa rồi có Acceptance Criteria nào gây hiểu lầm? Có refinement nào làm quá muộn khiến đội bị động? Đây là vòng lặp cải tiến của chính vai trò BA, không chỉ của quy trình kỹ thuật.

Nguyên tắc bao trùm: BA không "biến mất" sau khi giao tài liệu ở bài 8. Tài liệu (User Story, Acceptance Criteria) là điểm bắt đầu của một cuộc hội thoại kéo dài suốt dự án, không phải điểm kết thúc trách nhiệm.

📎 Actionable Template

BA Sprint Checklist — áp dụng cho mỗi chu kỳ sprint 2 tuần (ví dụ minh hoạ theo sprint 5 của Reso, giai đoạn phát triển luồng đặt dịch vụ spa/tour kèm phòng):

🧠 Tư duy phản biện: Khi cả đội "chạy đúng Scrum" — đủ standup, đủ sprint review, backlog gọn gàng — nhưng sản phẩm cuối cùng vẫn lệch khỏi vấn đề thật của khách hàng, có phải quy trình đang được tuân thủ như một nghi thức hình thức, trong khi câu hỏi cốt lõi ("chị Lan Anh cần Y chứ không chỉ X") đã bị lãng quên đâu đó giữa các sprint?

🔗 Case Study & Bài viết liên quan

Bài này là một chương trong hành trình xuyên suốt của dự án Reso — nơi vai trò BA không dừng lại sau khi tài liệu được viết xong, mà đồng hành qua từng sprint để đảm bảo đội kỹ thuật của Huy luôn hiểu đúng vấn đề thật của chị Lan Anh. Để hiểu rõ hơn cách những thay đổi phạm vi được xử lý trước khi đưa vào backlog, xem lại Quản trị phạm vi (Scope Management); và cách những xung đột giữa các stakeholder được hoá giải trước khi ảnh hưởng đến ưu tiên sprint, xem Quản trị xung đột giữa Stakeholders.

Sprint 5 của Reso rồi cũng sẽ qua, nhưng khối lượng công việc lặp lại mỗi 2 tuần — refine, hỏi, trả lời, tổng hợp phản hồi — là một dạng lao động trí óc có thể được hỗ trợ, tăng tốc, nhưng không thể thay thế hoàn toàn. Câu hỏi đặt ra ở chặng cuối cùng của hành trình này là: giữa núi công việc lặp đi lặp lại đó, đâu là phần AI có thể gánh đỡ cho Minh, và đâu là phần chỉ con người mới làm được?

Bài trước: Quản trị xung đột giữa Stakeholders · Bài tiếp theo: AI-Assisted BA