Mở đầu — vì sao bài này quan trọng
Khi còn là developer, bạn đã quá quen với Scrum rồi: mỗi sáng đứng nói daily, hai tuần một lần ngồi planning, cuối sprint demo cho khách. Nhưng bạn tham gia với tư cách người bị giao việc — bạn nhận task, ước lượng giờ code, kéo card từ "To Do" sang "Done". Bạn nhìn Scrum qua lăng kính của một mắt xích thực thi.
Khi chuyển sang BA, bạn bước sang phía cấp nguyên liệu cho cả guồng máy đó. Nếu requirements của bạn không sẵn sàng trước sprint, cả team chết đứng. Nếu bạn không làm rõ acceptance criteria, developer code sai, tester không biết test gì. Nếu bạn ngồi im trong sprint review, khách hàng không hiểu mình đang nhận được gì. Vai trò của BA trong Scrum không có tên chính thức trong Scrum Guide — chỉ có Product Owner, Scrum Master và Developers — nhưng trên thực tế tại Việt Nam, BA chính là người gánh phần lớn công việc làm rõ và truyền đạt yêu cầu, thường là cánh tay phải của PO hoặc kiêm luôn PO Proxy.
Bài này không dạy lại Scrum từ A đến Z (bạn đã biết). Bài này tập trung vào những gì BA phải làm trong từng Scrum event — đặc biệt là ba sự kiện cốt lõi: Sprint Planning, Daily Standup và Sprint Review. Đây là nơi lợi thế kỹ thuật của bạn tỏa sáng, nhưng cũng là nơi nhiều dev-turned-BA vấp ngã vì vẫn giữ thói quen "người thực thi".
Khái niệm cốt lõi
BA đứng ở đâu trong Scrum?
Scrum chính thống có ba vai trò: Product Owner (sở hữu backlog, quyết định ưu tiên), Scrum Master (bảo vệ quy trình), và Developers (xây sản phẩm). BA không nằm trong ba vai trò đó. Vậy BA làm gì?
Trong thực tế các công ty phần mềm Việt Nam và các dự án outsourcing, BA thường đảm nhận một trong ba mô hình:
- BA hỗ trợ PO: PO là người business (thường ở phía khách hàng), BA là người "dịch" yêu cầu business thành thứ team kỹ thuật hiểu được — viết user story, vẽ flow, làm rõ chi tiết. Đây là mô hình phổ biến nhất ở outsourcing.
- BA kiêm PO Proxy: Khách hàng ở xa (Nhật, Mỹ, EU), BA tại Việt Nam đại diện tiếng nói của họ, quản lý backlog hằng ngày, ưu tiên trong phạm vi được ủy quyền.
- BA kiêm Scrum Master: ở team nhỏ, một người gánh cả hai vai. Không lý tưởng nhưng rất hay gặp.
Ba Scrum event mà BA phải làm chủ
1. Sprint Planning (2–4 giờ cho sprint 2 tuần). Đây là buổi cả team chọn xem sprint tới sẽ làm gì và làm thế nào. Có một quy tắc kinh nghiệm: planning kéo dài tối đa khoảng 2 giờ cho mỗi tuần sprint — nên sprint 2 tuần thì planning timebox 4 giờ, sprint 1 tuần thì 2 giờ. Buổi này trả lời hai câu: Sprint Goal là gì? và Những story nào vào Sprint Backlog? Vai trò BA: đảm bảo mọi story được chọn đều đã rõ ràng, có acceptance criteria, đã được team hiểu và ước lượng ở vòng refinement trước. BA không được mang story còn mơ hồ vào planning.
2. Daily Standup / Daily Scrum (15 phút). Buổi đứng họp nhanh mỗi ngày, kinh điển với ba câu hỏi: Hôm qua tôi làm gì? Hôm nay tôi làm gì? Có gì cản trở (blocker) không? Lưu ý: Scrum Guide bản mới đã bỏ format ba câu hỏi cứng nhắc, nhưng tại Việt Nam ba câu này vẫn rất phổ biến và hữu ích cho team mới. Vai trò BA: lắng nghe blocker liên quan đến requirements — khi dev nói "tôi không rõ màn hình này xử lý lỗi thế nào", đó là tín hiệu bạn phải nhảy vào ngay sau standup, không phải trong standup.
3. Sprint Review (1–2 giờ). Cuối sprint, team demo phần tăng trưởng (increment) cho stakeholder và lấy feedback. Đây không phải buổi nghiệm thu trang trọng, mà là buổi đối thoại để điều chỉnh hướng đi. Vai trò BA: thường là người chủ trì kịch bản demo, kể câu chuyện business đằng sau những gì team đã xây, ghi nhận feedback và biến nó thành backlog item mới.
Ngoài ba event này, Scrum còn có Sprint Retrospective (team nhìn lại cách làm việc) và Backlog Refinement (làm mịn backlog — không phải event chính thức nhưng cực kỳ quan trọng với BA). Bài này tập trung ba event cốt lõi theo đúng phạm vi, nhưng bạn nên nhớ refinement là "sân nhà" thật sự của BA.
Lợi thế đặc biệt của dev-turned-BA trong Scrum
Bạn hiểu velocity thật sự nghĩa là gì, biết tại sao một story 3 điểm có thể đội lên 8 khi đụng vào legacy code. Bạn đọc được khi developer "ậm ừ" trong planning là do chưa hiểu yêu cầu hay do biết trước sẽ có rủi ro kỹ thuật. Bạn nói chuyện ngang hàng với team, và điều đó khiến requirements của bạn được tôn trọng. Đó là vốn quý mà BA thuần business không có.
Tình huống thực tế
Tình huống 1: Sprint Planning đổ vỡ vì backlog chưa "chín" — Tiki
Một team tại một công ty thương mại điện tử lớn ở TP.HCM (giả định theo bối cảnh Tiki) chạy sprint 2 tuần, planning timebox 4 giờ. Tuấn — một BA vừa từ backend developer chuyển sang được 3 tháng — mang vào buổi planning 12 user story cho tính năng "đổi điểm thưởng lấy voucher". Anh tự tin vì đã viết story rất chi tiết, kèm cả gợi ý cách lưu bảng dữ liệu.
Vấn đề: 5 trong 12 story chưa từng được mang ra refinement. Khi team đọc story "Người dùng đổi điểm lấy voucher", lập tức câu hỏi nổ ra: Điểm hết hạn xử lý sao? Đổi rồi hủy đơn thì điểm hoàn lại không? Voucher có giới hạn theo hạng thành viên không? Buổi planning kéo dài quá 4 giờ, team mệt mỏi, cuối cùng chỉ commit được 7 điểm thay vì velocity trung bình 28 điểm. Sprint đó gần như hỏng.
Bài học: Sprint Planning không phải nơi làm rõ requirements lần đầu — nó là nơi xác nhận những gì đã rõ. Vì còn nặng tư duy dev "cứ vào họp rồi bàn", Tuấn đã bỏ qua vòng refinement. Sau lần đó anh áp dụng quy tắc "Definition of Ready": một story chỉ được đưa vào planning nếu đã có acceptance criteria, đã được team thảo luận sơ bộ và ước lượng. Sprint kế tiếp velocity quay lại 26 điểm.
Tình huống 2: BA biến Daily Standup thành buổi "tra khảo tiến độ" — team outsourcing dự án Nhật
Linh chuyển từ frontend developer sang BA tại một công ty outsourcing ở Đà Nẵng, làm dự án cho khách Nhật. Vì kiêm luôn PO Proxy, cô tham gia daily standup mỗi sáng. Nhưng với thói quen của một người từng quản lý task chặt chẽ, Linh biến 15 phút standup thành buổi cô hỏi từng dev: "Task này sao chưa xong? Bao giờ xong? Tại sao chậm?". Standup kéo dài 35–40 phút, không khí căng thẳng, developer bắt đầu giấu blocker vì sợ bị "soi".
Scrum Master góp ý: Daily Scrum là buổi của developer, cho developer để họ tự đồng bộ kế hoạch trong ngày — không phải buổi báo cáo cho quản lý. Linh điều chỉnh: cô chỉ lắng nghe, ghi chú lại các blocker liên quan đến yêu cầu nghiệp vụ (ví dụ "chưa rõ rule tính phí ship cho đơn quốc tế"), và sau standup mới hẹn riêng dev liên quan để làm rõ. Trong vòng hai tuần, standup quay lại đúng 15 phút, và quan trọng hơn, dev chủ động nêu blocker requirements sớm hơn vì không còn sợ bị tra khảo.
Bài học: Trong standup, BA là người lắng nghe để bắt tín hiệu, không phải người chất vấn. Blocker liên quan requirements là vàng — bạn xử lý nó ngay sau standup, biến mình thành người gỡ vướng chứ không phải người tạo áp lực.
Tình huống 3: Sprint Review cứu một tính năng đi sai hướng — startup fintech VN
Tại một startup fintech ở Hà Nội (khoảng 25 người), team xây tính năng "nhắc nợ tự động" cho sản phẩm cho vay tiêu dùng. Phong — BA từ nền mobile developer — chủ trì sprint review cuối sprint 3. Thay vì chỉ để dev bấm demo qua loa, anh chuẩn bị một kịch bản kể chuyện: dựng sẵn một khách hàng giả "anh Hùng vay 10 triệu, trễ hạn 3 ngày", rồi demo trực tiếp luồng hệ thống gửi SMS nhắc nợ.
Khi demo, Giám đốc vận hành — một stakeholder ngồi xem — phát hiện ngay: "Tin nhắn nhắc nợ gửi lúc 9h tối là vi phạm quy định, luật chỉ cho phép nhắc nợ trong giờ hành chính." Đây là một business rule mà không ai trong team kỹ thuật biết. Vì Phong đã dựng kịch bản demo thật thay vì demo trừu tượng, lỗi này lộ ra ngay trong sprint review — chứ không phải sau khi lên production và bị khách hàng khiếu nại. Phong ghi nhận thành một backlog item mới về "khung giờ gửi thông báo", đưa vào sprint kế tiếp.
Bài học: Sprint Review là cơ hội cuối để bắt sai lệch trước khi quá muộn. BA giỏi không để demo trở thành màn "bấm nút cho có" — bạn dựng kịch bản gần với thực tế kinh doanh nhất để stakeholder phản ứng thật. Mỗi feedback là một viên ngọc cho backlog.
Hướng dẫn từng bước
Đây là cách một BA dev-turned vận hành qua một chu kỳ sprint 2 tuần:
Bước 1 — Trước Sprint Planning: làm mịn backlog (refinement). Khoảng giữa sprint trước, dành 1–2 buổi cùng team rà các story cho sprint tới. Mục tiêu: mỗi story đạt "Definition of Ready" — có mô tả rõ, có acceptance criteria, được team hiểu và ước lượng sơ bộ. Đây là nơi 80% công sức BA đổ vào.
Bước 2 — Tại Sprint Planning (timebox 4h cho sprint 2 tuần). Cùng PO trình bày Sprint Goal. Đưa ra các story đã sẵn sàng theo thứ tự ưu tiên. Trả lời câu hỏi làm rõ của developer, nhưng không sa đà thiết kế giải pháp tại chỗ. Để team tự quyết khối lượng commit dựa trên velocity. Chốt Sprint Backlog.
Bước 3 — Mỗi sáng tại Daily Standup (15 phút). Đứng nghe. Bắt các blocker liên quan requirements. Đừng nói dài, đừng chất vấn tiến độ. Ghi chú lại điểm cần làm rõ.
Bước 4 — Ngay sau standup và trong ngày. Hẹn riêng dev/tester để gỡ các điểm mơ hồ. Cập nhật story, bổ sung acceptance criteria nếu cần. Luôn sẵn sàng trả lời câu hỏi yêu cầu — đây là vai trò "người trực tổng đài requirements" của bạn.
Bước 5 — Trước Sprint Review. Chuẩn bị kịch bản demo theo góc nhìn business: dữ liệu mẫu thật, câu chuyện người dùng cụ thể. Quyết định story nào "Done" đủ chuẩn để demo.
Bước 6 — Tại Sprint Review (1–2h). Kể câu chuyện business, để dev demo phần kỹ thuật. Mời stakeholder phản hồi. Ghi nhận mọi feedback thành backlog item mới. Đừng phòng thủ khi bị chê — feedback là mục tiêu của buổi này.
Bước 7 — Sau Retrospective. Lắng nghe team góp ý về cách bạn cấp requirements: story có đủ rõ không, có đến đúng lúc không. Cải tiến cho sprint sau.
Lỗi thường gặp & mẹo
Lỗi 1: Mang story chưa "chín" vào Planning. Như tình huống Tiki ở trên. Mẹo: thiết lập checklist "Definition of Ready" và kiên quyết không đưa story chưa đạt vào planning.
Lỗi 2: Thiết kế giải pháp thay cho developer. Vì bạn từng code, bạn dễ buột miệng "cứ tạo bảng này, gọi API kia". Điều này tước quyền tự chủ kỹ thuật của team và làm bạn quên mất việc của BA là mô tả cái gì và tại sao, không phải làm thế nào. Mẹo: khi định nói cách làm, hãy dừng lại và hỏi "đây có phải việc của mình không?". (Chủ đề này được đào sâu ở bài về solution-jumping — ở đây chỉ nhắc đến trong bối cảnh Scrum event.)
Lỗi 3: Biến standup thành họp báo cáo. Như tình huống dự án Nhật. Mẹo: nhớ standup là của developer. Bạn lắng nghe, không lãnh đạo.
Lỗi 4: Demo kiểu "bấm nút cho có". Demo trừu tượng, không có ngữ cảnh business, khiến stakeholder không phản ứng được. Mẹo: luôn dựng dữ liệu và câu chuyện thật như tình huống fintech.
Lỗi 5: Coi nhẹ refinement vì nó "không phải event chính thức". Đây là sai lầm chí mạng — refinement chính là nơi BA tạo ra giá trị lớn nhất. Bỏ refinement đồng nghĩa dồn mọi rủi ro vào planning. Mẹo: bảo vệ thời gian refinement như bảo vệ thời gian quý nhất của mình.
Mẹo vàng cho dev-turned-BA: Lợi thế kỹ thuật của bạn nguy hiểm nếu lạm dụng. Hãy dùng nó để hiểu nhanh và đặt câu hỏi đúng, không phải để ra lệnh kỹ thuật. Một BA biết code mà biết im đúng lúc sẽ được team yêu quý gấp đôi.
Bài tập thực hành
- Viết Definition of Ready cho team của bạn. Liệt kê 5–7 tiêu chí một user story phải đạt trước khi vào Sprint Planning (ví dụ: có acceptance criteria, đã ước lượng, không phụ thuộc story chưa làm...). Đây là công cụ chống lại Lỗi 1.
- Mô phỏng Sprint Planning. Lấy một tính năng quen thuộc (ví dụ "đặt lại mật khẩu"). Viết Sprint Goal và 4–5 user story kèm acceptance criteria. Tự đặt cho mình 3 câu hỏi mà developer có thể hỏi, và chuẩn bị câu trả lời — nhưng chú ý: trả lời về cái gì, không phải làm thế nào.
- Soạn kịch bản Sprint Review. Cho tính năng ở bài tập 2, viết một kịch bản demo dài khoảng nửa trang: bối cảnh người dùng giả định, dữ liệu mẫu, các bước demo theo góc nhìn business. So sánh với một bản demo "bấm nút cho có" để thấy khác biệt.
- Tự soi thói quen dev. Ghi lại 3 tình huống gần đây bạn (hoặc một dev-turned-BA bạn biết) đã "nhảy vào giải pháp kỹ thuật" thay vì giữ vai BA. Với mỗi tình huống, viết lại cách phản ứng đúng vai trò hơn.
Tóm tắt
BA không có tên trong Scrum Guide, nhưng trên thực địa Việt Nam, BA là người cấp nguyên liệu sống còn cho cả guồng máy Scrum. Ba event cốt lõi định hình công việc của bạn: Sprint Planning (2–4h, nơi xác nhận story đã chín và chốt Sprint Backlog — không phải nơi làm rõ lần đầu), Daily Standup (15 phút, nơi bạn lắng nghe bắt blocker requirements chứ không chất vấn tiến độ), và Sprint Review (1–2h, nơi bạn dựng kịch bản demo thật để stakeholder phản hồi và bắt sai lệch sớm). Ngầm đằng sau là backlog refinement — sân nhà thật sự nơi 80% giá trị BA được tạo ra.
Lợi thế dev của bạn là con dao hai lưỡi: nó giúp bạn hiểu nhanh, nói ngang hàng với team và được tôn trọng; nhưng nếu lạm dụng để ra lệnh kỹ thuật hay tra khảo tiến độ, nó sẽ phá hỏng động lực của team. Người dev-turned-BA giỏi nhất là người biết dùng vốn kỹ thuật để đặt câu hỏi đúng và làm rõ yêu cầu, đồng thời biết lùi lại để team tự chủ phần "làm thế nào". Hãy chuẩn bị requirements trước khi team cần, làm rõ khi team hỏi, và để câu chuyện business dẫn dắt mỗi sprint.