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 cùng cả nhóm. Nếu cả nhóm lên đường mà không thống nhất đích đến, không biết mình mang theo được bao nhiêu hành lý, và mỗi người hiểu một kiểu về "thành công" của chuyến đi — thì gần như chắc chắn bạn sẽ lạc nhau. Sprint Planning chính là buổi họp để cả nhóm ngồi lại, vẽ ra tấm bản đồ chung trước khi xuất phát.
Trong các nhóm Agile mà tôi từng huấn luyện ở Việt Nam, Sprint Planning là buổi họp bị làm sai nhiều nhất. Có nhóm biến nó thành buổi "giao việc" của sếp xuống nhân viên. Có nhóm để Product Owner đọc một lèo danh sách hạng mục rồi hỏi "OK chưa các bạn?". Có nhóm bỏ hẳn buổi này vì "ai cũng biết phải làm gì rồi". Hệ quả là Sprint trôi đi trong mơ hồ: cuối Sprint không ai chắc đã đạt được gì, demo lủng củng, và Retrospective biến thành buổi đổ lỗi.
Sprint Planning là sự kiện mở đầu mỗi Sprint, nơi cả Scrum Team cùng trả lời ba câu hỏi lớn: Sprint này có giá trị gì? Chúng ta làm được bao nhiêu? Và chúng ta sẽ làm thế nào? Làm tốt buổi này, bạn đặt nền móng cho một Sprint có định hướng, có cam kết thật và có thể đo lường được. Đây chính là lúc người Project Manager chuyển vai từ "người phân công" sang "người tạo điều kiện cho nhóm tự cam kết" — một bước chuyển tư duy cốt lõi của Agile.
Khái niệm cốt lõi
Theo Scrum Guide 2020, Sprint Planning khởi động Sprint bằng cách đặt ra công việc sẽ được thực hiện. Kế hoạch này do toàn bộ Scrum Team cùng tạo ra — không phải do một mình Product Owner hay Scrum Master áp xuống. Buổi họp xoay quanh ba chủ đề (three topics).
Chủ đề 1 — Vì sao Sprint này có giá trị? (Why)
Product Owner đề xuất việc Sprint này sẽ làm tăng giá trị và tính hữu ích của sản phẩm như thế nào. Từ đó, cả nhóm cùng nhau xác định một Sprint Goal — Mục tiêu Sprint. Đây là một câu mô tả ngắn gọn, mang tính kết quả, trả lời câu hỏi: "Nếu Sprint này thành công, người dùng hoặc doanh nghiệp sẽ nhận được điều gì?"
Sprint Goal không phải là danh sách công việc. Nó là một mục tiêu duy nhất, mạch lạc, đủ rộng để nhóm có không gian xoay xở khi gặp khó khăn, nhưng đủ hẹp để định hướng mọi quyết định trong Sprint. Ví dụ Sprint Goal tốt: "Cho phép khách hàng thanh toán đơn hàng bằng ví MoMo từ đầu đến cuối". Ví dụ Sprint Goal tệ (vì chỉ là liệt kê): "Làm xong 12 user story trong backlog".
Sprint Goal phải được chốt trước khi cả nhóm cam kết kết thúc buổi Planning. Nó là cam kết (commitment) gắn với Sprint Backlog.
Chủ đề 2 — Sprint này làm được những gì? (What)
Thông qua thảo luận với Product Owner, các Developer chọn các hạng mục từ Product Backlog để đưa vào Sprint. Điểm mấu chốt mà nhiều nhóm Việt Nam hay làm sai: người chọn khối lượng công việc là Developer, không phải PO và không phải sếp. PO trình bày ưu tiên và giá trị; Developer là người quyết định "chừng này thì chúng tôi làm được trong Sprint này".
Để chọn đúng, nhóm dựa vào ba dữ kiện: hiệu suất quá khứ (velocity, throughput — sẽ học sâu ở Bài 23), năng lực thực tế của Sprint sắp tới (capacity — ai nghỉ phép, ai họp nhiều), và Definition of Done (Bài 16) để hiểu "xong" thực sự nghĩa là gì.
Chủ đề 3 — Công việc được chọn sẽ làm thế nào? (How)
Với mỗi hạng mục đã chọn, Developer phân rã thành các đầu việc đủ nhỏ — thường là các task hoàn thành được trong một ngày hoặc ít hơn. Cách phân rã hoàn toàn do Developer tự quyết; không ai bên ngoài được áp đặt. Đây là lúc kế hoạch trở nên cụ thể, lộ ra các phụ thuộc và rủi ro kỹ thuật.
Sản phẩm đầu ra: Sprint Backlog
Kết tinh của buổi Planning là Sprint Backlog, gồm ba phần: Sprint Goal (tại sao), tập hợp các hạng mục Product Backlog đã chọn (cái gì), và kế hoạch hành động để giao chúng (như thế nào). Sprint Backlog là bản kế hoạch sống, được Developer cập nhật mỗi ngày khi hiểu biết tăng lên.
Time-box
Sprint Planning được giới hạn thời gian (time-box) tối đa 8 giờ cho một Sprint một tháng. Sprint ngắn hơn thì buổi họp ngắn hơn tương ứng — Sprint hai tuần thường gói gọn trong khoảng 4 giờ. Time-box là trần, không phải sàn; nếu xong sớm thì kết thúc sớm.
Tình huống thực tế
Tình huống 1 — Sàn TMĐT giả định "Chợ Sạch" (Hà Nội): từ giao việc sang tự cam kết
Nhóm phát triển của "Chợ Sạch", một startup thương mại điện thực phẩm, làm Sprint hai tuần với 6 Developer. Ba Sprint đầu, Trưởng nhóm kỹ thuật (kiêm vai PM cũ) ngồi vào Planning và đọc danh sách 18 hạng mục, rồi nói "Sprint này mình làm hết nhé". Kết quả: Sprint 1 hoàn thành 9/18, Sprint 2 hoàn thành 11/18, cả nhóm kiệt sức và mất niềm tin vào ước lượng.
Khi chuyển sang đúng tinh thần Scrum, Scrum Master đề nghị PO chỉ trình bày giá trị và thứ tự ưu tiên, rồi để Developer tự kéo việc. Họ nhìn lại velocity trung bình ba Sprint là khoảng 26 điểm. Sprint mới, có một bạn nghỉ phép 3 ngày, nhóm tự chốt mục tiêu chỉ 22 điểm. Sprint Goal được đặt là: "Khách mua rau hữu cơ có thể đặt lịch giao cố định hằng tuần". Kết quả Sprint đó: hoàn thành 21/22 điểm, demo trọn vẹn tính năng đặt lịch.
Bài học: Khi để chính người làm tự cam kết khối lượng dựa trên dữ liệu thật, độ tin cậy của kế hoạch tăng vọt — dù con số cam kết "nhỏ hơn" trên giấy. Một Sprint đạt 95% cam kết đáng giá hơn nhiều một Sprint "tham vọng" chỉ đạt 50%.
Tình huống 2 — Công ty outsourcing tại TP.HCM: Sprint Goal cứu một Sprint suýt hỏng
Một công ty gia công phần mềm ở Quận 7 nhận dự án cho khách hàng Singapore. Trong một Sprint, nhóm chọn 10 user story rời rạc thuộc 4 mảng tính năng khác nhau, không có Sprint Goal rõ ràng. Đến giữa Sprint, một API bên thứ ba bị lỗi khiến 3 story bị kẹt.
Vì không có mục tiêu chung, nhóm hoảng loạn: nên bỏ story nào, giữ story nào? Mọi người tranh cãi mất nửa ngày. Sau đó Scrum Master đặt lại câu hỏi: "Nếu cuối Sprint chỉ giao được một thứ cho khách, thứ đó nên là gì?" Nhóm nhận ra mục tiêu thực sự đáng giá là hoàn thiện luồng đăng nhập SSO cho khách doanh nghiệp. Họ tập trung toàn lực vào 4 story phục vụ mục tiêu đó, gác lại các story phụ thuộc API lỗi.
Cuối Sprint, demo luồng SSO chạy mượt và khách hàng hài lòng, dù 3 story khác bị hoãn.
Bài học: Sprint Goal là chiếc la bàn khi sóng gió ập đến. Khi có biến cố, nhóm có mục tiêu rõ sẽ biết phải hy sinh cái gì và bảo vệ cái gì. Nếu Planning chỉ chốt "danh sách việc" mà thiếu mục tiêu, nhóm mất khả năng ra quyết định linh hoạt giữa Sprint.
Tình huống 3 — Fintech Đông Nam Á: capacity planning cứu nhóm khỏi cam kết ảo
Một nhóm tại một công ty fintech (giả định tên "PayLink") có 5 Developer, làm Sprint hai tuần (10 ngày làm việc). Lúc đầu họ tính capacity đơn giản: 5 người × 10 ngày = 50 ngày-người, và cam kết theo đó. Nhưng Sprint nào cũng trượt.
Khi ngồi lại, Scrum Master hướng dẫn tính capacity thực tế hơn: trừ thời gian họp (Daily, Review, Retro, Refinement chiếm khoảng 15%), trừ ngày nghỉ, trừ phần thời gian dành cho hỗ trợ vận hành (on-call) khoảng 20%. Capacity thực còn lại chỉ khoảng 32 ngày-người — chứ không phải 50. Từ Sprint đó, nhóm cam kết dựa trên 32, và lần đầu tiên họ hoàn thành đúng cam kết.
Bài học: Con số "lý thuyết" về năng lực luôn lớn hơn năng lực thật. Sprint Planning chuyên nghiệp phải trừ đi mọi khoản "hao hụt" — họp, nghỉ phép, on-call, công việc ngoài Sprint. Cam kết dựa trên capacity ảo là nguyên nhân số một khiến Sprint trượt liên tục.
Hướng dẫn từng bước
Dưới đây là quy trình tổ chức một buổi Sprint Planning hiệu quả mà bạn có thể áp dụng ngay. Giả định Sprint hai tuần, time-box 4 giờ.
Bước 0 — Chuẩn bị trước buổi họp (ngày trước đó). Đảm bảo Product Backlog đã được Refinement (Bài 15): các hạng mục ưu tiên cao đã đủ rõ ràng, có ước lượng sơ bộ và Acceptance Criteria. PO chuẩn bị sẵn đề xuất về giá trị Sprint tới. Scrum Master tổng hợp velocity vài Sprint gần nhất và lịch nghỉ phép của nhóm. Một buổi Planning tệ thường bắt đầu từ một backlog chưa được chuẩn bị.
Bước 1 — PO trình bày bối cảnh và đề xuất giá trị (khoảng 20–30 phút). PO mở đầu bằng việc nhắc lại Product Goal, kết quả Sprint trước, phản hồi từ Sprint Review, và đề xuất hướng đi của Sprint này. Đây là phần trả lời câu hỏi "Why".
Bước 2 — Cả nhóm cùng soạn thảo Sprint Goal. Đừng để PO đọc sẵn một câu rồi cả nhóm gật đầu. Hãy cùng viết, cùng tranh luận đến khi có một câu mục tiêu mạch lạc, hướng kết quả, mọi người đều hiểu giống nhau. Viết nó lên bảng để cả Sprint nhìn thấy.
Bước 3 — Xác định capacity thực của Sprint. Tính số ngày-người khả dụng sau khi trừ nghỉ phép, họp, on-call và buffer cho việc bất ngờ. Đây là trần khối lượng mà nhóm được phép cam kết.
Bước 4 — Developer chọn hạng mục (trả lời "What"). Theo thứ tự ưu tiên của PO, Developer kéo từng hạng mục vào Sprint, vừa kéo vừa đối chiếu với capacity và Sprint Goal. Mỗi hạng mục được chọn phải phục vụ mục tiêu hoặc giải thích được lý do cần có. Dừng lại khi capacity đã đầy — đừng nhồi thêm.
Bước 5 — Phân rã thành task (trả lời "How"). Với từng hạng mục, Developer thảo luận cách triển khai và chia thành các task nhỏ (thiết kế, code, test, tích hợp...). Đây cũng là lúc phát hiện phụ thuộc, rủi ro và những chỗ chưa rõ cần hỏi lại PO ngay.
Bước 6 — Kiểm tra tính khả thi và chốt cam kết. Nhóm nhìn lại toàn bộ Sprint Backlog: khối lượng có vừa capacity không? Có phục vụ Sprint Goal không? Định nghĩa "Done" có áp dụng được không? Khi cả nhóm tự tin, Sprint chính thức bắt đầu.
Bước 7 — Chốt đầu ra. Đảm bảo ba thứ rõ ràng: Sprint Goal, danh sách hạng mục, và kế hoạch task ban đầu. Đó chính là Sprint Backlog.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến Planning thành buổi giao việc. Sếp hoặc PO áp đặt khối lượng. Khắc phục: PO chỉ sở hữu "What và Why"; Developer sở hữu "How và bao nhiêu". Để chính người làm cam kết.
Lỗi 2 — Không có Sprint Goal, chỉ có danh sách story. Khi đó nhóm mất la bàn lúc gặp biến. Mẹo: nếu không tóm được mục tiêu Sprint trong một câu, có thể bạn đang ôm quá nhiều thứ rời rạc — hãy thu hẹp lại.
Lỗi 3 — Cam kết theo capacity ảo. Quên trừ họp, nghỉ phép, on-call. Mẹo: luôn dùng capacity thực, và để lại buffer 10–20% cho việc bất ngờ.
Lỗi 4 — Nhồi nhét đến 100% capacity. Sprint nào cũng có việc phát sinh. Nhồi đầy nghĩa là chắc chắn trượt. Mẹo: cam kết ở mức 80–85% capacity trong vài Sprint đầu để xây dựng độ tin cậy.
Lỗi 5 — Mang vào Sprint những story chưa rõ ràng. Story chưa Refinement sẽ "nổ" giữa Sprint. Mẹo: chỉ kéo vào Sprint những hạng mục đã "Ready" — đủ rõ, đủ nhỏ, có tiêu chí chấp nhận.
Lỗi 6 — Planning kéo dài lê thê. Tôn trọng time-box. Mẹo: nếu tranh luận kỹ thuật quá sâu, hãy "đỗ" (park) nó lại để xử lý ngoài buổi họp, tránh giữ cả nhóm chờ.
Lỗi 7 — Bỏ qua vai trò facilitator của Scrum Master. Scrum Master không quyết nội dung, nhưng phải đảm bảo buổi họp đúng mục đích, đủ ba chủ đề và trong time-box.
Bài tập thực hành
Bài tập 1 — Viết Sprint Goal. Cho bối cảnh: nhóm bạn làm app đặt đồ ăn, Sprint tới ưu tiên các story về tính năng theo dõi shipper theo thời gian thực. Hãy viết một Sprint Goal đạt chuẩn (một câu, hướng kết quả) và một Sprint Goal "phản ví dụ" (chỉ liệt kê công việc) để tự so sánh.
Bài tập 2 — Tính capacity. Nhóm 5 Developer, Sprint 10 ngày làm việc. Một bạn nghỉ phép 2 ngày. Họp định kỳ ngốn 12% thời gian. On-call ngốn 18%. Hãy tính capacity thực còn lại theo ngày-người, và đề xuất mức cam kết hợp lý (gợi ý: chừa buffer).
Bài tập 3 — Mô phỏng buổi Planning. Cùng nhóm (hoặc bạn học), chọn 5 hạng mục giả định, chạy đủ ba chủ đề Why–What–How trong 45 phút có bấm giờ. Sau đó tự đánh giá: đã chốt được Sprint Goal chưa, khối lượng có vừa capacity chưa, mỗi hạng mục đã phân rã thành task chưa.
Bài tập 4 — Soi lỗi. Quan sát (hoặc nhớ lại) một buổi Sprint Planning bạn từng tham gia. Đối chiếu với 7 lỗi ở trên và liệt kê những lỗi nhóm bạn mắc phải, kèm một hành động cải thiện cụ thể cho mỗi lỗi.
Tóm tắt
Sprint Planning là sự kiện mở đầu mỗi Sprint, do toàn bộ Scrum Team cùng thực hiện, xoay quanh ba chủ đề: Why (PO đề xuất giá trị, cả nhóm chốt Sprint Goal), What (Developer tự chọn hạng mục dựa trên capacity và velocity), và How (Developer phân rã thành task). Đầu ra là Sprint Backlog gồm Sprint Goal, các hạng mục đã chọn và kế hoạch hành động. Buổi họp có time-box tối đa 8 giờ cho Sprint một tháng.
Ba điều cốt lõi cần nhớ: thứ nhất, người cam kết khối lượng là Developer, không phải sếp — đó là bước chuyển tư duy từ "giao việc" sang "tự cam kết". Thứ hai, Sprint Goal là chiếc la bàn giúp nhóm linh hoạt khi gặp biến cố, nên đừng bao giờ bỏ qua nó. Thứ ba, hãy cam kết dựa trên capacity thực — trừ hết họp, nghỉ phép, on-call — vì cam kết theo capacity ảo là nguyên nhân số một khiến Sprint trượt. Làm tốt buổi này, bạn đặt nền móng vững cho mọi sự kiện Scrum còn lại trong Sprint.