Mở đầu — vì sao bài này quan trọng
Nếu bạn đến từ Marketing, có một "cú sốc văn hóa" gần như chắc chắn sẽ xảy ra trong tuần đầu tiên bạn ngồi vào ghế BA: nhịp làm việc hoàn toàn khác. Trong Marketing, bạn quen với một chiến dịch (campaign) kéo dài 3–6 tháng, có ngày khởi động lớn, có ngân sách được duyệt một lần, và kết quả được đánh giá khi cả campaign kết thúc. Sang môi trường phát triển sản phẩm theo Agile, mọi thứ bị "chặt nhỏ" ra thành những chu kỳ 2 tuần gọi là sprint, sản phẩm được giao liên tục, và kế hoạch có thể thay đổi mỗi hai tuần một lần.
Rất nhiều marketer chuyển sang BA bị "đuối" không phải vì thiếu kiến thức nghiệp vụ, mà vì không hiểu nhịp đập của Agile — không biết mình phải làm gì trong từng nghi thức (ceremony), không biết khi nào requirement của mình "đủ chín" để đưa vào sprint, và lúng túng khi product owner liên tục đổi thứ tự ưu tiên.
Bài này không dạy lại lý thuyết Scrum hàn lâm (bạn sẽ học sâu hơn ở Bài 29). Mục tiêu của Bài 9 là giúp bạn — một người có gốc Marketing — dịch tư duy chiến dịch sang tư duy sprint, hiểu rõ vai trò cụ thể của BA trong từng nghi thức Agile, và làm việc trơn tru với đội phát triển ngay từ những sprint đầu tiên.
Khái niệm cốt lõi
Tư duy chiến dịch vs tư duy sprint
Điểm khác biệt lớn nhất bạn cần nội hóa là: Marketing vận hành theo mô hình "big bang" (dồn lực cho một thời điểm ra mắt lớn), còn Agile vận hành theo mô hình "incremental" (giao từng phần nhỏ, liên tục, có thể dùng được ngay).
Bảng so sánh dưới đây là tấm bản đồ chuyển đổi tư duy:
| Marketing (campaign) | Agile BA (sprint) |
|---|---|
| Chu kỳ 3–6 tháng | Sprint 1–2 tuần |
| Kế hoạch cố định từ đầu (lock plan) | Kế hoạch điều chỉnh mỗi sprint |
| Đo kết quả khi campaign kết thúc | Đo kết quả cuối mỗi sprint (demo) |
| Ngân sách duyệt một lần | Ưu tiên (priority) xét lại liên tục |
| Creative brief gửi agency | User story gửi dev team |
| Báo cáo tổng kết cuối kỳ | Retrospective sau mỗi sprint |
| "Launch day" là đỉnh điểm | Giao hàng đều đặn, không có đỉnh duy nhất |
Scrum nói gọn cho người Marketing
Scrum là khung làm việc Agile phổ biến nhất ở các công ty công nghệ Việt Nam (FPT Software, VNG, MoMo, Tiki...). Ba "trụ cột" bạn cần nhớ:
- Vai trò (roles): Product Owner (PO) — người quyết định "làm gì" và thứ tự ưu tiên; Scrum Master (SM) — người gỡ vướng mắc, bảo vệ quy trình; Development Team — dev, QA, designer. BA thường không phải là một role chính thức trong Scrum, mà đứng giữa, hỗ trợ PO làm rõ requirement và hỗ trợ dev hiểu đúng yêu cầu.
- Tạo phẩm (artifacts): Product Backlog (danh sách tất cả việc cần làm, do PO quản lý), Sprint Backlog (phần việc team cam kết làm trong sprint này), Increment (phần sản phẩm hoàn chỉnh giao cuối sprint).
- Nghi thức (ceremonies): Sprint Planning, Daily Standup, Sprint Review/Demo, Sprint Retrospective — và "việc làm nền" liên tục gọi là Backlog Refinement.
BA làm gì trong từng nghi thức?
Đây là phần quan trọng nhất, vì câu hỏi muôn thuở của BA mới là "đến cuộc họp này tôi làm gì?".
- Backlog Refinement (thường giữa sprint): Đây là sân nhà của BA. Bạn làm rõ user story, bổ sung acceptance criteria, trả lời câu hỏi nghiệp vụ của dev, tách story lớn thành story nhỏ. So sánh dễ hiểu: giống lúc bạn brief chi tiết cho agency trước khi họ sản xuất.
- Sprint Planning (đầu sprint): BA trình bày các story đã "sẵn sàng", giải thích bối cảnh nghiệp vụ để team ước lượng (estimate) và cam kết khối lượng. Bạn không quyết định team làm bao nhiêu — team tự quyết — nhưng bạn cung cấp đủ thông tin để họ quyết đúng.
- Daily Standup (15 phút mỗi ngày): BA cập nhật nhanh, và quan trọng hơn là lắng nghe để phát hiện chỗ dev đang vướng vì requirement chưa rõ, rồi xử lý ngay sau buổi họp.
- Sprint Review/Demo (cuối sprint): BA giúp xác nhận tính năng làm ra có khớp acceptance criteria không, ghi nhận phản hồi của stakeholder.
- Retrospective (cuối sprint): BA tham gia cải tiến quy trình — ví dụ "lần sau story cần có sẵn mockup trước khi vào sprint".
"Definition of Ready" và "Definition of Done"
Hai khái niệm này là cứu cánh cho BA. Definition of Ready (DoR) là checklist để biết một story đã "đủ chín" để đưa vào sprint hay chưa (đã có acceptance criteria? đã có mockup? đã rõ business rule?). Definition of Done (DoD) là checklist để biết story đã thực sự "xong" (đã code? đã test? đã được PO chấp nhận?). Marketer hay nhầm "đã viết xong yêu cầu" là "xong" — không phải, "xong" phải đi qua cả vòng kiểm thử.
Tình huống thực tế
Tình huống 1 — Marketer mang tư duy "lock plan" vào sprint (Tiki)
Lan, trước đây là Campaign Manager tại một sàn TMĐT, chuyển sang làm BA cho đội Khuyến mãi tại Tiki. Sprint đầu tiên, Lan viết một tài liệu requirement dày 18 trang mô tả toàn bộ tính năng "Voucher cá nhân hóa" cho 3 tháng tới, rồi đưa hết vào Sprint Planning với kỳ vọng team "chốt kế hoạch một lần cho xong" giống cách cô từng lock plan campaign.
Kết quả: team chỉ làm được khoảng 15% khối lượng đó trong sprint 2 tuần. Tệ hơn, sang sprint sau, PO nhận phản hồi từ phòng kinh doanh và muốn đổi luật áp dụng voucher — khiến 10 trang tài liệu của Lan thành lỗi thời.
Bài học: Trong Agile, bạn không cần (và không nên) đặc tả mọi thứ ngay từ đầu. Lan học cách chỉ làm chi tiết (detail) cho những story sắp vào 1–2 sprint tới, còn phần xa hơn chỉ giữ ở dạng "epic" thô. Đây gọi là progressive elaboration — làm rõ dần theo thời gian. Tài liệu 18 trang sau đó được tách thành các user story nhỏ, mỗi story vừa với một sprint.
Tình huống 2 — Đo lường theo nhịp sprint thay vì chờ "launch day" (MoMo, giả định hợp lý)
Tại một fintech kiểu MoMo, Hùng — cựu Growth Marketer — phụ trách BA cho tính năng "Chia hóa đơn" (split bill). Theo phản xạ Marketing, Hùng muốn giữ kín tính năng, hoàn thiện đầy đủ trong 3 tháng rồi mới tung ra một "launch day" hoành tráng cùng chiến dịch truyền thông.
Scrum Master gợi ý cách khác: chia thành các increment. Sprint 1 chỉ làm chức năng chia đều hóa đơn cho 2 người và bật cho 5% người dùng. Số liệu thu được: tỉ lệ hoàn tất giao dịch split bill chỉ đạt 38% vì bước nhập tên người nhận quá rườm rà. Nhờ phát hiện sớm sau 2 tuần thay vì sau 3 tháng, đội kịp đơn giản hóa luồng nhập liệu ở sprint 2, đẩy tỉ lệ hoàn tất lên 71% trước khi mở rộng ra toàn bộ người dùng.
Bài học: Tư duy "release theo increment + đo sớm" của Agile chính là phiên bản nâng cao của A/B testing mà marketer vốn quen. Giao nhỏ, đo nhanh, học liền, sửa kịp — rủi ro thấp hơn nhiều so với dồn hết vào một ngày ra mắt.
Tình huống 3 — Story không "Ready", dev đứng hình giữa sprint (FPT Software)
Tại một dự án outsourcing ở FPT Software, BA mới đưa story "Người dùng đăng nhập bằng số điện thoại" vào sprint mà thiếu quy định: OTP có hiệu lực bao lâu? Nhập sai mấy lần thì khóa? Số đã đăng ký rồi thì xử lý sao? Giữa sprint, dev liên tục gửi câu hỏi, BA phải chạy đi hỏi PO, mỗi lần chờ trả lời mất nửa ngày. Story bị kéo dài, trượt sang sprint sau (gọi là "spillover").
Trong buổi Retrospective, team thống nhất áp dụng Definition of Ready chặt hơn: mọi story trước khi vào Sprint Planning bắt buộc phải có acceptance criteria và các business rule chính được làm rõ trong buổi Backlog Refinement.
Bài học: Công việc thật của BA trong Agile diễn ra trước sprint, ở khâu refinement, chứ không phải vá lỗi giữa sprint. Một story "Ready" tốt giúp cả team chạy mượt.
Hướng dẫn từng bước
Đây là quy trình thực hành để bạn — BA gốc Marketing — hòa nhịp với một sprint điển hình:
- Trước sprint — chuẩn bị backlog: Cùng PO rà soát Product Backlog, chọn các story sắp tới. Với mỗi story, viết đủ: mô tả ngắn, acceptance criteria, business rule, và đính kèm mockup nếu cần. Đây là lúc bạn dùng kỹ năng "viết brief" từ Marketing, nhưng dưới định dạng user story.
- Backlog Refinement — làm story "chín": Trình bày story với team, để dev và QA đặt câu hỏi. Bất kỳ chỗ nào còn mơ hồ, ghi lại và làm rõ. Áp checklist Definition of Ready — chỉ những story qua được mới đủ điều kiện vào sprint.
- Sprint Planning — bàn giao cho team: Giải thích bối cảnh nghiệp vụ, để team ước lượng và tự cam kết khối lượng. Đừng ép team nhận quá tải; tốc độ ổn định (velocity) quan trọng hơn lời hứa hão.
- Trong sprint — hỗ trợ và bảo vệ phạm vi: Mỗi ngày dự standup để bắt sớm vướng mắc. Trả lời câu hỏi dev nhanh nhất có thể. Quan trọng: giữ phạm vi sprint ổn định — nếu có yêu cầu mới phát sinh, đưa nó vào backlog cho sprint sau, đừng nhét vào sprint đang chạy (chống "scope creep").
- Sprint Review/Demo — nghiệm thu: Đối chiếu tính năng với acceptance criteria, xác nhận đạt Definition of Done, ghi nhận phản hồi stakeholder thành các story mới.
- Retrospective — cải tiến: Đóng góp ít nhất một đề xuất cải thiện cách làm việc của BA trong sprint tới.
Lỗi thường gặp & mẹo
- Lỗi: Mang tư duy "big bang launch". Cố hoàn thiện 100% rồi mới ra mắt. Mẹo: Tập nghĩ theo increment — "phiên bản nhỏ nhất nào có thể giao và học được điều gì đó?".
- Lỗi: Đặc tả thừa, viết tài liệu khổng lồ ngay từ sprint 1. Mẹo: Áp dụng progressive elaboration — chỉ chi tiết hóa story cho 1–2 sprint sắp tới.
- Lỗi: Nhét yêu cầu mới vào sprint đang chạy. Marketer quen "linh hoạt" nên dễ chiều thay đổi tức thì. Mẹo: Tôn trọng cam kết sprint; thay đổi đưa vào backlog cho sprint sau, để PO xếp ưu tiên.
- Lỗi: Coi "viết xong requirement" là "xong". Mẹo: Luôn bám Definition of Done — chỉ "xong" khi đã code, test và được chấp nhận.
- Lỗi: Im lặng trong standup vì nghĩ "đây là việc của dev". Mẹo: Standup là radar phát hiện sớm requirement mơ hồ; hãy lắng nghe chủ động.
- Mẹo vàng: Dùng chính kỹ năng đo lường của Marketing để theo dõi sức khỏe sprint — velocity (tốc độ team) giống như theo dõi reach/conversion theo thời gian; burndown chart giống biểu đồ tiêu ngân sách campaign.
Bài tập thực hành
- Dịch tư duy: Lấy một campaign Marketing bạn từng làm và mô tả nó như thể chạy theo Agile: epic là gì, có thể chia thành những increment 2 tuần nào, mỗi increment đo chỉ số gì để "học sớm"?
- Viết Definition of Ready: Soạn một checklist DoR gồm 5–6 mục cho đội của bạn (gợi ý: có acceptance criteria, có mockup, business rule đã rõ, đã được dev/QA xem qua...).
- Mô phỏng refinement: Lấy story "Người dùng đặt lại mật khẩu qua email" và liệt kê ít nhất 6 câu hỏi nghiệp vụ cần làm rõ trước khi story đủ "Ready".
- Phân tích tình huống: Đọc lại Tình huống 1 (Lan ở Tiki). Nếu là bạn, bạn sẽ tách tài liệu 18 trang thành những user story nào cho 2 sprint đầu? Viết ra 4–5 story.
Tóm tắt
Bước chuyển khó nhất từ Marketing sang BA trong môi trường Agile không nằm ở kiến thức nghiệp vụ mà ở nhịp làm việc: từ chu kỳ campaign 3–6 tháng sang sprint 2 tuần, từ "lock plan" sang "điều chỉnh liên tục", từ "big bang launch" sang "giao tăng dần và đo sớm". Tin vui là tư duy build–measure–learn của Agile chính là họ hàng của A/B testing mà bạn đã thành thạo.
Hãy nhớ ba điều cốt lõi: (1) công việc thật của BA diễn ra trước sprint ở khâu Backlog Refinement; (2) đừng đặc tả quá sớm — hãy làm rõ dần theo progressive elaboration; (3) tôn trọng cam kết sprint, dùng Definition of Ready và Definition of Done làm kim chỉ nam. Nắm vững nhịp đập này, bạn sẽ hòa nhập với đội phát triển nhanh hơn rất nhiều marketer khác. Ở Bài 29, bạn sẽ đào sâu hơn nữa vào từng kỹ thuật Scrum dành riêng cho BA.