Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn chuẩn bị cho một chuyến đi dài hai tuần. Nếu bạn xuất phát mà không biết đích đến, không biết mang theo gì, không biết ai chịu trách nhiệm lái xe — thì gần như chắc chắn chuyến đi sẽ hỗn loạn. Sprint Planning (Họp lập kế hoạch Sprint) chính là buổi họp giúp cả team thống nhất "chuyến đi" hai tuần (hoặc bốn tuần) sắp tới: chúng ta đi đâu, vì sao đi, và làm thế nào để đến nơi.
Trong vai trò Product Owner (PO — người chịu trách nhiệm về giá trị sản phẩm), Sprint Planning là một trong những buổi họp mà bạn có ảnh hưởng lớn nhất. Đây là nơi bạn biến những ưu tiên trừu tượng trong đầu mình thành một cam kết cụ thể của cả team. Một buổi Sprint Planning tốt giúp team bước vào Sprint với sự rõ ràng và tự tin. Một buổi Sprint Planning tệ — vội vàng, mơ hồ, ôm đồm quá nhiều — sẽ kéo theo cả Sprint chệch hướng, deadline trượt, và những buổi Daily Scrum đầy căng thẳng.
Trong Bài 16 này, chúng ta đi sâu vào cách tổ chức và dẫn dắt một buổi Sprint Planning chi tiết: time-box (giới hạn thời gian), ba câu hỏi cốt lõi mà buổi họp phải trả lời, vai trò của từng người, và cách bạn — với tư cách PO — chuẩn bị để buổi họp này thực sự hiệu quả. Lưu ý: bài này tập trung vào cách thực thi buổi Sprint Planning; phần Sprint Goal sâu hơn sẽ được khai thác riêng ở Bài 27, còn estimation bằng Story Points sẽ ở Bài 24.
Khái niệm cốt lõi
Sprint Planning là gì?
Sprint Planning là sự kiện (event) khởi đầu cho mỗi Sprint. Toàn bộ Scrum Team — Product Owner, Scrum Master và các Developers — cùng ngồi lại để xác định công việc nào sẽ được thực hiện trong Sprint sắp tới và bằng cách nào. Kết quả của buổi họp này là Sprint Backlog: tập hợp Sprint Goal, các Product Backlog Item (PBI) được chọn, và kế hoạch để hoàn thành chúng.
Theo Scrum Guide, Sprint Planning trả lời ba câu hỏi nền tảng:
- Tại sao Sprint này có giá trị? — Đây là Sprint Goal (mục tiêu Sprint), do PO đề xuất và cả team cùng tinh chỉnh. Nó trả lời câu hỏi: nếu Sprint này thành công, chúng ta tạo ra giá trị gì cho khách hàng và doanh nghiệp?
- Có thể hoàn thành những gì trong Sprint này? — Developers, dựa trên năng lực (capacity) thực tế và độ phức tạp công việc, chọn ra các PBI từ đỉnh Product Backlog mà họ tin có thể "Done" trong Sprint.
- Công việc được chọn sẽ thực hiện như thế nào? — Developers phân rã (decompose) các item đã chọn thành các task nhỏ hơn, đủ chi tiết để bắt tay làm ngay.
Time-box — nguyên tắc giới hạn thời gian
Sprint Planning có time-box rõ ràng, tỉ lệ thuận với độ dài Sprint:
- Tối đa 8 giờ cho một Sprint kéo dài 1 tháng.
- Tối đa 4 giờ cho một Sprint kéo dài 2 tuần.
- Sprint càng ngắn thì buổi planning càng ngắn. Với Sprint 1 tuần, thường chỉ cần khoảng 2 giờ.
Vì sao time-box quan trọng đến vậy? Vì nó tạo áp lực lành mạnh buộc PO phải đến với một backlog đã sẵn sàng. Nếu PO mang đến những item mơ hồ, chưa có tiêu chí chấp nhận (acceptance criteria), cả team sẽ "đốt" thời gian planning để làm refinement — việc lẽ ra phải xong từ trước.
Năng lực (Capacity) — đừng nhầm với Velocity
Khi Developers quyết định "có thể làm bao nhiêu", họ dựa trên capacity của Sprint cụ thể này, chứ không phải velocity trung bình một cách máy móc. Capacity là số ngày-người thực sự sẵn có: trừ đi ngày nghỉ phép, ngày lễ, thời gian cho họp hành, hỗ trợ vận hành. Ví dụ một team 5 người làm Sprint 2 tuần (10 ngày làm việc) có lý thuyết 50 ngày-người, nhưng nếu một bạn nghỉ phép 3 ngày và cả team mất ~15% thời gian cho họp, capacity thực tế chỉ còn khoảng 40 ngày-người. PO cần nắm con số này để không kỳ vọng phi thực tế.
Vai trò trong buổi họp
- Product Owner: mang đến một Product Backlog đã được sắp xếp ưu tiên (ordered), trình bày bối cảnh kinh doanh, đề xuất Sprint Goal, làm rõ ý nghĩa từng item, và sẵn sàng đàm phán phạm vi. PO không ép số lượng công việc.
- Developers: ước lượng, chọn công việc, phân rã task, và là người duy nhất quyết định "chúng tôi có thể cam kết bao nhiêu".
- Scrum Master: facilitator (người điều phối), đảm bảo buổi họp đúng time-box, đúng trọng tâm, mọi người cùng tham gia.
Tình huống thực tế
Ví dụ 1 — Tiki Việt Nam: khi PO đến với backlog chưa sẵn sàng
Một team phát triển tính năng thanh toán tại một sàn thương mại điện tử lớn ở TP.HCM (ta gọi là team "Checkout") chạy Sprint 2 tuần. Anh Minh — PO của team — vốn rất bận với các cuộc họp đối tác, thường đến Sprint Planning mà chưa kịp refine backlog. Buổi planning bắt đầu, anh mới mở Jira ra và bắt đầu... viết acceptance criteria ngay tại chỗ.
Hậu quả: buổi họp dự kiến 2 giờ kéo dài tới 4 giờ. Developers liên tục hỏi "ý anh là sao?", "trường hợp khách hủy đơn thì xử lý thế nào?". Vì mệt mỏi và muốn kết thúc, team chọn đại 8 item mà không thực sự hiểu rõ. Kết quả Sprint: chỉ 4 item "Done", 2 item phải làm lại vì hiểu sai yêu cầu.
Bài học: Sprint Planning không phải là nơi làm refinement. PO phải hoàn tất việc làm rõ yêu cầu ở các buổi backlog refinement trước đó (xem Bài 23). Sau sự cố này, anh Minh áp dụng quy tắc "Definition of Ready" (DoR): một item chỉ được đưa vào planning khi đã có mô tả rõ, acceptance criteria, và đã được team ước lượng. Sprint kế tiếp, buổi planning gọn trong 95 phút và team hoàn thành 7/8 item.
Ví dụ 2 — Startup fintech ở Singapore: Sprint Goal cứu cả Sprint
Một startup fintech khu vực Đông Nam Á (trụ sở Singapore, team dev ở Hà Nội) đang xây ứng dụng ví điện tử. PO tên Lan chuẩn bị một Sprint Goal rất rõ: "Người dùng mới có thể hoàn tất đăng ký và xác thực eKYC chỉ trong dưới 3 phút."
Giữa Sprint, một stakeholder từ phòng marketing nhảy vào yêu cầu thêm một banner khuyến mãi "khẩn cấp". Thay vì nhận bừa, Lan đối chiếu với Sprint Goal: banner này không phục vụ mục tiêu eKYC. Cô lịch sự từ chối đưa vào Sprint hiện tại và đẩy nó vào Product Backlog để cân nhắc cho Sprint sau.
Nhờ Sprint Goal đóng vai trò "kim chỉ nam", team không bị phân tán. Cuối Sprint, luồng eKYC hoàn thành đúng mục tiêu, thời gian đăng ký trung bình đo được là 2 phút 40 giây.
Bài học: Một Sprint Goal tốt — được đề xuất bởi PO ngay trong Sprint Planning — không chỉ định hướng công việc mà còn là "lá chắn" giúp team chống lại scope creep (phình phạm vi) giữa Sprint. Hãy đầu tư thời gian viết Sprint Goal thật rõ ngay từ phần đầu buổi planning.
Ví dụ 3 — Team agency outsourcing tại Đà Nẵng: ôm đồm quá tay
Một công ty gia công phần mềm ở Đà Nẵng có team 6 Developers làm Sprint 2 tuần cho khách hàng Nhật. Velocity trung bình các Sprint gần đây là khoảng 32 story points. Trong một buổi planning, PO háo hức vì khách hàng đang giục tiến độ, nên thuyết phục team nhận tới 45 points "để gây ấn tượng".
Developers, vì nể PO và áp lực khách hàng, miễn cưỡng đồng ý. Kết quả: cuối Sprint chỉ đạt 30 points, 3 story dở dang, và quan trọng hơn — chất lượng giảm vì làm vội, phát sinh 5 bug nghiêm trọng phải sửa ở Sprint sau. Niềm tin của khách hàng giảm thay vì tăng.
Bài học: Quyết định "làm được bao nhiêu" thuộc về Developers, không phải PO. Vai trò của PO là làm rõ giá trị và ưu tiên, rồi tôn trọng năng lực thực tế của team. Cam kết quá tải (over-commit) gần như luôn phản tác dụng: nó hủy hoại cả tiến độ lẫn niềm tin.
Hướng dẫn từng bước
Dưới đây là quy trình thực thi một buổi Sprint Planning hiệu quả, theo trình tự ba câu hỏi của Scrum.
Bước 0 — Chuẩn bị trước buổi họp (vai trò PO). Trước ngày planning, hãy đảm bảo:
- Product Backlog đã được sắp xếp ưu tiên, các item ở đỉnh đã được refine và ước lượng.
- Bạn đã có một bản nháp Sprint Goal trong đầu, gắn với Product Goal lớn hơn.
- Bạn nắm được capacity sắp tới (hỏi team về ngày nghỉ, lễ).
- Có sẵn dữ liệu hỗ trợ ra quyết định: phản hồi khách hàng, số liệu, kết quả Sprint Review trước.
Bước 2 — Trả lời "Tại sao" — Chốt Sprint Goal. Cả team cùng làm sắc nét Sprint Goal cho đến khi nó cụ thể, đo được, và thực sự tạo giá trị. Đây là chiếc neo cho toàn bộ phần còn lại của buổi họp.
Bước 3 — Trả lời "Cái gì" — Chọn Product Backlog Item. Developers kéo các item từ đỉnh backlog vào Sprint, mỗi item được hỏi: "item này có phục vụ Sprint Goal không?". PO đứng cạnh để làm rõ yêu cầu và acceptance criteria khi Developers cần. Đối chiếu tổng khối lượng với capacity và velocity tham chiếu để tránh ôm đồm.
Bước 4 — Trả lời "Như thế nào" — Phân rã task. Developers chia mỗi PBI thành các task kỹ thuật nhỏ (thường mỗi task ước lượng dưới 1 ngày). Đây là phần PO có thể lắng nghe nhiều hơn nói — nhưng vẫn cần có mặt để giải đáp ngay khi phát sinh câu hỏi về nghiệp vụ.
Bước 5 — Kiểm tra tính khả thi (sanity check). Cả team nhìn lại Sprint Backlog: tổng công việc có vừa với capacity không? Có rủi ro hay phụ thuộc (dependency) nào chưa xử lý? Nếu quá tải, cùng nhau bỏ bớt item ưu tiên thấp; nếu còn dư, có thể kéo thêm item từ backlog.
Bước 6 — Chốt và cam kết. Phát biểu lại Sprint Goal thành tiếng, xác nhận Sprint Backlog, và mọi người đồng thuận. Scrum Master ghi nhận, Sprint chính thức bắt đầu.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến planning thành buổi refinement. Như ví dụ Tiki, nếu bạn viết acceptance criteria tại chỗ, buổi họp sẽ vỡ time-box. Mẹo: Áp dụng "Definition of Ready" và dành các buổi refinement riêng giữa Sprint.
Lỗi 2 — PO ép số lượng công việc. PO không được phép quyết định team nhận bao nhiêu. Mẹo: Hãy trình bày giá trị và ưu tiên; để Developers tự cam kết khối lượng. Tin tưởng năng lực của họ.
Lỗi 3 — Bỏ qua Sprint Goal. Nhiều team nhảy thẳng vào chọn task mà quên mục tiêu. Mẹo: Luôn bắt đầu bằng "Tại sao Sprint này có giá trị?" trước khi bàn "Cái gì".
Lỗi 4 — Không tính capacity thực tế. Dùng velocity trung bình một cách mù quáng trong tuần có nhiều ngày lễ (như dịp Tết) sẽ dẫn đến over-commit. Mẹo: Hỏi rõ lịch nghỉ trước mỗi planning; điều chỉnh kỳ vọng tương ứng.
Lỗi 5 — Lập kế hoạch 100% capacity. Luôn có việc phát sinh: bug khẩn, hỗ trợ vận hành. Mẹo: Chừa khoảng 10–20% buffer để Sprint không đổ vỡ khi có biến.
Lỗi 6 — Không có mặt khi Developers cần. PO biến mất ngay sau khi trình bày là sai lầm. Mẹo: PO cần có mặt suốt buổi (hoặc ít nhất sẵn sàng phản hồi nhanh) để giải đáp nghiệp vụ.
Mẹo bổ sung: Với team mới hoặc team remote, hãy chia planning thành hai phần — Part 1 (chốt Sprint Goal & chọn item, có PO dẫn dắt) và Part 2 (Developers phân rã task, PO chỉ standby). Cách này giúp buổi họp đỡ mệt và sử dụng thời gian của mọi người hiệu quả hơn.
Bài tập thực hành
- Thiết kế nghị trình (agenda): Giả sử team của bạn chạy Sprint 2 tuần, gồm 5 Developers. Hãy viết một agenda chi tiết cho buổi Sprint Planning, phân bổ thời gian cụ thể cho từng phần (mở đầu, chốt Sprint Goal, chọn item, phân rã task, sanity check, chốt). Tổng không vượt quá time-box 4 giờ — và thử thách bản thân: gói gọn trong 2 giờ.
- Tính capacity: Team 5 người, Sprint 2 tuần (10 ngày làm việc). Trong Sprint này: 1 người nghỉ phép 2 ngày, có 1 ngày nghỉ lễ chung, và mỗi người dành trung bình 1 ngày cho họp hành. Hãy tính capacity thực tế (theo ngày-người) và so sánh với capacity lý thuyết.
- Viết Sprint Goal: Lấy một tính năng bạn đang hình dung (ví dụ "tích hợp thanh toán ZaloPay vào app"). Viết một Sprint Goal đạt các tiêu chí: cụ thể, đo được, hướng tới giá trị khách hàng. Sau đó liệt kê 3 item nên đưa vào Sprint và 2 item không nên — giải thích vì sao dựa trên Sprint Goal.
- Tình huống xử lý: Giữa buổi planning, một Developer nói "em nghĩ chúng ta nhận quá nhiều, không kịp đâu". Là PO, bạn sẽ phản ứng thế nào? Viết ra 3–4 câu thể hiện cách bạn lắng nghe và điều chỉnh phạm vi mà không gây áp lực.
Tóm tắt
Sprint Planning là buổi họp khởi đầu mỗi Sprint, nơi cả Scrum Team thống nhất làm gì và làm như thế nào cho chu kỳ sắp tới. Buổi họp có time-box rõ ràng: tối đa 8 giờ cho Sprint 1 tháng, 4 giờ cho Sprint 2 tuần, và ngắn hơn cho Sprint ngắn hơn — nhưng đây là giới hạn trên, không phải mục tiêu cần lấp đầy.
Buổi họp xoay quanh ba câu hỏi: Tại sao Sprint này có giá trị (Sprint Goal — do PO đề xuất), Có thể hoàn thành những gì (Developers chọn dựa trên capacity, không phải PO ép), và Thực hiện như thế nào (phân rã task). Kết quả là Sprint Backlog.
Với vai trò PO, ba việc quan trọng nhất của bạn là: (1) đến với một backlog đã refine kỹ và ưu tiên rõ ràng; (2) đề xuất một Sprint Goal sắc nét làm kim chỉ nam; và (3) tôn trọng quyền tự quyết của Developers về khối lượng công việc. Những bài học từ Tiki, startup fintech Singapore và agency Đà Nẵng đều hội tụ về một điểm: chuẩn bị tốt và tôn trọng ranh giới vai trò chính là chìa khóa cho một Sprint Planning thành công — và một Sprint suôn sẻ theo sau.