Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Product Owner của một đội phát triển ứng dụng gọi xe ở TP.HCM. Sáng thứ Hai đầu Sprint, cả nhóm tụ họp trong phòng họp, mọi người nhìn nhau và hỏi: "Sprint này mình làm gì nhỉ?". Không ai chắc chắn. Backlog thì dài dằng dặc, mỗi người hiểu ưu tiên một kiểu, lập trình viên ước lượng dựa trên cảm tính. Hai tuần sau, Sprint kết thúc trong tình trạng dở dang: ba tính năng làm được một nửa, không có gì hoàn chỉnh để demo cho khách hàng.
Đó chính xác là điều xảy ra khi Sprint Planning bị xem nhẹ. Trong Scrum, Sprint là "trái tim" của cả khung làm việc, và Sprint Planning là khoảnh khắc quyết định Sprint đó sẽ thành công hay thất bại ngay từ trước khi viết một dòng code. Một buổi Planning tốt biến một danh sách công việc hỗn loạn thành một cam kết rõ ràng, có mục tiêu, có kế hoạch và có niềm tin của cả đội.
Với vai trò Product Owner, bạn không "ngồi ngoài" buổi Planning. Bạn là người mang đến tại sao (mục tiêu, giá trị, ưu tiên), trong khi Developers quyết định làm thế nào và bao nhiêu. Bài học này sẽ giúp bạn hiểu sâu cơ chế của Sprint Planning và Sprint Execution — cách chuẩn bị đầu vào, cách dẫn dắt buổi họp, và cách đồng hành cùng đội trong suốt Sprint mà không biến mình thành một "ông sếp giao việc".
Khái niệm cốt lõi
Sprint Planning là gì
Sprint Planning là sự kiện mở đầu mỗi Sprint, nơi cả Scrum Team cùng nhau trả lời ba câu hỏi lớn: Sprint này tạo ra giá trị gì? Có thể hoàn thành được những gì? Sẽ làm thế nào để hoàn thành? Đây là buổi họp có giới hạn thời gian (timebox) — tối đa 8 giờ cho một Sprint dài 1 tháng, và ngắn hơn tương ứng với Sprint ngắn hơn. Với Sprint 2 tuần phổ biến ở Việt Nam, buổi Planning thường gói gọn trong 3–4 giờ.
Theo Scrum Guide 2020, Sprint Planning được chia thành ba chủ đề (topic):
Topic 1 — Tại sao Sprint này có giá trị? Product Owner đề xuất Sprint Goal (Mục tiêu Sprint) — một câu ngắn gọn mô tả vì sao Sprint này đáng làm. Cả đội cùng tinh chỉnh để Sprint Goal trở thành cam kết chung. Đây là đóng góp quan trọng nhất của PO trong buổi họp.
Topic 2 — Sprint này có thể hoàn thành những gì? Developers, qua thảo luận với PO, chọn ra các hạng mục từ Product Backlog đưa vào Sprint. Họ cân nhắc capacity (năng lực thực tế), velocity (tốc độ trung bình các Sprint trước) và Definition of Done.
Topic 3 — Làm thế nào để hoàn thành? Developers chia nhỏ các hạng mục đã chọn thành các task cụ thể, đủ nhỏ để xử lý trong một ngày hoặc ít hơn. Đây là phần kỹ thuật, PO không cần can thiệp sâu nhưng nên có mặt để giải đáp thắc mắc.
Bốn đầu vào bắt buộc của Sprint Planning
Một buổi Planning chỉ hiệu quả khi các đầu vào đã sẵn sàng. Nếu thiếu, buổi họp sẽ biến thành buổi refinement vội vàng và kéo dài lê thê.
- Product Backlog đã được sắp xếp và tinh chỉnh (ordered & refined). Các hạng mục ở đầu backlog phải rõ ràng, đủ nhỏ, có tiêu chí chấp nhận (acceptance criteria) và đã được ước lượng sơ bộ. Đây là trách nhiệm cốt lõi của Product Owner — bạn không thể bước vào Planning với một backlog mơ hồ.
- Team capacity (năng lực khả dụng). Đây là số "giờ thật" hoặc "ngày thật" mà đội có trong Sprint sau khi trừ đi nghỉ phép, họp hành, hỗ trợ vận hành. Một đội 5 người trong Sprint 2 tuần không có 80 giờ x 5 để code — sau khi trừ họp Scrum, hỗ trợ, nghỉ lễ, con số thực có thể chỉ còn 60–65%.
- Definition of Done (DoD). Tiêu chuẩn "thế nào là xong" để đội biết một hạng mục cần làm tới đâu mới được tính hoàn thành — đã code, đã test, đã review, đã tích hợp.
- Velocity. Tốc độ trung bình (tính bằng story points) mà đội hoàn thành trong vài Sprint gần nhất, dùng làm cơ sở dự báo khối lượng hợp lý cho Sprint mới.
Sprint Execution — vận hành Sprint
Sau Planning, Sprint Backlog ra đời: gồm Sprint Goal + các hạng mục đã chọn + kế hoạch thực hiện. Trong giai đoạn Execution, đội làm việc hằng ngày để biến Sprint Backlog thành Increment (sản phẩm gia tăng) hoàn chỉnh. Sprint Backlog không "đóng băng" — đội có thể điều chỉnh chi tiết kế hoạch khi học được điều mới, miễn là Sprint Goal không thay đổi. Vai trò của PO trong giai đoạn này là luôn sẵn sàng trả lời câu hỏi, làm rõ yêu cầu, và bảo vệ Sprint Goal khỏi những yêu cầu phát sinh nửa chừng.
Tình huống thực tế
Ví dụ 1 — Tiki và buổi Planning "đói đầu vào"
Một đội 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 (tạm gọi mô hình giống Tiki) từng có thói quen bước vào Sprint Planning mà không refine backlog trước. Kết quả: mỗi buổi Planning kéo dài tới 6 giờ vì cả nhóm phải vừa làm rõ yêu cầu, vừa tranh luận ưu tiên, vừa ước lượng — tất cả trong một buổi.
PO mới về nhận ra vấn đề và áp dụng quy tắc: dành 1–2 buổi refinement giữa Sprint (mỗi buổi 60 phút) để 3–4 hạng mục đầu backlog luôn đạt trạng thái "ready" — rõ acceptance criteria, đã ước lượng. Sau ba Sprint, thời lượng Planning của đội giảm từ 6 giờ xuống còn 2,5 giờ, và quan trọng hơn, tỷ lệ hoàn thành Sprint Goal tăng từ khoảng 50% lên trên 85%.
Bài học: Chất lượng của Sprint Planning được quyết định trước buổi họp, không phải trong buổi họp. Backlog refinement là khoản đầu tư mà PO không được bỏ qua.
Ví dụ 2 — Đội fintech ở Singapore và bài học về capacity
Một startup fintech ở Singapore có đội 6 lập trình viên, velocity trung bình 40 story points/Sprint. Một Sprint nọ, PO háo hức kéo 48 điểm vào Sprint vì sếp đang giục ra mắt tính năng mới cho một đối tác ngân hàng. Đội miễn cưỡng đồng ý.
Vấn đề là Sprint đó rơi vào tuần có hai lập trình viên đi tập huấn 2 ngày, và một người phải trực hỗ trợ sự cố sản xuất. Capacity thực tế giảm khoảng 25%, nghĩa là sức chứa hợp lý chỉ còn quanh 30 điểm. Kết quả: Sprint kết thúc với 31 điểm hoàn thành, 17 điểm dở dang, tính năng cho đối tác không kịp, và tệ hơn là đội mất niềm tin vào cam kết của chính mình.
Sprint sau, PO thay đổi cách làm: trước Planning, cô cùng Scrum Master tính capacity thực tế dựa trên lịch nghỉ và phân công trực, rồi mới đề xuất Sprint Goal phù hợp. Velocity được dùng làm tham chiếu, không phải mục tiêu cứng. Đội bắt đầu hoàn thành đều đặn 90% cam kết.
Bài học: Velocity là dự báo, không phải lời hứa. PO phải tôn trọng capacity thực tế của đội và kháng cự áp lực "nhồi" thêm việc — vì một Sprint thất bại đắt hơn nhiều một Sprint khiêm tốn nhưng trọn vẹn.
Ví dụ 3 — Đội nội bộ ngân hàng Việt Nam và Sprint Goal cứu Sprint
Một đội phát triển ứng dụng mobile banking ở Hà Nội đưa vào Sprint sáu hạng mục rời rạc: cập nhật giao diện màn hình chính, sửa lỗi đăng nhập, thêm tính năng QR, tối ưu tốc độ, viết lại màn hình lịch sử giao dịch, và một spike nghiên cứu công nghệ. Không có sợi dây chung nào kết nối chúng.
Giữa Sprint, đối tác yêu cầu gấp một thay đổi cho tính năng QR. Vì các hạng mục rời rạc, không ai biết nên ưu tiên gì, đội mất một ngày tranh cãi. PO sau đó học cách định hình Sprint Goal trước: "Sprint này, mục tiêu là cho phép khách hàng thanh toán bằng QR an toàn và mượt mà." Khi có Sprint Goal, mọi hạng mục liên quan QR được ưu tiên rõ ràng, các việc phụ có thể linh hoạt cắt bớt mà không ảnh hưởng giá trị cốt lõi. Yêu cầu phát sinh được xử lý nhanh vì nó nằm trong tinh thần của Sprint Goal.
Bài học: Sprint Goal không phải thủ tục hình thức. Nó là kim chỉ nam giúp đội ra quyết định khi có biến động — và đó là sản phẩm quan trọng nhất mà PO mang đến buổi Planning.
Hướng dẫn từng bước
Bước 1 — Chuẩn bị trước Planning (PO chủ trì). Đảm bảo 3–4 hạng mục đầu backlog đã "ready": rõ mô tả, có acceptance criteria, đã được ước lượng sơ bộ qua refinement. Cập nhật thứ tự ưu tiên theo giá trị kinh doanh mới nhất.
Bước 2 — Cùng Scrum Master tính capacity. Trừ đi ngày nghỉ, lễ, tập huấn, thời gian trực vận hành. Ghi rõ năng lực thực tế của Sprint sắp tới.
Bước 3 — Đề xuất Sprint Goal (Topic 1). Mở đầu buổi họp bằng một câu Sprint Goal nháp. Giải thích vì sao nó quan trọng với khách hàng và doanh nghiệp. Cùng đội tinh chỉnh thành một câu rõ ràng, đo được.
Bước 4 — Chọn hạng mục đưa vào Sprint (Topic 2). Để Developers chủ động kéo các hạng mục phù hợp với Sprint Goal vào Sprint, dựa trên velocity và capacity. PO làm rõ yêu cầu, trả lời câu hỏi, nhưng không ép số lượng.
Bước 5 — Lập kế hoạch thực hiện (Topic 3). Developers chia nhỏ hạng mục thành task. PO có mặt để giải đáp, nhưng phần này thuộc về đội kỹ thuật.
Bước 6 — Xác nhận Sprint Backlog. Chốt lại: Sprint Goal + danh sách hạng mục + kế hoạch. Đảm bảo cả đội đồng thuận và tự tin với cam kết.
Bước 7 — Đồng hành trong Execution. Tham gia Daily Scrum với tư cách lắng nghe (không chỉ đạo). Luôn sẵn sàng làm rõ yêu cầu trong vòng vài giờ. Bảo vệ Sprint Goal: nếu có yêu cầu phát sinh, cân nhắc đưa vào backlog cho Sprint sau thay vì phá vỡ Sprint hiện tại.
Bước 8 — Theo dõi tiến độ. Quan sát tiến độ qua Sprint Backlog hằng ngày. Nếu thấy Sprint Goal có nguy cơ không đạt, cùng đội đàm phán lại phạm vi — cắt bớt hạng mục phụ, giữ cốt lõi.
Lỗi thường gặp & mẹo
Lỗi 1 — PO biến Planning thành buổi giao việc. PO chỉ định "anh làm cái này, chị làm cái kia" là phá vỡ tính tự tổ chức của đội. Mẹo: chỉ mang đến mục tiêu và ưu tiên, để Developers tự quyết cách làm và khối lượng.
Lỗi 2 — Bỏ qua Sprint Goal, chỉ chọn một mớ task rời rạc. Sprint không có "linh hồn", đội mất phương hướng khi có biến động. Mẹo: luôn bắt đầu bằng một câu Sprint Goal trước khi chọn hạng mục.
Lỗi 3 — Nhồi quá nhiều việc ("over-commitment"). Lạc quan quá mức khiến Sprint kết thúc dở dang. Mẹo: dùng velocity làm trần, để lại 10–20% đệm cho việc phát sinh và rủi ro.
Lỗi 4 — Backlog chưa refine mà vẫn vào Planning. Buổi họp kéo dài, kiệt sức, kém chất lượng. Mẹo: duy trì refinement đều đặn giữa Sprint, giữ "đỉnh backlog" luôn sẵn sàng.
Lỗi 5 — Thay đổi phạm vi giữa Sprint một cách tùy tiện. PO liên tục thêm việc mới giữa Sprint khiến đội không bao giờ hoàn thành. Mẹo: tôn trọng Sprint Goal; yêu cầu mới đi vào backlog, không phá Sprint đang chạy.
Mẹo vàng: Hãy hỏi đội cuối buổi Planning: "Mọi người có tự tin hoàn thành Sprint Goal này không?". Nếu câu trả lời ngập ngừng, hãy điều chỉnh phạm vi ngay — niềm tin của đội là tín hiệu chính xác nhất về tính khả thi của Sprint.
Bài tập thực hành
- Viết Sprint Goal. Lấy một sản phẩm bạn quen thuộc (hoặc giả định một ứng dụng giao đồ ăn). Chọn 4–5 hạng mục backlog và viết một câu Sprint Goal liên kết chúng. Tự đánh giá: nếu phải cắt 1 hạng mục, cái nào có thể bỏ mà không ảnh hưởng Sprint Goal?
- Tính capacity. Đội có 5 lập trình viên, Sprint 2 tuần (10 ngày làm việc). Có 1 người nghỉ phép 2 ngày, cả đội dành ~10% thời gian cho họp Scrum, 1 người trực vận hành mất 1 ngày. Hãy ước tính số "ngày làm việc thực" của đội trong Sprint.
- Dự báo khối lượng. Velocity ba Sprint gần nhất lần lượt là 38, 42, 40 điểm. Sprint tới capacity giảm khoảng 20%. Bạn nên đề xuất kéo bao nhiêu điểm vào Sprint? Giải thích lý do.
- Xử lý tình huống. Giữa Sprint, sếp yêu cầu thêm gấp một tính năng "nhỏ" ước lượng 5 điểm. Sprint đang chạy đúng tiến độ với Sprint Goal khác. Viết ra cách bạn phản hồi sếp theo tinh thần Scrum.
Tóm tắt
Sprint Planning là sự kiện quyết định Sprint thành hay bại, và Product Owner đóng vai trò trung tâm ở khâu chuẩn bị đầu vào và định hình Sprint Goal. Bốn đầu vào bắt buộc — Product Backlog đã refine, capacity thực tế, Definition of Done, và velocity — phải sẵn sàng trước buổi họp. Trong Planning, PO mang đến "tại sao" qua Sprint Goal, còn Developers quyết định "làm gì" và "làm thế nào".
Qua ba tình huống thực tế, ta rút ra ba nguyên tắc cốt lõi: refinement quyết định chất lượng Planning, velocity là dự báo chứ không phải lời hứa, và Sprint Goal là kim chỉ nam giúp đội vững vàng trước biến động. Trong giai đoạn Execution, PO không buông tay mà đồng hành — sẵn sàng làm rõ yêu cầu, bảo vệ Sprint Goal, và cùng đội đàm phán phạm vi khi cần. Một PO giỏi không nhồi việc, không giao việc, mà tạo điều kiện để đội tự cam kết và tự tin hoàn thành. Đó là nền tảng để mọi Sprint trở nên trọn vẹn và tạo ra giá trị thật cho khách hàng.