Mở đầu — vì sao bài này quan trọng
Có một hiểu lầm rất phổ biến trong các đội Scrum tại Việt Nam: Sprint Planning là "buổi họp của developer", còn Product Owner chỉ tạt qua đọc cho team nghe danh sách user story rồi rời đi để quay lại với hàng tá email từ stakeholder. Nếu bạn đang nghĩ như vậy, bạn đang bỏ lỡ chính khoảnh khắc quan trọng nhất trong cả Sprint của một PO.
Sprint Planning là nơi giá trị (value) được chuyển hóa từ ý định thành cam kết. Đây là buổi mà cả Scrum Team cùng nhau trả lời câu hỏi: "Sprint này chúng ta tạo ra điều gì xứng đáng để dồn sức trong hai tuần tới?" Và người duy nhất có thẩm quyền (accountability) về giá trị của sản phẩm chính là bạn — Product Owner. Nếu bạn vắng mặt hoặc tham gia hời hợt, đội của bạn sẽ làm việc chăm chỉ để giao một thứ gì đó, nhưng không ai chắc chắn thứ đó có đáng làm hay không.
Trong bài này, chúng ta sẽ đi sâu vào Sprint Planning đúng theo Scrum Guide 2020 — cụ thể là ba chủ đề (topics) WHY, WHAT, HOW — nhưng nhìn qua lăng kính của một PO thực thụ: bạn cần chuẩn bị gì trước buổi họp, bạn dẫn dắt phần nào, bạn lùi lại ở phần nào, và làm sao để buổi planning không biến thành một phiên "ép việc" mệt mỏi cho cả đội. Mục tiêu của tôi là sau bài này, bạn bước vào Sprint Planning với tâm thế của người làm chủ giá trị, chứ không phải người đọc danh sách.
Khái niệm cốt lõi
Sprint Planning là gì và ai chịu trách nhiệm gì
Theo Scrum Guide 2020, Sprint Planning khởi động một Sprint bằng cách vạch ra công việc sẽ được thực hiện. Toàn bộ Scrum Team — Product Owner, Scrum Master và Developers — cùng tạo ra kế hoạch này. Đây là sự kiện hợp tác, không phải buổi giao việc một chiều.
Một điểm quan trọng về thời lượng (timebox): Sprint Planning tối đa 8 giờ cho một Sprint kéo dài một tháng. Sprint ngắn hơn thì buổi họp ngắn hơn — với Sprint hai tuần (phổ biến nhất ở Việt Nam), bạn nên gói gọn trong khoảng 4 giờ. Đây là timebox tối đa, không phải mục tiêu phải dùng hết.
Scrum Guide cấu trúc Sprint Planning quanh ba chủ đề. Hãy nhớ kỹ ai làm chủ phần nào.
Topic 1 — WHY: Vì sao Sprint này có giá trị?
Đây là phần PO dẫn dắt. Bạn đề xuất sản phẩm có thể tăng giá trị và tính hữu dụng như thế nào trong Sprint này. Từ đó, cả Scrum Team cùng nhau định nghĩa một Sprint Goal (Mục tiêu Sprint) — một mục tiêu duy nhất, cô đọng, truyền đạt vì sao Sprint này đáng để làm.
Sprint Goal là một cam kết (commitment) gắn với Sprint Backlog. Nó không phải là một danh sách tính năng. Nó là lý do khiến tất cả các tính năng đó được gom vào cùng một Sprint. Một Sprint Goal tốt cho team sự linh hoạt: nếu giữa Sprint phát hiện một story khó hơn dự kiến, team vẫn có thể điều chỉnh phạm vi công việc miễn là vẫn đạt được mục tiêu.
Ví dụ phân biệt:
- Không phải Sprint Goal: "Làm xong 8 story về thanh toán."
- Là Sprint Goal: "Cho phép khách hàng thanh toán đơn hàng bằng ví MoMo để giảm tỷ lệ bỏ giỏ hàng ở bước cuối."
Topic 2 — WHAT: Chọn gì vào Sprint?
Thông qua thảo luận với PO, Developers chọn các item từ Product Backlog để đưa vào Sprint này. Đây là phần hợp tác chặt chẽ nhất giữa PO và Developers.
Vai trò của bạn ở đây rất tinh tế. Bạn làm rõ ý nghĩa, ngữ cảnh và độ ưu tiên của các item; bạn đàm phán về phạm vi nếu cần. Nhưng bạn không quyết định team lấy bao nhiêu item — đó là quyền của Developers, vì chỉ họ mới đánh giá được năng lực thực hiện của chính mình. PO không được ép số lượng. Một PO giỏi nói "Đây là thứ tôi mong muốn nhất", chứ không nói "Sprint này phải làm xong bằng này việc".
Để Developers có thể dự báo (forecast) được lượng công việc, họ cần xem xét hiệu suất quá khứ, năng lực hiện tại của Sprint này (ví dụ ai nghỉ phép) và Definition of Done. Điều đó nghĩa là backlog phải đã được refine trước đó — các item ở đầu backlog phải đủ rõ ràng, đủ nhỏ. Đây là lý do Backlog Refinement (bài 18) là điều kiện tiên quyết để Sprint Planning trôi chảy.
Topic 3 — HOW: Làm như thế nào?
Với mỗi Product Backlog item được chọn, Developers lập kế hoạch công việc cần thiết để tạo ra một Increment đạt Definition of Done. Họ thường chia (decompose) item thành các phần việc nhỏ hơn, thường là một ngày hoặc ít hơn.
Đây hoàn toàn là lãnh địa của Developers. Cách họ phân rã, thiết kế kỹ thuật, ai làm gì — PO không can thiệp. Vai trò của bạn ở đây là sẵn sàng trả lời khi họ phát hiện một câu hỏi nghiệp vụ chưa được giải đáp ("Nếu khách hàng nhập sai OTP ba lần thì sao?"). Bạn ở lại phòng, lắng nghe, và làm rõ ngay khi được hỏi — đó là giá trị lớn nhất bạn mang lại trong topic 3.
Đầu ra của Sprint Planning
Khi buổi họp kết thúc, Scrum Team có một Sprint Backlog hoàn chỉnh, gồm ba thành phần: Sprint Goal (why), tập hợp Product Backlog item được chọn (what), và kế hoạch thực hiện (how).
Tình huống thực tế
Tình huống 1 — Tiki: Khi PO biến planning thành buổi đọc danh sách
Một đội phát triển tính năng "đánh giá sản phẩm" tại một sàn thương mại điện tử kiểu Tiki gặp vấn đề kéo dài: Sprint nào cũng giao đủ story nhưng metric kinh doanh không nhúc nhích. Khi nhìn lại, người ta phát hiện cách PO chạy Sprint Planning là gốc rễ.
Mỗi buổi planning, PO mở Jira lên, đọc lần lượt 12 story đã ưu tiên sẵn từ trên xuống, hỏi team "lấy hết được không?", team gật đầu, và buổi họp kết thúc sau 40 phút. Không có Sprint Goal. Khi giữa Sprint một story về tải ảnh đánh giá bị chậm do hạ tầng, team không biết nên hy sinh phần nào vì... mọi story đều "ngang nhau" trong mắt họ. Họ cố làm hết, kết quả là làm dở dang nhiều thứ, không hoàn thiện cái nào ra hồn.
Khi Scrum Master can thiệp, họ yêu cầu PO bắt đầu mỗi planning bằng câu hỏi WHY. PO buộc phải suy nghĩ và đưa ra Sprint Goal: "Tăng số lượt đánh giá có kèm hình ảnh thật từ người mua, vì review có ảnh tăng tỷ lệ chuyển đổi của sản phẩm lên rõ rệt." Đột nhiên team có la bàn. Trong Sprint sau, khi gặp trở ngại kỹ thuật, họ tự quyết định cắt phần "lọc đánh giá theo sao" (không liên quan mục tiêu) để dồn sức làm cho bằng được luồng tải ảnh.
Bài học: Thiếu Sprint Goal, team không có cách nào ưu tiên khi gặp bất ngờ giữa Sprint. PO dẫn dắt phần WHY không phải để cho có thủ tục, mà để trao cho team một la bàn ra quyết định.
Tình huống 2 — Một startup fintech: PO ép số lượng và cái giá phải trả
Tại một startup fintech ở TP.HCM làm app cho vay tiêu dùng, PO vốn xuất thân từ kinh doanh nên rất áp lực về deadline ra mắt. Trong một Sprint Planning, team gồm 5 developer dự báo họ làm được khoảng 21 story point. PO nhìn vào roadmap đã hứa với nhà đầu tư và nói: "Sprint này mình phải làm 34 point, không thì lỡ mốc demo gọi vốn."
Team miễn cưỡng đồng ý vì nể PO. Kết quả: cuối Sprint, họ giao được 19 point nhưng phần lớn chưa đạt Definition of Done — code chưa test kỹ, có ba lỗi nghiêm trọng lọt ra môi trường thật, một khoản giải ngân bị tính sai lãi suất. Việc khắc phục ngốn nguyên Sprint tiếp theo. Tính ra, việc ép tiến độ khiến họ chậm hơn so với nếu cứ cam kết 21 point một cách trung thực.
Sau retrospective, đội thống nhất một nguyên tắc: PO sở hữu WHAT về mặt ưu tiên, nhưng Developers sở hữu HOW NHIỀU về mặt năng lực. PO có thể nói "tôi rất cần ba story này trước mốc gọi vốn", và cùng team tìm cách thu hẹp phạm vi từng story (vertical slicing — sẽ học ở bài 32) để vừa kịp vừa giữ chất lượng. Nhưng PO không được áp đặt con số.
Bài học: Velocity là công cụ dự báo, không phải hạn ngạch để ép. Một PO ép số lượng đang vay nợ kỹ thuật với lãi suất rất cao, và cái nợ đó luôn phải trả ở Sprint sau.
Tình huống 3 — Đội ngân hàng số: Sức mạnh của việc chuẩn bị trước
Một đội làm ứng dụng ngân hàng số tại một ngân hàng lớn ở Hà Nội từng có Sprint Planning kéo dài tới 6 tiếng cho Sprint hai tuần, ai cũng kiệt sức. Vấn đề không nằm ở buổi họp mà ở khâu chuẩn bị: PO mang vào những story còn mơ hồ, thiếu điều kiện chấp nhận (acceptance criteria), và buổi planning biến thành phiên refinement bất đắc dĩ.
PO mới về đội đã thay đổi thói quen. Trước mỗi Sprint Planning, anh dành buổi Backlog Refinement giữa Sprint trước để cùng team làm rõ 8–10 item ở đầu backlog: mỗi item có mô tả rõ, acceptance criteria, đã được team ước lượng sơ bộ và đủ nhỏ. Anh cũng chuẩn bị sẵn một đề xuất Sprint Goal nháp để mở đầu phần WHY (lưu ý: chỉ là nháp để khơi mào, Sprint Goal cuối cùng do cả team chốt).
Kết quả: Sprint Planning rút xuống còn 90 phút. Team bước vào với backlog "chín", nên dành thời gian cho việc thực sự quan trọng — thống nhất mục tiêu và lập kế hoạch — thay vì cãi nhau xem story này nghĩa là gì.
Bài học: Chất lượng Sprint Planning được quyết định trước khi buổi họp bắt đầu. Một PO chuẩn bị tốt là một PO tôn trọng thời gian của cả đội.
Hướng dẫn từng bước
Dưới đây là quy trình một PO nên đi qua, chia làm ba giai đoạn: trước, trong, và sau buổi họp.
Trước Sprint Planning (chuẩn bị):
- Đảm bảo backlog đã chín. Kiểm tra 8–12 item ở đầu Product Backlog: mỗi item có mô tả rõ, acceptance criteria, đã được team refine và ước lượng. Nếu chưa, hãy tổ chức refinement gấp — đừng để planning gánh việc này.
- Soạn một đề xuất Sprint Goal nháp. Dựa trên Product Goal hiện tại, dữ liệu sản phẩm và mong muốn của stakeholder, hãy viết ra một câu trả lời cho "vì sao Sprint này đáng làm". Đây là điểm khởi đầu cho thảo luận, không phải quyết định cuối cùng.
- Nắm năng lực Sprint. Hỏi trước xem ai nghỉ phép, có ngày lễ nào không, để cùng team đối chiếu khi dự báo.
- Mở đầu bằng WHY. Trình bày bối cảnh: Product Goal đang ở đâu, Sprint trước để lại gì, dữ liệu nói gì. Đề xuất Sprint Goal nháp và mời cả team cùng tinh chỉnh đến khi có một mục tiêu mọi người đều hiểu và đồng thuận.
- Cùng chọn WHAT. Đi qua các item theo thứ tự ưu tiên. Với mỗi item, làm rõ giá trị và ngữ cảnh, trả lời câu hỏi của Developers. Để Developers quyết định lấy bao nhiêu item dựa trên năng lực. Nếu team thấy quá tải, hãy cùng đàm phán thu hẹp phạm vi thay vì cắt bừa.
- Hỗ trợ phần HOW. Khi Developers phân rã công việc, hãy ở lại phòng. Bạn không lập kế hoạch kỹ thuật, nhưng bạn trả lời ngay mọi câu hỏi nghiệp vụ phát sinh. Đây là lúc nhiều giả định ẩn lộ ra — đừng bỏ lỡ.
- Kiểm tra tính nhất quán. Trước khi kết thúc, hỏi: "Tập item chúng ta chọn có thực sự phục vụ Sprint Goal không?" Nếu có item lạc đề, cân nhắc bỏ ra.
- Truyền đạt Sprint Goal ra ngoài. Chia sẻ Sprint Goal với stakeholder để họ biết Sprint này hướng tới điều gì — đây là cầu nối cho Sprint Review sắp tới.
- Bảo vệ Sprint Goal. Trong suốt Sprint, khi có yêu cầu chen ngang, hãy dùng Sprint Goal làm thước đo để nói "không" hoặc "để Sprint sau".
Lỗi thường gặp & mẹo
Lỗi 1 — Bỏ qua Sprint Goal, chỉ chọn story. Đây là lỗi phổ biến nhất. Mẹo: luôn bắt đầu bằng câu hỏi "Sprint này tạo ra giá trị gì?" trước khi chạm vào danh sách story. Nếu bạn không trả lời được, đừng vội chọn item.
Lỗi 2 — PO ép số lượng item. Hãy nhớ: bạn ưu tiên cái gì, team quyết định bao nhiêu. Mẹo: thay vì ép, hãy đàm phán phạm vi — chia nhỏ story để vừa năng lực mà vẫn đạt mục tiêu.
Lỗi 3 — Mang backlog mơ hồ vào planning. Hậu quả là buổi họp biến thành refinement, kéo dài và kiệt sức. Mẹo: coi Backlog Refinement là điều kiện bắt buộc trước mỗi Sprint Planning.
Lỗi 4 — PO rời phòng ngay sau topic WHAT. Phần HOW là lúc Developers phát hiện những câu hỏi nghiệp vụ quan trọng nhất. Mẹo: ở lại đến cuối, ngay cả khi bạn không nói nhiều — sự hiện diện của bạn rút ngắn thời gian chờ làm rõ.
Lỗi 5 — Sprint Goal là một danh sách trá hình. "Làm xong A, B, C" không phải mục tiêu. Mẹo: viết Sprint Goal dưới dạng một kết quả hoặc giá trị duy nhất, đủ để team dựa vào đó tự ưu tiên khi gặp bất ngờ.
Mẹo bổ sung — Dùng Product Goal làm bối cảnh. Mỗi Sprint Goal nên là một bước tiến về phía Product Goal (bài 14). Khi mở đầu WHY, hãy nhắc team đang ở đâu trên hành trình đó để Sprint Goal không bị rời rạc.
Bài tập thực hành
- Viết lại Sprint Goal. Lấy ba "mục tiêu" sau và xác định cái nào là Sprint Goal thật, cái nào chỉ là danh sách story trá hình. Sau đó viết lại cái sai thành Sprint Goal đúng:
- Mô phỏng đàm phán phạm vi. Giả sử team của bạn dự báo làm được 20 point nhưng bạn rất cần một story 13 point ra mắt trước mốc demo. Viết ra 3 cách bạn có thể thu hẹp phạm vi story đó (gợi ý: bỏ trường hợp biên, làm phiên bản thủ công trước, hỗ trợ một kênh thanh toán thay vì ba).
- Tự kiểm chuẩn bị. Trước buổi Sprint Planning gần nhất của bạn, lập một checklist 5 dòng dựa trên phần "Trước Sprint Planning" ở trên và tự chấm xem bạn đáp ứng được mấy mục. Bất kỳ mục nào thiếu, đó chính là việc cần làm ngay.
- Viết Sprint Goal nháp cho sản phẩm của bạn. Dựa trên Product Goal hiện tại và một vấn đề người dùng đang gặp, soạn một Sprint Goal nháp dài đúng một câu, có chứa vì sao chứ không chỉ cái gì.
Tóm tắt
Sprint Planning không phải buổi giao việc, và càng không phải buổi PO đọc danh sách story. Đó là sự kiện hợp tác mở đầu Sprint, được tổ chức quanh ba câu hỏi: WHY (vì sao Sprint này đáng làm — PO dẫn dắt, cả team chốt thành Sprint Goal), WHAT (chọn item nào — PO làm rõ và ưu tiên, Developers quyết định số lượng), và HOW (làm thế nào — Developers lập kế hoạch, PO sẵn sàng trả lời nghiệp vụ).
Vai trò của PO có thể tóm trong ba từ: dẫn dắt phần WHY, hợp tác ở phần WHAT, và hỗ trợ ở phần HOW. Bạn sở hữu giá trị và độ ưu tiên; bạn không sở hữu năng lực của team. Bạn ép số lượng là bạn vay nợ kỹ thuật với lãi cao.
Và đừng quên: phần lớn chất lượng Sprint Planning được quyết định trước buổi họp — qua một backlog đã chín và một đề xuất Sprint Goal được chuẩn bị kỹ. Đầu ra cuối cùng là một Sprint Backlog gồm đủ Sprint Goal, các item được chọn, và kế hoạch thực hiện. Hãy bước vào planning như người làm chủ giá trị, và bạn sẽ thấy cả đội đi theo một la bàn chung thay vì chỉ chạy đua giao việc.