Mở đầu — vì sao bài này quan trọng
Nếu bạn xuất thân từ Finance hoặc Kế toán, có một thứ đã ăn sâu vào máu bạn suốt nhiều năm: chu kỳ đóng sổ (closing cycle). Mỗi cuối tháng, cuối quý, cuối năm, bạn lao vào một guồng quay quen thuộc — thu thập chứng từ, đối chiếu, hạch toán, lập báo cáo, trình ký, phát hành. Mọi thứ có deadline cứng, có quy trình tuần tự, có một "đích đến" rõ ràng là báo cáo tài chính hoàn chỉnh được phát hành đúng hạn (thường là M+5, tức 5 ngày làm việc sau khi kết thúc tháng).
Khi chuyển sang làm BA trong môi trường công nghệ, bạn sẽ va vào một nhịp làm việc hoàn toàn khác: Scrum sprint. Và đây chính là nơi rất nhiều người từ Finance bị "sốc văn hóa". Họ quen với việc lập kế hoạch chi tiết một lần rồi thực thi đến cùng; còn Scrum lại chia nhỏ công việc thành những vòng lặp 2 tuần, liên tục điều chỉnh, chấp nhận thay đổi giữa chừng. Người từ Finance thường thấy Scrum "lộn xộn", "thiếu kế hoạch", "sao cứ thay đổi liên tục thế?".
Tin tốt là: tư duy chu kỳ (cyclical thinking) mà bạn rèn được từ closing cycle thực ra là một lợi thế cực lớn để hiểu Scrum — nếu bạn biết cách ánh xạ (map) đúng. Bài này sẽ giúp bạn làm điều đó: hiểu Agile/Scrum không phải từ con số không, mà từ chính những thứ bạn đã thành thạo. Vai trò của BA trong từng nghi thức (ceremony) của Scrum, và cách bạn — một người ex-Finance — có thể tỏa sáng nhờ kỷ luật quy trình sẵn có.
Khái niệm cốt lõi
Agile và Scrum là gì, nói cho người Finance hiểu
Agile là một triết lý làm việc, không phải một quy trình cụ thể. Tinh thần cốt lõi: thay vì cố làm đúng một bản kế hoạch khổng lồ định sẵn từ đầu (cách làm "thác nước" — Waterfall), ta giao sản phẩm thành từng phần nhỏ, thường xuyên, để học hỏi từ phản hồi thực tế và điều chỉnh.
Hãy hình dung thế này: cách làm Waterfall giống như bạn lập một bản dự toán ngân sách (budget) cả năm rồi khóa cứng, không được đụng tới. Cách làm Agile giống như rolling forecast — dự báo cuốn chiếu — mà nhiều công ty hiện đại đang dùng: bạn cập nhật lại dự báo mỗi tháng dựa trên số liệu thực tế mới nhất. Nếu bạn đã từng làm rolling forecast, bạn đã hiểu được một nửa tinh thần Agile rồi đấy.
Scrum là khung làm việc (framework) cụ thể, phổ biến nhất để hiện thực hóa Agile. Scrum chia công việc thành các sprint — chu kỳ cố định thường dài 1–4 tuần (phổ biến nhất là 2 tuần). Mỗi sprint là một vòng lặp khép kín: lập kế hoạch → làm → giao sản phẩm → nhìn lại để cải tiến.
Bảng ánh xạ: Closing cycle với Scrum sprint
Đây là bảng so sánh mà tôi muốn bạn ghi nhớ. Nó là chìa khóa để não bộ ex-Finance của bạn "click" với Scrum:
| Closing cycle (Kế toán) | Scrum sprint (BA/Tech) |
|---|---|
| Chu kỳ tháng/quý, đóng sổ M+5 | Sprint cố định 2 tuần |
| Lịch đóng sổ (closing calendar) | Sprint calendar / cadence |
| Trial balance → điều chỉnh → final | Increment liên tục được tinh chỉnh |
| Họp kick-off đầu kỳ phân công | Sprint Planning |
| Họp giao ban hằng ngày khi cao điểm | Daily Standup |
| Phát hành báo cáo, trình BGĐ duyệt | Sprint Review (demo) |
| Họp rút kinh nghiệm sau quyết toán năm | Sprint Retrospective |
| Checklist đóng sổ | Definition of Done (DoD) |
| Danh mục bút toán cần xử lý | Product Backlog |
| Bút toán ưu tiên xử lý trước hạn | Sprint Backlog (đã ưu tiên) |
| Audit adjustment phát sinh sau khóa sổ | Change request giữa sprint |
Vai trò của BA trong Scrum
Scrum chính thức chỉ có 3 vai trò: Product Owner (PO), Scrum Master (SM), và Development Team. BA không phải là một vai trò "chính danh" trong Scrum Guide. Vậy BA đứng ở đâu? Thực tế tại Việt Nam, BA thường:
- Hỗ trợ PO quản lý và làm rõ backlog (refine requirement, viết user story, viết acceptance criteria).
- Là cầu nối giữa stakeholder/business và Development Team — đây là điểm mạnh tự nhiên của người Finance vì bạn nói được "ngôn ngữ nghiệp vụ".
- Đôi khi kiêm luôn vai PO ở các công ty nhỏ, hoặc đóng vai "Proxy PO".
Năm "nghi thức" của Scrum và việc BA cần làm
- Sprint Planning (Lập kế hoạch sprint) — đầu mỗi sprint. Cả team chọn các story từ backlog để cam kết hoàn thành trong sprint. BA: đảm bảo các story đã "sẵn sàng" (ready) — đủ rõ ràng, có acceptance criteria, đã giải đáp thắc mắc của dev. Đây giống hệt buổi kick-off đầu kỳ đóng sổ, nơi bạn phân công ai làm phần nào.
- Daily Standup (Họp đứng hằng ngày) — 15 phút mỗi sáng. Mỗi người trả lời: hôm qua làm gì, hôm nay làm gì, có vướng mắc (blocker) gì. BA: lắng nghe để phát hiện sớm các blocker liên quan đến yêu cầu, sẵn sàng giải đáp khi dev hỏi. Hãy nhớ cảm giác họp giao ban 8h sáng những ngày cao điểm đóng sổ — đó chính là daily standup phiên bản kế toán.
- Sprint Review (Demo nghiệm thu) — cuối sprint. Team trình bày phần đã làm cho stakeholder, lấy phản hồi. BA: thường là người dẫn demo hoặc giải thích nghiệp vụ, ghi nhận feedback. Giống buổi trình báo cáo tài chính cho Ban Giám đốc.
- Sprint Retrospective (Họp cải tiến) — cuối sprint, chỉ nội bộ team. Nhìn lại: cái gì tốt, cái gì chưa tốt, cần cải thiện gì. BA tham gia như thành viên team. Giống buổi rút kinh nghiệm sau quyết toán năm.
- Backlog Refinement (Tinh chỉnh backlog) — diễn ra giữa sprint, chuẩn bị cho sprint sau. BA: đây là "sân nhà" của BA — bạn làm rõ yêu cầu, chia nhỏ story, viết acceptance criteria, ước lượng cùng team.
Tình huống thực tế
Tình huống 1: Chị Lan — từ Kế toán tổng hợp tại một công ty sản xuất sang BA tại một startup logistics
Chị Lan, 31 tuổi, làm Kế toán tổng hợp 7 năm tại một công ty sản xuất gỗ ở Bình Dương, quen với chu kỳ đóng sổ M+6. Tháng đầu vào làm BA tại một startup logistics ở TP.HCM (đội ngũ 25 người, làm phần mềm quản lý vận tải), chị stress nặng vì sprint chỉ có 2 tuần. "Sao mới làm chưa xong đã phải demo? Báo cáo của tôi ngày xưa làm 6 ngày mới ra mà còn phải đẹp."
Bước ngoặt đến khi Scrum Master nói với chị một câu: "Sprint không phải để làm xong toàn bộ phần mềm. Sprint là để làm xong một mẩu hoàn chỉnh, chạy được, demo được." Chị Lan liền liên hệ: nó giống như đóng sổ một phân hệ (ví dụ chỉ riêng phần công nợ phải thu) thay vì cả bộ báo cáo. Từ đó chị áp dụng tư duy "đóng sổ từng phân hệ" vào việc chẻ nhỏ story. Trong vòng 3 sprint, chị trở thành người chẻ story rõ ràng nhất team.
Bài học: Đừng cố ép sprint phải "hoàn hảo và đầy đủ" như báo cáo tài chính. Sprint giao "một mẩu chạy được". Tư duy đóng sổ từng phân hệ giúp bạn chẻ nhỏ công việc rất tốt.
Tình huống 2: Anh Tuấn tại một ngân hàng số — khi "audit adjustment" gặp "change request giữa sprint"
Anh Tuấn từng làm kiểm soát tài chính (Financial Controller) tại một ngân hàng, chuyển sang BA cho dự án core banking. Sprint thứ 4, team đang làm tính năng tính lãi tiền gửi. Giữa sprint, phòng Pháp chế gửi yêu cầu khẩn: Thông tư mới của Ngân hàng Nhà nước thay đổi cách làm tròn lãi suất. Team dev nhao nhao: "Đang giữa sprint, không nhận thêm việc!"
Anh Tuấn xử lý điều này cực kỳ điềm tĩnh, vì với dân Finance, "phát sinh điều chỉnh sau khi đã chốt số" là chuyện cơm bữa — đó chính là audit adjustment. Anh đề xuất: ghi nhận yêu cầu vào backlog, đánh giá độ ưu tiên với PO. Nếu cực kỳ khẩn (compliance), có thể đưa vào sprint hiện tại nhưng phải bỏ bớt một story khác ra để giữ nguyên khối lượng cam kết — y hệt nguyên tắc "có điều chỉnh thì phải có bút toán đối ứng, tổng phải cân". Cuối cùng team đẩy một story low-priority sang sprint sau, đưa yêu cầu compliance vào.
Bài học: Scrum không cấm thay đổi — nó chỉ yêu cầu thay đổi phải có kỷ luật. Tư duy "điều chỉnh phải đối ứng, sổ phải cân" của Finance giúp bạn quản lý scope giữa sprint một cách chuyên nghiệp, không để team vỡ cam kết.
Tình huống 3: Đội BA tại một công ty fintech và bài toán "velocity giống như năng suất đóng sổ"
Tại một công ty fintech ví điện tử (giả định, quy mô ~150 người, đội phát triển chia thành 6 squad), ban lãnh đạo muốn dự báo bao giờ tính năng "trả góp" ra mắt. Một BA ex-Finance tên Hùng đề xuất dùng velocity — số story point trung bình team hoàn thành mỗi sprint — để dự báo. Anh giải thích với sếp bằng ngôn ngữ Finance: "Velocity giống như năng suất đóng sổ trung bình. Nếu 3 kỳ vừa rồi team làm trung bình 30 point/sprint, và backlog tính năng còn 120 point, thì cần khoảng 4 sprint, tức 8 tuần." Anh còn cảnh báo: đừng dùng velocity của 1 sprint duy nhất để dự báo, hãy lấy trung bình 3–5 sprint gần nhất — giống như bạn không bao giờ dự báo dòng tiền dựa trên đúng 1 tháng dữ liệu.
Bài học: Các khái niệm đo lường trong Scrum (velocity, burndown chart) rất gần với tư duy phân tích xu hướng (trend) và dự báo (forecast) của Finance. Bạn có lợi thế lớn ở đây — đừng ngại nói chuyện bằng con số.
Hướng dẫn từng bước
Đây là lộ trình giúp bạn — một người ex-Finance — hòa nhập vào nhịp Scrum trong 30 ngày đầu:
Bước 1 — Vẽ bảng ánh xạ của riêng bạn. Lấy bảng so sánh closing cycle với sprint ở trên, viết lại bằng đúng trải nghiệm đóng sổ của bạn. Việc tự tay ánh xạ giúp bạn "neo" kiến thức mới vào kiến thức cũ.
Bước 2 — Quan sát một vòng sprint trọn vẹn trước khi can thiệp. Trong 2 tuần đầu, hãy ngồi yên dự đủ 5 ceremony, ghi chú: ceremony này dài bao lâu, ai chủ trì, mọi người làm gì. Đừng vội "sửa quy trình" — bạn chưa hiểu đủ.
Bước 3 — Học viết user story và acceptance criteria. Đây là sản phẩm chính của BA trong refinement. (Cú pháp Gherkin và use case sẽ học sâu ở bài khác; ở đây bạn chỉ cần biết: story phải đủ rõ để dev không phải đoán.)
Bước 4 — Tham gia Backlog Refinement chủ động. Đây là sân nhà của BA. Mỗi story bạn đưa ra, hãy tự hỏi 3 câu kiểu kế toán: (1) Story này "cân" chưa — input và output đã rõ chưa? (2) Có ngoại lệ (edge case) nào chưa xử lý không? (3) Định nghĩa "xong" (Done) của nó là gì?
Bước 5 — Theo dõi burndown chart và velocity. Cuối mỗi sprint, ghi lại velocity. Sau 3 sprint, bạn đã có dữ liệu để nói chuyện dự báo với stakeholder — một thế mạnh ex-Finance.
Bước 6 — Đóng góp trong Retrospective bằng tư duy cải tiến quy trình. Dân Finance vốn giỏi nhìn ra điểm nghẽn quy trình (process bottleneck). Hãy mang kỹ năng đó vào retro: "Tôi thấy mỗi sprint chúng ta mất 2 ngày chờ làm rõ yêu cầu — giống điểm nghẽn chờ chứng từ khi đóng sổ. Ta có thể refine sớm hơn không?"
Lỗi thường gặp & mẹo
Lỗi 1 — Mang tư duy "kế hoạch cứng" của Waterfall vào Scrum. Nhiều ex-Finance muốn có một bản kế hoạch chi tiết toàn dự án từ đầu rồi khóa cứng. Scrum không hoạt động vậy. Mẹo: hãy nghĩ về Agile như rolling forecast, không phải annual budget khóa cứng.
Lỗi 2 — Coi sprint là "deadline để làm xong mọi thứ". Sprint là để giao một increment chạy được, không phải để hoàn thiện toàn bộ. Mẹo: áp dụng tư duy "đóng sổ từng phân hệ".
Lỗi 3 — Chống lại thay đổi giữa sprint một cách cứng nhắc, hoặc ngược lại, nhận bừa mọi yêu cầu. Mẹo: dùng nguyên tắc "điều chỉnh phải đối ứng" — muốn thêm việc vào sprint thì phải bỏ bớt việc khác ra, qua thương lượng với PO.
Lỗi 4 — Im lặng trong Standup vì nghĩ "tôi không phải dev". BA là thành viên team. Nếu bạn đang vướng làm rõ một yêu cầu, đó là blocker cần nói ra. Mẹo: coi standup như buổi giao ban đóng sổ — ai vướng gì nói nấy để gỡ ngay.
Lỗi 5 — Viết story quá chi tiết như một bản đặc tả 50 trang. Dân Finance quen viết tài liệu dày. Trong Scrum, story nên vừa đủ và bổ sung qua trò chuyện. Mẹo: nhớ nguyên tắc "card, conversation, confirmation" — story là điểm khởi đầu cho hội thoại, không phải hợp đồng pháp lý.
Mẹo vàng: Mỗi khi thấy một khái niệm Scrum khó hiểu, hãy tự hỏi "Trong closing cycle, cái này tương đương với gì?". 90% trường hợp bạn sẽ tìm ra một điểm neo quen thuộc.
Bài tập thực hành
Bài tập 1 — Bảng ánh xạ cá nhân. Viết bảng so sánh closing cycle của chính bạn (mô tả đúng quy trình đóng sổ nơi bạn từng làm: M+mấy, có những bước gì) với 5 ceremony của Scrum. Mục tiêu: ít nhất 8 dòng ánh xạ.
Bài tập 2 — Mô phỏng Sprint Planning. Giả sử bạn có backlog 6 story (tự nghĩ cho một app quản lý chi tiêu cá nhân). Velocity team là 20 point. Hãy gán point cho từng story (dùng dãy 1,2,3,5,8) và chọn các story đưa vào sprint sao cho tổng không vượt 20. Giải thích lựa chọn ưu tiên của bạn.
Bài tập 3 — Xử lý change request. Tình huống: đang giữa sprint (đã làm được 5 ngày/10 ngày), PO yêu cầu thêm một tính năng khẩn 8 point. Velocity là 20 và team đã cam kết đủ 20. Viết 1 đoạn ngắn (150 từ) mô tả bạn sẽ thương lượng thế nào, áp dụng nguyên tắc "điều chỉnh phải đối ứng".
Bài tập 4 — Đóng góp Retrospective. Viết 3 quan sát kiểu "process improvement" mà một ex-Finance có thể mang vào buổi retro đầu tiên, dựa trên kinh nghiệm nhìn ra điểm nghẽn quy trình.
Tóm tắt
- Closing cycle và Scrum sprint cùng là tư duy chu kỳ — bạn không học Scrum từ con số không, mà ánh xạ từ nhịp đóng sổ bạn đã thành thạo: cadence cố định, ceremony, definition of done, xử lý điều chỉnh phát sinh.
- Sprint giao một increment chạy được, không phải toàn bộ sản phẩm hoàn hảo — hãy nghĩ "đóng sổ từng phân hệ" thay vì "cả bộ báo cáo".
- BA tỏa sáng trong Backlog Refinement và Sprint Review — nơi bạn làm rõ yêu cầu và nói ngôn ngữ nghiệp vụ, đúng thế mạnh ex-Finance.
- Thay đổi giữa sprint là bình thường nhưng cần kỷ luật — áp dụng nguyên tắc "điều chỉnh phải đối ứng, sổ phải cân" để quản lý scope.
- Velocity và burndown gần với tư duy forecast/trend của Finance — đừng ngại dùng con số để dự báo và giao tiếp với stakeholder.
- Mẹo cốt lõi: với mọi khái niệm Scrum khó, hãy hỏi "trong closing cycle, cái này là gì?" — bạn sẽ luôn tìm được điểm neo.