Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là BA trong một team vừa kết thúc Sprint Review. Mọi người vỗ tay, demo trôi chảy, nhưng ngay sau đó ai cũng nhìn nhau với một câu hỏi: "Sprint tới làm gì đây?" Nếu câu trả lời mơ hồ, hai tuần kế tiếp sẽ trôi qua trong tình trạng lúc thì code dở, lúc thì thiếu yêu cầu, lúc thì dev hỏi BA mà BA cũng chưa rõ. Sprint Planning chính là buổi họp quyết định toàn bộ "số phận" của hai tuần đó.
Với vai trò BA, bạn không phải là người chủ trì Sprint Planning (đó là việc của Scrum Master và Product Owner), nhưng bạn là người nắm chìa khóa quan trọng nhất: sự rõ ràng của từng item trong Sprint Backlog. Khi dev hỏi "Story này nghĩa là gì? Acceptance Criteria ở đâu? Edge case nào cần xử lý?" — người trả lời là bạn. Một buổi Sprint Planning thành công hay thất bại phụ thuộc rất nhiều vào việc BA đã chuẩn bị backlog đủ "chín" hay chưa.
Bài này tập trung riêng vào cách tổ chức và thực thi Sprint Planning trực tiếp trên JIRA — từ timebox, cấu trúc hai phần WHAT và HOW, đến thao tác kéo issue từ Backlog vào Sprint, đặt Sprint Goal, ước lượng story point và commit khối lượng công việc hợp lý. Lưu ý: bài này KHÔNG đi sâu vào Backlog Refinement (đó là Bài 11) hay cách cấu hình Board (Bài 9, 27) — chúng ta giả định backlog đã được refine và board đã sẵn sàng, giờ là lúc lên kế hoạch cho một sprint cụ thể.
Khái niệm cốt lõi
Sprint Planning là gì và ai tham gia
Sprint Planning là buổi họp mở đầu mỗi Sprint, nơi cả team thống nhất: Sprint này sẽ làm gì (Sprint Goal) và sẽ làm như thế nào (kế hoạch thực thi). Theo Scrum Guide, đây là một trong những "events" bắt buộc. Người tham gia gồm: Product Owner (PO) — người mang vào các item ưu tiên cao nhất; Development Team (dev, QA) — người ước lượng và cam kết; Scrum Master — người điều phối; và BA — người làm rõ yêu cầu, đóng vai trò "cầu nối" giữa PO và team kỹ thuật.
Timebox — đừng để họp kéo dài lê thê
Quy tắc kinh điển của Scrum: Sprint Planning được timebox tối đa 1 giờ cho mỗi tuần của Sprint. Nghĩa là:
- Sprint 1 tuần → tối đa 1 giờ planning.
- Sprint 2 tuần → tối đa 2 giờ planning.
- Sprint 4 tuần → tối đa 4 giờ planning.
Cấu trúc hai phần: WHAT và HOW
Một buổi Sprint Planning chuẩn được chia làm hai nửa thời gian:
Part 1 — WHAT (Làm gì): PO trình bày mục tiêu kinh doanh của sprint và các item ưu tiên cao nhất trên đỉnh Product Backlog. Team thảo luận để hiểu giá trị, đặt câu hỏi, và cùng nhau hình thành Sprint Goal — một câu mục tiêu duy nhất tóm gọn "vì sao sprint này tồn tại". BA tham gia tích cực ở đây để làm rõ scope: cái gì nằm trong, cái gì để lại.
Part 2 — HOW (Làm như thế nào): Dev team mổ xẻ từng Story đã chọn, tách thành các Sub-task kỹ thuật, ước lượng, và kiểm tra capacity (sức chứa) của sprint xem có gánh nổi không. BA ở phần này trả lời các câu hỏi chi tiết về nghiệp vụ và Acceptance Criteria.
Với một sprint 2 tuần, tỉ lệ thường là khoảng 1 giờ cho WHAT và 1 giờ cho HOW.
Sprint Goal — linh hồn của sprint
Sprint Goal không phải là danh sách story. Nó là một mục tiêu duy nhất, có thể đo lường được, ví dụ: "Hoàn tất luồng thanh toán qua VNPay để khách hàng có thể đặt hàng end-to-end". Trong JIRA, bạn nhập Sprint Goal vào ô riêng khi start sprint. Lợi ích: khi giữa sprint có việc phát sinh, team nhìn vào Sprint Goal để quyết định ưu tiên — cái gì phục vụ goal thì làm, cái gì không thì gác lại.
Capacity và Velocity — cam kết bao nhiêu là vừa
Velocity là số story point trung bình team hoàn thành mỗi sprint trong vài sprint gần nhất. Capacity là sức chứa thực tế của sprint sắp tới, có tính đến ngày nghỉ, lễ, người vắng. Nguyên tắc: đừng commit vượt velocity. Nếu velocity trung bình 3 sprint gần nhất là 28 điểm, nhưng sprint tới có 2 dev nghỉ lễ Giỗ Tổ mất 2 ngày, bạn nên hạ commit xuống còn khoảng 22-24 điểm. JIRA hiển thị velocity trong Velocity Report của board để bạn tham chiếu.
Tình huống thực tế
Ví dụ 1 — Tiki: Sprint Planning bị "vỡ trận" vì backlog chưa chín
Team thanh toán của một sàn TMĐT kiểu Tiki có sprint 2 tuần, planning timebox 2 giờ. Sprint đầu, PO mang vào 12 story nhưng nhiều story chỉ có tiêu đề kiểu "Tích hợp cổng thanh toán mới", không có Acceptance Criteria. Trong buổi họp, dev liên tục hỏi BA: "Cổng nào? ZaloPay hay Momo? Có hoàn tiền không? Timeout bao lâu?". BA không trả lời được ngay, phải nhắn PO, PO lại hỏi business. Kết quả: 2 giờ trôi qua mà team chỉ commit được 3 story, planning phải dời sang hôm sau.
Diễn giải: Vấn đề không nằm ở buổi planning, mà ở khâu chuẩn bị. Backlog mang vào planning phải đạt "Definition of Ready" — mỗi story có mô tả, Acceptance Criteria, và đã được refine trước.
Bài học: BA phải đảm bảo các item top-of-backlog đã "ready" trước khi planning bắt đầu. Sprint Planning là nơi cam kết, không phải nơi làm rõ yêu cầu lần đầu. Một mẹo: gắn label ready-for-sprint trên JIRA cho những story đã refine xong, và lọc backlog theo label này trước buổi họp.
Ví dụ 2 — Startup fintech ở TP.HCM: Sprint Goal cứu cả sprint
Một startup fintech 15 người ở Quận 1, TP.HCM, team có velocity ổn định 26 điểm/sprint. Trước Sprint Planning, BA cùng PO đã refine backlog và xác định Sprint Goal: "Khách hàng có thể đăng ký tài khoản và xác thực eKYC hoàn chỉnh". Team kéo vào 8 story tổng 25 điểm, đặt đúng Sprint Goal đó vào ô goal khi start sprint trong JIRA.
Giữa sprint, sếp bán hàng đột ngột yêu cầu thêm tính năng "mời bạn nhận thưởng". Thay vì nhận bừa, Scrum Master và BA nhìn vào Sprint Goal: tính năng referral không phục vụ mục tiêu eKYC. Họ đưa nó vào backlog cho sprint sau. Sprint kết thúc đúng hạn, luồng eKYC demo trơn tru.
Diễn giải: Sprint Goal hoạt động như một "tấm khiên" chống lại scope creep giữa sprint. Vì goal rõ ràng và được ghi ngay trên JIRA, ai cũng thấy và dễ đồng thuận khi từ chối việc ngoài luồng.
Bài học: Luôn chốt một Sprint Goal cụ thể và ghi nó vào JIRA. Đây là công cụ quản trị mạnh nhất mà nhiều team Việt bỏ quên.
Ví dụ 3 — Team outsource Đà Nẵng: commit vượt capacity vì quên ngày lễ
Một công ty outsource ở Đà Nẵng làm dự án cho khách Nhật, sprint 2 tuần. Velocity trung bình 30 điểm. Trong Sprint Planning, team hào hứng kéo vào 32 điểm "vì sprint trước làm tốt". Nhưng họ quên rằng sprint này rơi đúng dịp lễ 30/4 - 1/5, mất 2 ngày làm việc, và 1 QA xin nghỉ phép 3 ngày.
Kết quả: cuối sprint chỉ hoàn thành 21 điểm, 3 story dang dở phải carry-over. Burndown chart trên JIRA đi ngang suốt nửa sau sprint, khách Nhật phàn nàn về việc "cam kết mà không giữ lời".
Diễn giải: Velocity là tham chiếu, nhưng capacity thực tế của từng sprint mới là con số quyết định. Phải trừ đi ngày nghỉ, lễ, và người vắng.
Bài học: Trước khi commit, tính capacity thật: (số dev × số ngày làm việc thực) − ngày nghỉ phép − ngày lễ. Ở Việt Nam, hãy đặc biệt cẩn thận với các kỳ nghỉ Tết, Giỗ Tổ, 30/4, 2/9 — chúng có thể "ăn" cả tuần làm việc.
Hướng dẫn từng bước
Dưới đây là quy trình thực thi Sprint Planning trực tiếp trên JIRA (giả định bạn dùng Scrum board, backlog đã refine):
Bước 1 — Chuẩn bị trước buổi họp (BA làm trước 1 ngày). Mở Backlog view của board. Lọc các story có label ready-for-sprint. Kiểm tra mỗi story top-backlog có đủ: mô tả, Acceptance Criteria, story point ước lượng. Mở Velocity Report để xem velocity 3 sprint gần nhất.
Bước 2 — Tạo Sprint mới. Trong Backlog view, bấm nút Create Sprint ở đầu danh sách. JIRA tạo một khung sprint trống phía trên backlog. Đặt tên rõ ràng, ví dụ "Sprint 14 — eKYC".
Bước 3 — Part 1 (WHAT): PO trình bày và chốt Sprint Goal. PO giới thiệu các item ưu tiên cao nhất. Team thảo luận giá trị. Cùng nhau viết ra một câu Sprint Goal. Ghi tạm vào Confluence hoặc note để lát nữa dán vào JIRA.
Bước 4 — Tính capacity. Cùng team liệt kê ngày làm việc thực của sprint, trừ ngày nghỉ/lễ. Đối chiếu với velocity để ra con số story point mục tiêu (ví dụ velocity 28, capacity giảm 15% → mục tiêu ~24 điểm).
Bước 5 — Kéo story vào Sprint (Drag & Drop). Từ Backlog, kéo từng story từ trên xuống (ưu tiên cao nhất trước) thả vào khung Sprint vừa tạo. JIRA hiển thị tổng story point của sprint ở góc khung sprint, cập nhật real-time. Kéo cho đến khi gần chạm con số mục tiêu thì dừng.
Bước 6 — Part 2 (HOW): tách Sub-task và rà soát chi tiết. Mở từng story, dev tách thành các Sub-task kỹ thuật (FE, BE, test...). BA trả lời các câu hỏi nghiệp vụ và đảm bảo Acceptance Criteria rõ. Nếu phát hiện story quá lớn, tách (split) ngay trên backlog.
Bước 7 — Gán người (Assignee) sơ bộ. Có thể gán assignee cho story/sub-task để thấy tải công việc phân bổ. Nhiều team để dev tự nhận trong Daily, nhưng gán sơ bộ giúp phát hiện ai đang quá tải.
Bước 8 — Start Sprint. Bấm Start Sprint. JIRA mở hộp thoại: nhập Sprint name, Sprint goal (dán câu goal ở Bước 3 vào đây), Start date và End date (duration). Bấm Start. Từ giờ board chuyển sang chế độ active sprint, burndown chart bắt đầu được theo dõi.
Bước 9 — Đồng bộ lên Confluence (tùy chọn). Tạo trang "Sprint 14 Planning Notes" trên Confluence, dán link sprint JIRA, Sprint Goal, danh sách story commit và capacity. Việc này giúp team distributed và stakeholder nắm thông tin.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi Sprint Planning là buổi refine. Nhiều team Việt dùng planning để làm rõ yêu cầu lần đầu, khiến họp kéo dài và mệt mỏi. Mẹo: tách hẳn Backlog Refinement thành buổi riêng giữa sprint trước; planning chỉ để chốt và cam kết.
Lỗi 2 — Không đặt Sprint Goal. Bỏ trống ô goal khi start sprint là sai lầm phổ biến. Mẹo: bắt buộc mỗi sprint có một câu goal duy nhất, ghi vào JIRA; nếu không nghĩ ra goal, có thể backlog đang là một mớ việc rời rạc không có chủ đề.
Lỗi 3 — Commit theo velocity mà quên capacity. Như ví dụ Đà Nẵng, quên ngày lễ dẫn đến over-commit. Mẹo: luôn dựng một bảng capacity nhỏ (người × ngày làm thực) trước khi kéo story.
Lỗi 4 — Kéo quá nhiều story "để dự phòng". Một số team nhồi thêm story "nếu rảnh thì làm". Điều này làm burndown nhiễu và team mất tập trung. Mẹo: commit đúng sức; nếu xong sớm, kéo thêm từ backlog sau (pull when ready).
Lỗi 5 — Bỏ qua dependency giữa các story. Kéo story B vào sprint nhưng B phụ thuộc story A chưa làm. Mẹo: dùng issue link "is blocked by" để hiện dependency; rà soát trước khi commit (chi tiết về linking ở Bài 39).
Mẹo vàng cho BA: Trước mỗi planning, gửi trước cho team một bản tóm tắt các story dự kiến kèm Acceptance Criteria qua Confluence hoặc Slack. Khi vào họp, mọi người đã đọc trước, buổi planning chỉ còn việc xác nhận và cam kết — nhanh gọn, đúng timebox.
Bài tập thực hành
- Tính capacity: Team bạn có 4 dev và 1 QA, sprint 2 tuần (10 ngày làm việc). Sprint tới có lễ 2/9 nghỉ 1 ngày, 1 dev nghỉ phép 2 ngày. Velocity trung bình 30 điểm. Hãy tính capacity còn lại theo % và đề xuất con số story point nên commit.
- Thực hành trên JIRA: Tạo một board Scrum thử nghiệm, thêm 8 story với story point bất kỳ (tổng ~35 điểm). Tạo một Sprint mới, kéo các story sao cho tổng gần con số bạn tính ở bài 1, đặt một Sprint Goal cụ thể, rồi Start Sprint với duration 2 tuần.
- Viết Sprint Goal: Cho tình huống "team cần ra mắt tính năng đặt lịch hẹn online cho phòng khám", hãy viết một câu Sprint Goal duy nhất, đo lường được, không phải là danh sách story.
- Phân tích lỗi: Đọc lại Ví dụ 1 (Tiki). Liệt kê 3 hành động cụ thể mà BA có thể làm trước buổi planning để tránh tình trạng vỡ trận đó.
Tóm tắt
Sprint Planning là buổi họp mở màn mỗi sprint, quyết định team sẽ làm gì và làm như thế nào. Quy tắc timebox: tối đa 1 giờ cho mỗi tuần của sprint (sprint 2 tuần → 2 giờ). Buổi họp chia hai phần: WHAT — PO trình bày và team chốt Sprint Goal; HOW — dev tách sub-task, ước lượng và kiểm tra capacity.
Vai trò BA tuy không chủ trì nhưng cực kỳ quan trọng: đảm bảo backlog đã "ready" với Acceptance Criteria đầy đủ trước buổi họp, làm rõ nghiệp vụ trong phần HOW, và giúp team không over-commit. Trên JIRA, quy trình gồm: tạo sprint, kéo story từ backlog theo độ ưu tiên, theo dõi tổng story point so với capacity, đặt Sprint Goal vào ô riêng khi Start Sprint.
Ba nguyên tắc cần khắc cốt ghi tâm: (1) Planning là nơi cam kết, không phải nơi refine lần đầu; (2) Luôn có một Sprint Goal duy nhất ghi rõ trên JIRA — nó là tấm khiên chống scope creep; (3) Commit theo capacity thực tế, đặc biệt cẩn thận với các kỳ nghỉ lễ Việt Nam. Làm tốt ba điều này, sprint của bạn sẽ kết thúc đúng hạn và team giữ được uy tín cam kết.