Mở đầu — vì sao bài này quan trọng
Khi bạn nộp CV cho một vị trí BA fresher tại Việt Nam năm 2026, có một cụm từ gần như chắc chắn xuất hiện trong 8 trên 10 tin tuyển dụng: "Kinh nghiệm làm việc trong môi trường Agile/Scrum là một lợi thế". Nhiều bạn sinh viên đọc xong thì hoang mang, vì Agile nghe rất trừu tượng, còn Scrum thì giống một mớ thuật ngữ tiếng Anh khó nhớ: sprint, backlog, standup, retrospective...
Sự thật là như thế này: Agile/Scrum không phải kiến thức hàn lâm để bạn học thuộc lòng rồi trả bài phỏng vấn. Nó là nhịp làm việc hàng ngày của bạn. Là cách team quyết định tuần này làm gì, họp lúc nào, ai chịu trách nhiệm cái gì. Một BA junior không hiểu Scrum sẽ giống như một cầu thủ ra sân mà không biết luật bóng đá — bạn có thể chạy rất nhiệt tình nhưng chạy sai chỗ, đá vào lúc trọng tài đã thổi còi.
Điều quan trọng hơn: BA là một trong những vai trò chịu tác động trực tiếp nhất từ cách team vận hành Scrum. Bạn viết requirement khi nào? Trước sprint hay trong sprint? Ai duyệt user story của bạn? Khi nào Dev bắt đầu code phần bạn phân tích? Tất cả những câu hỏi đó đều được trả lời bởi khung Scrum. Hiểu Scrum tức là bạn hiểu công việc của chính mình sẽ diễn ra theo lịch trình nào.
Bài này sẽ giúp bạn nắm được khung Scrum một cách thực dụng — không phải để thi chứng chỉ, mà để ngày đầu tiên đi làm bạn biết mình đang đứng ở đâu trong guồng máy và làm gì cho đúng nhịp.
Khái niệm cốt lõi
Agile là tư tưởng, Scrum là cách làm
Trước hết, cần phân biệt hai từ hay bị nhầm lẫn.
Agile là một triết lý làm việc, được đúc kết trong Tuyên ngôn Agile (Agile Manifesto) năm 2001. Nó không phải quy trình cụ thể mà là bộ giá trị: ưu tiên con người và tương tác hơn công cụ; ưu tiên phần mềm chạy được hơn tài liệu dày cộp; ưu tiên hợp tác với khách hàng hơn đàm phán hợp đồng; ưu tiên phản hồi với thay đổi hơn bám cứng kế hoạch. Nói ngắn gọn: làm từng phần nhỏ, giao sớm, lấy phản hồi liên tục, sửa nhanh.
Scrum là một khung làm việc (framework) cụ thể để hiện thực hóa tư tưởng Agile. Scrum nói rõ: team có những vai trò nào, họp những cuộc họp nào, tạo ra những sản phẩm (artifact) nào. Có thể hình dung: Agile là "sống lành mạnh", còn Scrum là một "thực đơn ăn uống cụ thể" để bạn sống lành mạnh. Ngoài Scrum còn có Kanban, XP... nhưng Scrum là phổ biến nhất ở thị trường Việt Nam, nên đây là thứ bạn phải nắm chắc.
Ba vai trò trong Scrum
Scrum chỉ có đúng ba vai trò chính thức. Đây là điều nhiều bạn fresher bất ngờ — vậy BA nằm ở đâu? Ta sẽ nói ở phần sau.
Product Owner (PO): người chịu trách nhiệm về giá trị sản phẩm. PO quyết định làm gì trước, làm gì sau, tính năng nào quan trọng. PO là người sở hữu và sắp xếp thứ tự ưu tiên của Product Backlog. Nếu team giống một nhà bếp, PO là người quyết định thực đơn: hôm nay nấu món gì phục vụ khách.
Scrum Master (SM): người chịu trách nhiệm về quy trình. SM không phải sếp, không giao việc, mà là người phục vụ team — gỡ vướng mắc (impediment), bảo vệ team khỏi bị làm phiền, đảm bảo các cuộc họp Scrum diễn ra đúng và hiệu quả. SM giống người quản lý vận hành nhà bếp: đảm bảo bếp có đủ gas, dao thớt sạch, đầu bếp không bị khách xông vào quấy rầy.
Developers (Dev Team): nhóm những người thực sự tạo ra sản phẩm — lập trình viên, tester, và ở nhiều team là cả designer. Đây là những người "nấu ăn". Trong Scrum hiện đại, Dev Team tự tổ chức, tự quyết định cách làm để đạt được mục tiêu sprint.
Các sự kiện (event) trong Scrum
Scrum vận hành theo chu kỳ gọi là Sprint — thường kéo dài 1 đến 4 tuần (phổ biến nhất ở Việt Nam là 2 tuần). Mỗi sprint là một vòng lặp khép kín, kết thúc là phải có một phần sản phẩm dùng được. Trong mỗi sprint có bốn sự kiện:
1. Sprint Planning (Lập kế hoạch sprint): đầu sprint, cả team ngồi lại chọn ra những việc sẽ làm trong sprint này từ Product Backlog, đưa vào Sprint Backlog. Team trả lời hai câu: sprint này ta hướng tới mục tiêu gì, và ta sẽ làm những gì để đạt được nó.
2. Daily Standup (Họp nhanh hàng ngày): cuộc họp ngắn 15 phút mỗi ngày, thường đứng để tránh dài dòng. Mỗi người trả lời: hôm qua tôi làm gì, hôm nay tôi làm gì, tôi có bị vướng gì không. Đây không phải cuộc họp báo cáo cho sếp mà là cuộc đồng bộ giữa các thành viên.
3. Sprint Review (Rà soát sprint): cuối sprint, team demo phần sản phẩm đã làm được cho PO và các bên liên quan (stakeholder) xem, lấy phản hồi. Đây là lúc "dọn món ăn lên bàn cho khách nếm thử".
4. Sprint Retrospective (Nhìn lại sprint): cũng cuối sprint, nhưng khác Review. Retro không nói về sản phẩm mà nói về cách làm việc: điều gì tốt nên giữ, điều gì dở nên bỏ, cần cải tiến gì cho sprint sau. Đây là cuộc họp giúp team ngày càng khỏe lên.
Các artifact chính
- Product Backlog: danh sách tất cả những gì cần làm cho sản phẩm, sắp xếp theo độ ưu tiên, do PO quản lý. Nó luôn thay đổi, không bao giờ "xong".
- Sprint Backlog: phần việc được chọn ra để làm trong sprint hiện tại.
- Increment: phần sản phẩm hoàn chỉnh, dùng được, tạo ra sau mỗi sprint.
Vậy BA đứng ở đâu?
Đây là câu hỏi quan trọng nhất với bạn. Scrum "chuẩn sách vở" không có vai trò BA. Nhưng trong thực tế tại Việt Nam, BA hiện diện ở khắp nơi trong guồng Scrum, thường theo một trong ba dạng:
- BA hỗ trợ PO: PO bận chuyện chiến lược, còn BA là người "biến ý tưởng của PO thành user story chi tiết", làm rõ backlog, viết acceptance criteria. Đây là mô hình phổ biến nhất cho BA junior.
- BA kiêm PO (Proxy PO): ở nhiều công ty outsourcing Việt Nam, BA đóng luôn vai PO nội bộ, làm cầu nối với khách hàng nước ngoài.
- BA trong Dev Team: BA được coi là một thành viên của Dev Team, chịu trách nhiệm phần phân tích trong mỗi item.
Tình huống thực tế
Tình huống 1: BA fresher và cái bẫy "requirement chưa sẵn sàng"
Minh là BA mới ra trường, vào làm tại một công ty fintech ở TP.HCM, team dùng Scrum sprint 2 tuần. Sprint Planning diễn ra sáng thứ Hai. PO đề xuất đưa vào sprint tính năng "cho phép người dùng đặt lịch nhắc thanh toán hóa đơn". Cả team gật đầu, kéo item vào Sprint Backlog.
Đến thứ Tư, lập trình viên bắt đầu làm và hỏi Minh: "Nhắc trước bao nhiêu ngày? Nhắc qua kênh nào — SMS, email hay push? Nếu người dùng có 5 hóa đơn cùng ngày thì gộp thành 1 thông báo hay gửi 5 cái?". Minh không có câu trả lời, vì lúc Planning chính bạn cũng chưa phân tích kỹ. Kết quả: Dev phải dừng lại chờ, Minh cuống cuồng đi hỏi PO và khách hàng, mất 2 ngày. Item đó không kịp hoàn thành trong sprint.
Bài học: Với BA, có một nguyên tắc vàng gọi là backlog refinement (làm mịn backlog) — bạn phải phân tích và làm rõ item trước khi nó được đưa vào sprint, không phải sau. Requirement đưa vào Planning nên đã đạt trạng thái "Ready" (sẵn sàng để làm). Đây chính là lý do trong Scrum có buổi refinement giữa sprint để BA và team chuẩn bị item cho sprint kế tiếp.
Tình huống 2: Team Shopee-style và giá trị của Daily Standup
Một team phát triển tính năng khuyến mãi cho một sàn thương mại điện tử lớn ở Đông Nam Á có 8 người: 1 PO, 1 SM, 4 Dev, 1 QA và 1 BA tên Lan. Trong 3 ngày liền, tại Daily Standup, một bạn Dev nói: "Hôm nay tôi vẫn đang chờ Lan xác nhận logic tính giảm giá khi khách dùng đồng thời voucher sàn và voucher shop."
Ban đầu Lan nghĩ đó là chuyện nhỏ, để từ từ trả lời. Nhưng vì standup nêu công khai mỗi ngày, SM lập tức nhận ra đây là một impediment (vật cản) đang chặn tiến độ. SM sắp xếp ngay một buổi 30 phút chiều hôm đó giữa Lan, PO và Dev để chốt logic. Vướng mắc được gỡ, item chạy tiếp.
Bài học: Daily Standup không phải hình thức. Với BA junior, đây là nơi bạn nghe được ai đang chờ mình, ai đang vướng vì thiếu thông tin từ mình. Hãy coi standup là "radar" — nếu tên bạn xuất hiện trong phần "tôi bị vướng" của người khác, đó là ưu tiên số một trong ngày của bạn.
Tình huống 3: Sprint Review cứu một hiểu lầm requirement
FPT Software có một team làm dự án cho khách hàng Nhật, sprint 2 tuần. BA tên Tú viết requirement cho màn hình tìm kiếm đơn hàng, trong đó có bộ lọc theo "ngày tạo đơn". Dev làm đúng như tài liệu. Nhưng tại Sprint Review, khi demo cho khách hàng, khách xem xong nói: "Chúng tôi cần lọc theo ngày giao hàng mới đúng nghiệp vụ, ngày tạo đơn gần như vô dụng với đội vận hành."
Vì team làm theo Scrum, phát hiện này đến ngay sau 2 tuần chứ không phải sau 6 tháng khi cả hệ thống đã xong. Chi phí sửa rất nhỏ. Tú ghi nhận, cập nhật backlog, và sprint sau điều chỉnh.
Bài học: Đây chính là sức mạnh của Agile mà bài học đầu đã nói: giao sớm, lấy phản hồi sớm, sửa rẻ. Sprint Review là cơ hội để BA kiểm chứng xem mình đã hiểu đúng nghiệp vụ khách hàng chưa. Đừng ngại khi requirement của mình bị điều chỉnh tại Review — đó là cơ chế hoạt động đúng, không phải thất bại.
Hướng dẫn từng bước
Đây là cách một BA junior tham gia vào một sprint Scrum điển hình, theo dòng thời gian:
Bước 1 — Trước sprint (Refinement): Cùng PO và team làm mịn các item ở đầu Product Backlog. Bạn phân tích, đặt câu hỏi, viết user story và acceptance criteria. Mục tiêu: item đạt trạng thái "Ready". Đây là lúc làm việc nặng nhất của BA.
Bước 2 — Sprint Planning: Cùng team chọn item vào sprint. Nhiệm vụ của bạn là giải thích rõ từng item cho Dev và QA hiểu, trả lời câu hỏi ngay tại chỗ. Nếu một item còn quá nhiều điểm mờ, hãy mạnh dạn nói "item này chưa Ready, không nên đưa vào sprint" — điều đó tốt hơn nhiều so với để nó vỡ giữa chừng.
Bước 3 — Trong sprint (hàng ngày): Dự Daily Standup, lắng nghe xem ai vướng vì thiếu thông tin. Luôn sẵn sàng làm rõ requirement cho Dev, cập nhật tài liệu khi có thay đổi. Đồng thời bắt đầu refinement cho sprint kế tiếp.
Bước 4 — Hỗ trợ kiểm thử: Khi Dev làm xong một phần, phối hợp với QA đối chiếu kết quả với acceptance criteria bạn đã viết. Bạn là người xác nhận "đúng như nghiệp vụ mong muốn".
Bước 5 — Sprint Review: Chuẩn bị và tham gia demo. Ghi nhận phản hồi từ PO và stakeholder, đưa vào backlog để xử lý.
Bước 6 — Retrospective: Đóng góp thẳng thắn về cách làm việc. Ví dụ: "Sprint này em thấy requirement hay bị hỏi lại giữa sprint, có lẽ ta nên refinement sớm hơn". BA cũng cần cải tiến chính mình.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Scrum Master là sếp. SM không giao việc cho bạn và không phải người bạn "báo cáo". SM phục vụ team. Sếp trực tiếp về chuyên môn của bạn thường là BA Lead hoặc PO. Hiểu sai điều này khiến bạn ứng xử lệch trong team.
Lỗi 2 — Viết requirement kiểu "thác nước" trong môi trường Agile. Nhiều bạn fresher cố viết một tài liệu khổng lồ, hoàn hảo 100% ngay từ đầu rồi mới bàn giao. Trong Scrum, bạn viết vừa đủ cho từng item, giao dần theo sprint, chấp nhận rằng nó sẽ được tinh chỉnh. Đừng cầu toàn đến mức làm chậm cả team.
Lỗi 3 — Coi thường Daily Standup, nói lan man. Standup 15 phút. Đừng biến nó thành buổi giải quyết vấn đề chi tiết. Nếu có việc cần bàn sâu, hãy nói "cái này em xin đặt một buổi riêng sau standup" (kỹ thuật gọi là parking lot).
Lỗi 4 — Ôm việc chờ đến Review mới lộ ra. Nếu bạn kẹt requirement, hãy nêu ngay tại standup, đừng giấu. Vấn đề càng để lâu càng đắt.
Mẹo về Definition of Ready và Definition of Done: Hãy hỏi team hai định nghĩa này ngay tuần đầu đi làm. DoR cho bạn biết một item cần đạt gì để được đưa vào sprint — đây là "chuẩn đầu ra" cho công việc của BA. DoD cho biết khi nào một item được coi là hoàn thành. Nắm hai thứ này, bạn sẽ biết chính xác kỳ vọng đặt lên mình.
Mẹo về velocity: Velocity là lượng công việc trung bình team hoàn thành mỗi sprint. BA junior không cần tính, nhưng hiểu khái niệm này giúp bạn biết vì sao không thể "nhồi" vô hạn item vào một sprint.
Bài tập thực hành
- Vẽ vòng đời một sprint 2 tuần. Vẽ một timeline từ thứ Hai tuần 1 đến thứ Sáu tuần 2. Đặt bốn sự kiện Scrum vào đúng vị trí. Sau đó, ở mỗi ngày, ghi chú BA đang làm gì. Mục tiêu: hình dung công việc BA trải đều cả sprint chứ không dồn vào một điểm.
- Phân vai trong tình huống. Đọc lại Tình huống 2 (team thương mại điện tử). Liệt kê: nếu bạn là SM, bạn sẽ làm gì khi nghe Dev báo chờ Lan? Nếu bạn là Lan, bạn nên phản ứng thế nào? So sánh với cách xử lý trong bài.
- Tự viết Definition of Ready. Giả sử bạn là BA cho tính năng "đăng ký tài khoản bằng số điện thoại". Viết ra 5 tiêu chí mà một user story phải đạt để bạn coi là "Ready" đưa vào sprint (gợi ý: có acceptance criteria rõ, đã xác định luồng lỗi, đã thống nhất với PO về phạm vi...).
- Chuẩn bị câu trả lời phỏng vấn. Viết một đoạn 4–5 câu trả lời cho câu hỏi phỏng vấn kinh điển: "Em hiểu vai trò của BA trong một team Scrum như thế nào?". Dùng đúng thuật ngữ đã học: refinement, backlog, sprint, acceptance criteria.
Tóm tắt
Agile là triết lý "làm nhỏ, giao sớm, sửa nhanh"; Scrum là khung cụ thể để thực hiện triết lý đó. Scrum có ba vai trò (Product Owner, Scrum Master, Developers), bốn sự kiện (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective) và các artifact chính (Product Backlog, Sprint Backlog, Increment), tất cả xoay quanh chu kỳ Sprint thường kéo dài 2 tuần.
BA không phải một vai trò chính thức trong Scrum, nhưng lại là mắt xích cực kỳ quan trọng: bạn làm mịn backlog trước sprint, giải thích requirement tại Planning, gỡ vướng cho Dev hàng ngày, hỗ trợ kiểm thử, và kiểm chứng nghiệp vụ tại Review. Nguyên tắc sống còn của BA junior trong Scrum là: chuẩn bị requirement đạt trạng thái Ready trước khi item vào sprint, và đừng giấu vướng mắc — nêu ngay tại standup.
Nắm chắc bài này, bạn không chỉ trả lời trơn tru câu hỏi "em có kinh nghiệm Agile không" mà quan trọng hơn, ngày đầu đi làm bạn sẽ hòa vào nhịp của team một cách tự tin, biết rõ mình phải làm gì và làm vào lúc nào.