Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười Scrum Master rằng sự kiện nào trong Sprint hay bị làm "cho có" nhất, rất nhiều người sẽ trả lời: Sprint Planning. Lý do là ở cấp PSM I, chúng ta được dạy Sprint Planning như một thủ tục: gọi team vào phòng, kéo item từ Product Backlog xuống, ước lượng, rồi commit. Nhưng ở cấp độ Scrum Master cao cấp (PSM II), bạn phải nhìn Sprint Planning như một sự kiện thiết kế kết quả — nơi cả team cùng nhau định hình một Sprint có khả năng tạo ra giá trị, chứ không chỉ là một danh sách công việc cần làm.
Đây là điểm khác biệt then chốt. Một team yếu coi Sprint Planning là "chia việc". Một team trưởng thành coi Sprint Planning là nơi họ trả lời câu hỏi: "Tại sao Sprint này đáng để chúng ta dành hai tuần tới? Chúng ta sẽ làm cho cuộc sống của ai tốt hơn?" Vai trò của Scrum Master không phải là người điều phối phòng họp đơn thuần, mà là người thiết kế cuộc planning sao cho nó luôn đẩy team về phía outcome (kết quả, tác động) thay vì output (sản lượng, số lượng task).
Bài này sẽ đi sâu vào nghệ thuật làm Sprint Planning ở tầm cao: cách craft một buổi planning tạo ra ba "đầu ra" chuẩn của Scrum Guide 2020, cách xử lý ba chủ đề (topic) của planning, và cách bạn — với tư cách Scrum Master — facilitate để team tự sở hữu kế hoạch thay vì bị áp đặt.
Khái niệm cốt lõi
Ba đầu ra bắt buộc của một Sprint Planning chất lượng
Theo Scrum Guide 2020, một Sprint Planning hoàn chỉnh phải tạo ra ba thứ — và đây cũng là khung để bạn đánh giá chất lượng buổi planning của team mình:
- Sprint Goal đã được cam kết — một mục tiêu duy nhất, mạch lạc, trả lời "tại sao" của Sprint. Đây là commitment của Sprint Backlog.
- Các Product Backlog Item được chọn vào Sprint — "cái gì" có thể hoàn thành trong Sprint này để phục vụ Sprint Goal.
- Một kế hoạch để đạt được mục tiêu (the plan) — "làm thế nào" team sẽ biến các item đã chọn thành một Increment hoàn chỉnh, đạt Definition of Done.
Trật tự Why → What → How: lỗi đảo ngược kinh điển
Ở PSM I, nhiều người vô thức làm planning theo trật tự ngược: bắt đầu bằng việc kéo item (What), chia task (How), rồi nếu còn thời gian mới nghĩ tới Sprint Goal (Why). Hậu quả là Sprint Goal trở thành một câu mô tả gượng gạo ghép lại từ các item lẻ — kiểu "Hoàn thành 8 user story đã chọn". Đó không phải là goal, đó là bản tóm tắt backlog.
Scrum Master trưởng thành đảo lại trật tự. Bắt đầu từ Why: Product Owner trình bày mục tiêu kinh doanh, dữ liệu người dùng, hoặc cơ hội mà Sprint này nên nhắm tới. Từ cuộc đối thoại đó, team đề xuất một Sprint Goal nháp. Chỉ khi đã có hướng đi rõ ràng, team mới chọn item (What) phục vụ goal đó, và cuối cùng phác kế hoạch (How). Trật tự này khiến Sprint Goal trở thành la bàn — mọi quyết định chọn item về sau đều quy chiếu về nó.
Capacity-based planning, không phải velocity-based commitment
Một khái niệm cốt lõi khác: Developers — chứ không phải Scrum Master hay PO — là người quyết định họ chọn bao nhiêu vào Sprint. Vai trò của bạn là giúp họ planning dựa trên capacity thực tế (số người, ngày nghỉ lễ, on-call, công việc hỗ trợ ngoài Sprint) chứ không chỉ nhìn velocity trung bình của các Sprint trước. Velocity là chỉ báo tham khảo; capacity của chính Sprint sắp tới mới là ràng buộc thật.
Forecast, không phải promise
Cuối cùng, hãy khắc cốt một từ: forecast (dự báo). Các item được chọn là một dự báo về những gì team tin có thể hoàn thành, không phải một lời hứa cứng buộc về toàn bộ phạm vi. Thứ duy nhất được commit (cam kết) là Sprint Goal. Sự phân biệt tinh tế này giải phóng team khỏi nỗi sợ "không xong hết item = thất bại", và cho phép họ điều chỉnh phạm vi trong Sprint miễn là vẫn bảo vệ được Sprint Goal.
Tình huống thực tế
Tình huống 1 — Team "chia việc" tại một fintech ở TP.HCM
Một công ty fintech tại Quận 1, TP.HCM (gọi là "MoMoney") có một team 6 Developer làm tính năng ví điện tử. Mỗi Sprint Planning kéo dài gần 4 tiếng và luôn kết thúc trong mệt mỏi. Khi Scrum Master mới về, anh quan sát và phát hiện vấn đề: buổi planning bắt đầu bằng việc mở Jira, kéo lần lượt 14 item từ đầu backlog xuống, mỗi item lại tách thành 5–7 sub-task, và team tranh cãi từng giờ ước lượng. Sprint Goal được viết vào ô cuối cùng, 10 phút trước khi hết giờ: "Hoàn thành các story trong Sprint 23."
Hậu quả là khi giữa Sprint phát sinh sự cố, team không biết item nào quan trọng hơn item nào, vì tất cả đều "phải xong". Họ ôm đồm cả 14 item, kết quả là 9 item dở dang, không cái nào release được.
Scrum Master can thiệp bằng cách đảo trật tự. Sprint kế tiếp, anh yêu cầu PO mở đầu bằng một câu hỏi: "Sau hai tuần tới, điều gì khiến chúng ta tự hào nhất?" PO trả lời: "Người dùng có thể nạp tiền từ thẻ ngân hàng mới mà không bị treo ở bước OTP." Cả team lập tức có một Sprint Goal thật: "Người dùng nạp tiền qua thẻ thành công trong một lần, không lỗi OTP." Từ goal đó, họ chỉ chọn 8/14 item thực sự phục vụ luồng nạp tiền, đẩy 6 item còn lại sang sau. Buổi planning rút còn 2 tiếng. Cuối Sprint, luồng nạp tiền release được trọn vẹn.
Bài học: Khi không có Why dẫn đường, mọi item trông quan trọng như nhau và team mất khả năng ưu tiên dưới áp lực. Sprint Goal không phải mục trang trí — nó là cơ chế ra quyết định trong suốt Sprint.
Tình huống 2 — Over-commit vì nhìn velocity mù quáng tại một công ty outsourcing ở Hà Nội
Một công ty gia công phần mềm ở Cầu Giấy, Hà Nội (gọi là "VietSoft") có team velocity trung bình 40 điểm/Sprint. Sprint Planning của họ mặc định: cứ kéo item cho đủ 40 điểm là xong. Nghe rất kỷ luật. Nhưng có một Sprint, hai Developer giỏi nhất nghỉ phép Tết tổng cộng 6 ngày, một bạn lại phải on-call hỗ trợ hệ thống cũ. Team vẫn commit 40 điểm theo thói quen.
Kết quả: chỉ hoàn thành 22 điểm. Tệ hơn, vì cố nhồi cho đủ, họ bỏ qua việc kiểm thử kỹ, đẩy ba bug nghiêm trọng sang Sprint sau, làm hỏng luôn kế hoạch Sprint kế tiếp.
Scrum Master sau đó đưa vào một bước nhỏ nhưng đắt giá: trước mỗi planning, team làm một capacity check bằng bảng đơn giản — tổng số ngày-người khả dụng (loại trừ nghỉ phép, lễ, on-call, họp lớn). Sprint sau, capacity thực chỉ còn 60% bình thường, nên team forecast 24 điểm thay vì 40. Họ hoàn thành 24 điểm trọn vẹn, kèm Sprint Goal. Niềm tin của khách hàng tăng lên vì lần đầu tiên cam kết khớp với thực giao.
Bài học: Velocity quá khứ chỉ là tham chiếu. Capacity của chính Sprint sắp tới mới là ràng buộc thật. Một Scrum Master giỏi giúp team planning theo điều kiện thực, không theo con số trung bình lý tưởng.
Tình huống 3 — Planning thiếu "How" tại một startup thương mại điện tử
Một startup e-commerce ở Đà Nẵng có team rất nhanh ở khâu Why và What: họ chốt Sprint Goal trong 20 phút, chọn item gọn gàng. Nhưng họ bỏ qua phần How — "đã chọn item rồi thì cứ thế mà làm". Vấn đề lộ ra ở Daily Scrum ngày thứ ba: hai Developer phát hiện họ đang làm trùng một phần API, còn một dependency với team thanh toán bên ngoài thì không ai để ý cho tới khi bị chặn cứng.
Scrum Master nhận ra buổi planning của họ thiếu cuộc đối thoại về kế hoạch thực thi. Anh đưa vào một câu hỏi facilitation đơn giản cho phần How: "Với mỗi item, đâu là phần khó nhất, ai phụ thuộc vào ai, và có dependency nào ngoài team không?" Chỉ riêng câu hỏi đó giúp team phát hiện sớm dependency với đội thanh toán và chủ động đặt lịch trước. Sprint sau đó trôi chảy hơn hẳn.
Bài học: Phần How không cần chi tiết tới từng dòng code, nhưng phải đủ để team tự tin rằng kế hoạch khả thi và đã nhận diện được rủi ro, dependency lớn. Bỏ qua How là đẩy rủi ro vào giữa Sprint.
Hướng dẫn từng bước
Dưới đây là một quy trình facilitation Sprint Planning mà bạn có thể áp dụng và tinh chỉnh cho team mình. Giả định Sprint hai tuần, planning đóng khung tối đa 4 tiếng (timebox theo Scrum Guide cho Sprint một tháng; ngắn hơn cho Sprint ngắn hơn).
Bước 0 — Chuẩn bị trước planning (việc của Scrum Master cùng PO). Đảm bảo Product Backlog đã được refine đủ: các item ở đầu backlog rõ ràng, đủ nhỏ, có tiêu chí chấp nhận. Planning không phải lúc để refine từ con số 0. Đồng thời chuẩn bị dữ liệu capacity và một Sprint Goal nháp mà PO mang tới để mồi cuộc đối thoại.
Bước 1 — Mở màn bằng Why (15–30 phút). PO trình bày mục tiêu kinh doanh, phản hồi người dùng, dữ liệu Sprint trước. Scrum Master facilitate để cả team cùng nhào nặn một Sprint Goal nháp — một câu, hướng về tác động cho người dùng hoặc doanh nghiệp, không phải danh sách item.
Bước 2 — Kiểm tra capacity (10 phút). Cùng team tính số ngày-người khả dụng thực tế cho Sprint này, trừ đi nghỉ phép, lễ, on-call, các cuộc họp lớn. Ghi ra rõ ràng để mọi người cùng nhìn thấy ràng buộc.
Bước 3 — Chọn item phục vụ goal (What) (45–60 phút). Team kéo item, nhưng với mỗi item phải hỏi: "Item này có phục vụ Sprint Goal không?" Item nào không phục vụ goal mà vẫn cần làm thì để ở mức tối thiểu. Developers — không phải PO — quyết định số lượng dựa trên capacity.
Bước 4 — Phác kế hoạch thực thi (How) (45–60 phút). Với từng item hoặc nhóm item, team thảo luận: phần khó nhất ở đâu, dependency nội bộ và bên ngoài, ai cần phối hợp với ai, rủi ro lớn nhất. Không cần tách hết task ngay; đủ để team tự tin kế hoạch khả thi.
Bước 5 — Kiểm tra tính khả thi và chốt (15 phút). Hỏi cả team ba câu: Sprint Goal này có truyền cảm hứng và rõ ràng không? Forecast này có khả thi với capacity không? Nếu giữa Sprint phải cắt phạm vi, chúng ta vẫn bảo vệ được Sprint Goal chứ? Khi cả team gật đầu, đó là lúc commit Sprint Goal.
Lỗi thường gặp & mẹo
Lỗi 1 — Sprint Goal là bản tóm tắt backlog. "Hoàn thành 8 story" không phải goal. Mẹo: viết goal theo công thức tác động — "Để [ai đó] có thể [làm được điều gì] nhằm [tạo ra giá trị gì]."
Lỗi 2 — Scrum Master ôm hết, biến planning thành phần thuyết trình một chiều. Bạn là facilitator, không phải người quyết định phạm vi. Mẹo: dùng câu hỏi mở để team tự nói, im lặng nhiều hơn bạn tưởng là cần thiết.
Lỗi 3 — Coi forecast là promise. Khi team sợ "không xong hết item", họ sẽ giấu rủi ro và over-commit. Mẹo: nhắc rõ ngay đầu planning rằng chỉ Sprint Goal được commit, phạm vi item là dự báo có thể điều chỉnh.
Lỗi 4 — Bỏ qua capacity thực, chỉ nhìn velocity. Mẹo: luôn làm capacity check khi có nghỉ lễ, người mới, hoặc on-call — đặc biệt quan trọng với bối cảnh Việt Nam quanh dịp Tết.
Lỗi 5 — Planning kéo dài lê thê vì refine ngay tại chỗ. Mẹo: bảo vệ timebox; nếu item quá mơ hồ, đó là tín hiệu refinement chưa đủ chứ không phải vấn đề của planning.
Mẹo nâng cao: Sau vài Sprint, hãy đo "tỷ lệ Sprint đạt được Sprint Goal" thay vì chỉ đo "% item hoàn thành". Một team đạt goal 9/10 Sprint nhưng đôi khi bỏ vài item phụ là team khỏe mạnh hơn nhiều so với team xong 100% item nhưng goal mờ nhạt.
Bài tập thực hành
- Viết lại Sprint Goal. Lấy Sprint Goal gần nhất của team bạn. Nếu nó là danh sách item, hãy viết lại theo công thức tác động "Để [ai] có thể [làm gì] nhằm [giá trị gì]". So sánh hai phiên bản và tự hỏi: phiên bản nào giúp ra quyết định khi giữa Sprint phải cắt phạm vi?
- Capacity check thử nghiệm. Cho Sprint sắp tới, lập một bảng đơn giản: tên từng Developer, số ngày khả dụng, trừ nghỉ phép/on-call/họp lớn. Tính tổng capacity thực và so với velocity trung bình. Mức chênh lệch nói lên điều gì?
- Thiết kế lại agenda planning. Vẽ lại agenda buổi Sprint Planning của team bạn theo trật tự Why → What → How với timebox cho từng phần. Mang ra thảo luận với team và thử chạy trong một Sprint, rồi đưa kết quả vào Retrospective.
- Câu hỏi cho phần How. Soạn 3 câu hỏi mở mà bạn sẽ dùng để facilitate phần kế hoạch thực thi, giúp team phát hiện dependency và rủi ro sớm thay vì để lộ ở Daily Scrum.
Tóm tắt
Sprint Planning ở cấp PSM II không phải là một thủ tục chia việc, mà là một sự kiện thiết kế kết quả. Một buổi planning chất lượng phải tạo ra ba đầu ra: Sprint Goal đã cam kết, các item được chọn phục vụ goal, và một kế hoạch khả thi để đạt được goal đó. Bí quyết then chốt là đảo về đúng trật tự Why → What → How, để Sprint Goal trở thành la bàn dẫn đường thay vì câu mô tả ghép vội ở phút cuối.
Là Scrum Master, vai trò của bạn là facilitate chứ không áp đặt: giúp team craft một Sprint Goal hướng tác động, planning dựa trên capacity thực thay vì velocity lý tưởng, và hiểu rằng phạm vi item là forecast chứ chỉ Sprint Goal mới là commitment. Ba tình huống ở MoMoney, VietSoft và startup Đà Nẵng cho thấy ba thất bại phổ biến — thiếu Why, over-commit theo velocity, và bỏ qua How — đều có thể chữa bằng những can thiệp facilitation nhỏ nhưng đúng chỗ. Khi bạn làm chủ được điều này, mỗi Sprint Planning sẽ không còn là gánh nặng bốn tiếng đồng hồ, mà trở thành khoảnh khắc team thực sự sở hữu hướng đi của mình.