Sprint Planning: Hướng Dẫn Toàn Diện Cho Engineering Teams
Sprint Planning done right quyết định 80% thành công của sprint. Planning tệ = over-commitment → burnout, hoặc under-commitment → waste capacity. Theo Scrum Guide 2020, Sprint Planning dài max 2 giờ cho sprint 1 tuần, 4 giờ cho sprint 2 tuần. Nhưng thực tế: nhiều team planning 4 giờ mà vẫn không ai rõ ai làm gì, sprint goal mơ hồ, và cuối sprint lại fail 40% commitments. State of Agile Report 2024 cho thấy 58% Scrum teams không đạt sprint goals thường xuyên — nguyên nhân #1: sprint planning kém. Bài viết này chia sẻ framework Sprint Planning hiệu quả từ kinh nghiệm thực tế BanhCuonFlow team.
Sprint Planning Gồm 3 Phần
🎯 Part 1: Sprint Goal (30 phút)
Product Owner trình bày: sprint này đạt mục tiêu gì? "Hoàn thành workflow approval cho module HR" — không phải list 20 tasks random. Sprint Goal là north star: khi phải cắt giảm scope, những tasks phục vụ Sprint Goal được giữ lại, còn lại đưa về backlog. Team thảo luận, ask questions, clarify acceptance criteria. Sprint Goal tốt = specific, measurable, achievable within sprint, business-value-oriented. Sprint Goal xấu = "làm nhiều tasks nhất có thể" hoặc "fix bugs."
📊 Part 2: Capacity Planning (15 phút)
Tính capacity thực tế — không phải lý thuyết. Công thức: X devs × Y ngày working = base capacity. Trừ: holidays, planned vacations, meetings (daily standup 15min × 10 ngày = 2.5h), on-call duties, sprint ceremonies (review, retro). Ví dụ thực tế BanhCuonFlow: 4 devs × 10 ngày = 40 dev-days lý thuyết. Trừ meetings & ceremonies (20%) = 32 dev-days. Thêm buffer 20% cho bugs, production incidents, code review = ~25 dev-days effective capacity. Phổ biến sai lầm: dùng 100% capacity lý thuyết → chắc chắn fail sprint.
🃏 Part 3: Estimation & Selection (1-2 giờ)
Kéo items từ Product Backlog vào Sprint Backlog. PO giải thích context và priority. Team estimate effort dùng Planning Poker hoặc T-shirt sizing. Items > 13 story points → quá lớn, cần break down trước khi đưa vào sprint. Team tự quyết định bao nhiêu items fit capacity — PO không ép thêm. Khi đủ → STOP. Đừng cố nhét thêm "just one more task" — đó là con đường dẫn đến sprint failure. Output: Sprint Backlog + Sprint Goal + commitment của team.
Estimation Techniques So Sánh
Planning Poker: Mỗi dev giơ card (fibonacci: 1, 2, 3, 5, 8, 13). Divergence lớn (ví dụ: 1 người ra 2, người khác ra 13) → discussion bắt buộc — ai đó hiểu requirements khác hoặc nhìn thấy complexity ẩn. Sau discuss → vote lại. Converge → move on. Ưu điểm: democratic, reveals knowledge gaps, team alignment. Nhược: chậm nếu backlog dài. Phù hợp: sprint planning cho well-known domain.
T-Shirt Sizing (S/M/L/XL): Nhanh hơn Planning Poker, ít chính xác hơn. S = 1-2 ngày, M = 3-5 ngày, L = 1 tuần, XL = quá lớn, cần break down. Phù hợp: backlog grooming, roadmap planning, early-stage estimation khi requirements chưa rõ. BanhCuonFlow dùng T-shirt sizing cho quarterly planning, Planning Poker cho sprint planning.
#NoEstimates: Trend đang lên — không estimate, chỉ break down tasks đủ nhỏ (< 1 ngày). Đo throughput (bao nhiêu tasks/sprint) và cycle time thay vì velocity (story points). Monte Carlo simulation dự đoán delivery date. Phù hợp mature teams hiểu domain rõ, backlog items tương đối đồng đều về size. BanhCuonFlow thử nghiệm: cycle time average 1.2 ngày/task → sprint predictable without estimates.
Definition of Ready (DoR)
Trước khi đưa item vào sprint, nó phải đạt "Definition of Ready" — tránh tình trạng developer nhận task rồi phải chase PO hỏi requirements. BanhCuonFlow DoR checklist: ✅ User story rõ ràng (As a..., I want..., So that...). ✅ Acceptance criteria defined (given/when/then). ✅ UI mockup hoặc wireframe đính kèm (nếu có UI). ✅ Dependencies identified (API đã có? Data đã sẵn?). ✅ Estimable — team hiểu đủ để estimate. Item không đạt DoR → không được đưa vào sprint, trả về backlog để PO refine thêm.
5 Sai Lầm Sprint Planning Phổ Biến
① Over-commitment: "Chắc sprint này xong được" — chưa bao giờ xong. Ego estimation: developers thường estimate optimistic gấp 2-3 lần reality (Hofstadter's Law). Luôn trừ buffer 20%. Better under-promise, over-deliver.
② Vague user stories: "Improve performance" — measure gì? Target gì? "Fix login" — fix gì? Acceptance criteria phải specific: "Page load time < 2s trên 3G connection" hoặc "Login error rate < 0.1%."
③ Không break down tasks: 1 task 13 points → nửa sprint mới discover hidden complexity. Kết quả: task not done, rollover sang sprint sau. Nguyên tắc: mọi task trong sprint nên ≤ 3 ngày effort. Lớn hơn → break down.
④ Planning without team: Tech lead hoặc manager plan rồi assign tasks cho từng người. Team không own sprint → không commit. Scrum: team tự chọn tasks, tự organize ai làm gì. Ownership = accountability.
⑤ Ignore tech debt: 100% features, 0% maintenance. Sau 5 sprints → system brittle, bugs tăng exponentially, developer productivity giảm. Best practice: allocate 20% capacity cho tech debt mỗi sprint — refactor, update dependencies, improve test coverage, fix flaky tests.