Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn chuẩn bị khởi hành một chuyến đi xuyên Việt bằng xe máy. Bạn sẽ không nhảy lên xe rồi cứ thế phóng đi mà không biết hôm nay sẽ tới đâu, mang theo gì, đường nào tránh kẹt xe. Sprint Planning chính là buổi họp "trước khi nổ máy" của mỗi Sprint — nơi cả Scrum Team ngồi lại để trả lời ba câu hỏi sống còn: chúng ta đang hướng tới điều gì, sẽ làm được gì trong Sprint này, và sẽ làm như thế nào.
Với kỳ thi PSM I, Sprint Planning là một trong những event bị hỏi nhiều nhất, và cũng là nơi thí sinh hay sai nhất. Vì sao? Vì trong thực tế, rất nhiều công ty làm Sprint Planning sai bản chất — họ biến nó thành buổi "sếp giao việc", buổi "ước lượng chính xác từng giờ", hoặc buổi họp chỉ có Product Owner và một vài người tham gia. Scrum Guide 2020 mô tả Sprint Planning rất gọn gàng nhưng chặt chẽ, và đề thi PSM I sẽ kiểm tra xem bạn có nắm đúng "by the book" hay không.
Bài này tập trung riêng vào Sprint Planning — event mở màn cho mỗi Sprint. Tôi sẽ không lan sang Daily Scrum, Sprint Review hay Retrospective (những event đó có bài riêng), cũng không đào sâu vào bản chất Sprint Backlog hay Sprint Goal như một artifact/commitment độc lập. Ở đây, chúng ta quan tâm đến cơ chế của buổi họp: ai tham gia, kéo dài bao lâu, đầu vào là gì, đầu ra là gì, và ba chủ đề (topics) mà Scrum Guide yêu cầu phải giải quyết.
Khái niệm cốt lõi
Định nghĩa và mục đích
Theo Scrum Guide 2020, Sprint Planning khởi tạo Sprint bằng cách bày ra (lay out) công việc sẽ được thực hiện trong Sprint đó. Kế hoạch này được tạo ra thông qua sự cộng tác của toàn bộ Scrum Team — nghĩa là cả Product Owner, Scrum Master và Developers cùng tham gia, chứ không phải một người áp đặt cho phần còn lại.
Hãy ghi nhớ một câu rất quan trọng cho kỳ thi: Sprint Planning là điểm bắt đầu của Sprint. Sprint không bắt đầu bằng một quyết định hành chính nào đó; nó bắt đầu bằng chính buổi Sprint Planning này. Ngay khi Sprint Planning kết thúc, Sprint đã chạy.
Timebox
Sprint Planning được giới hạn thời gian tối đa 8 giờ cho một Sprint dài một tháng (4 tuần). Với Sprint ngắn hơn, event này thường ngắn hơn tương ứng. Ví dụ, Sprint hai tuần thường có Sprint Planning khoảng 4 giờ.
Một điểm cực kỳ dễ bẫy trong đề thi: 8 giờ là giới hạn trên (maximum), không phải thời lượng cố định. Nếu team hoàn thành kế hoạch trong 2 giờ, họ kết thúc sớm và bắt đầu làm việc — không cần "ngồi cho đủ giờ". Timebox trong Scrum luôn là trần, không phải sàn.
Ai tham gia
Người tham gia bắt buộc là toàn bộ Scrum Team: Product Owner, Scrum Master, Developers. Ngoài ra, Scrum Team có thể mời người khác tham dự để cung cấp tư vấn — ví dụ một chuyên gia kỹ thuật, một người am hiểu nghiệp vụ. Nhưng những người này chỉ là khách mời để tư vấn; quyết định vẫn thuộc về Scrum Team.
Scrum Master không "chủ trì và phân công" như một quản lý dự án truyền thống. Scrum Master đảm bảo sự kiện diễn ra, đúng mục đích, đúng timebox, và giúp mọi người tập trung — đó là vai trò facilitator, không phải người ra lệnh.
Đầu vào của Sprint Planning
Để buổi planning hiệu quả, Scrum Team nên có sẵn các đầu vào:
- Product Backlog đã được refinement ở mức đủ tốt (các hạng mục ưu tiên cao đã rõ ràng, đủ nhỏ).
- Product Goal — mục tiêu dài hạn mà Product Backlog đang hướng tới.
- Increment trước đó và hiệu suất thực tế của team (past performance).
- Định nghĩa Hoàn thành (Definition of Done) để team biết "xong" nghĩa là gì.
- Capacity dự kiến của team trong Sprint (ai nghỉ phép, lễ tết, v.v.).
Ba chủ đề (Topics) của Sprint Planning
Đây là phần "xương sống" mà đề PSM I bắt buộc bạn thuộc. Scrum Guide 2020 chia Sprint Planning thành ba topic, ứng với ba câu hỏi:
Topic 1 — Why: Tại sao Sprint này có giá trị? Product Owner đề xuất cách Sản phẩm có thể tăng giá trị và tiện ích trong Sprint hiện tại. Sau đó toàn bộ Scrum Team cùng nhau định nghĩa Sprint Goal — một mục tiêu duy nhất, súc tích, truyền đạt vì sao Sprint này đáng làm. Sprint Goal phải được hoàn tất (finalized) trước khi Sprint Planning kết thúc.
Topic 2 — What: Có thể hoàn thành điều gì trong Sprint này? Thông qua thảo luận với Product Owner, Developers chọn các hạng mục từ Product Backlog để đưa vào Sprint. Điểm mấu chốt: chính Developers là người quyết định bao nhiêu việc đưa vào, dựa trên năng lực và kinh nghiệm quá khứ của họ — không ai được ép. Scrum Team có thể tinh chỉnh các hạng mục này để hiểu rõ và tự tin hơn.
Topic 3 — How: Sẽ làm công việc đã chọn như thế nào? Với mỗi hạng mục đượ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. Thường họ chia (decompose) hạng mục thành các đầu việc nhỏ hơn, lý tưởng là cỡ một ngày hoặc nhỏ hơn. Cách Developers tổ chức công việc này hoàn toàn do họ tự quyết — đây là biểu hiện của tính tự quản (self-managing).
Đầu ra của Sprint Planning
Khi buổi họp kết thúc, Scrum Team đã tạo ra Sprint Backlog, gồm ba thành phần:
- Sprint Goal (Why) — mục tiêu của Sprint.
- Tập hợp các Product Backlog Item được chọn (What).
- Kế hoạch để giao Increment (How).
Tình huống thực tế
Ví dụ 1 — Tiki Software Team biến Planning thành "buổi giao việc"
Tại một nhóm phát triển trong một công ty thương mại điện tử lớn ở TP.HCM (gọi là nhóm "Checkout Squad", 6 Developers, Sprint 2 tuần), buổi Sprint Planning thường diễn ra như sau: Trưởng nhóm kỹ thuật mở Jira lên, đọc danh sách công việc đã được anh ấy "xếp sẵn" cho từng người, rồi hỏi "có ai thắc mắc gì không?". Cả buổi gói gọn trong 30 phút, không ai phản đối, và cũng chẳng ai thực sự cam kết.
Hệ quả là gì? Đến giữa Sprint, các Developer phát hiện một hạng mục thực ra phụ thuộc vào API của team khác chưa sẵn sàng, một hạng mục khác lại lớn gấp ba so với hình dung ban đầu. Sprint vỡ kế hoạch, team phải làm thêm giờ, và Sprint Goal — nếu có — thì cũng mơ hồ ("làm xong mấy task checkout").
Bài học: Sprint Planning không phải buổi sếp giao việc. Khi Developers không tự chọn lượng việc và không tự lập kế hoạch How, họ không sở hữu cam kết, và những rủi ro (phụ thuộc, độ lớn thật) không được phơi bày sớm. Đúng Scrum, chính Developers phải là người chọn "bao nhiêu" và "làm thế nào" — đó là lý do topic What và How thuộc về Developers.
Ví dụ 2 — Một fintech ở Singapore làm đúng Topic 1 (Why) trước
Một nhóm tại một startup fintech ở Singapore (5 Developers, một PO, một SM, Sprint 2 tuần) có thói quen rất hay: mỗi Sprint Planning, họ dành 20 phút đầu chỉ để chốt Sprint Goal, trước khi đụng vào bất kỳ hạng mục Product Backlog nào.
Trong một Sprint cụ thể, PO đề xuất giá trị: "Giảm tỷ lệ rớt giao dịch khi nạp tiền qua ví điện tử". Cả team thảo luận và chốt Sprint Goal: "Người dùng có thể nạp tiền qua ba ví phổ biến nhất với tỷ lệ thành công trên 98%." Chỉ sau khi có mục tiêu này, Developers mới chọn các hạng mục từ backlog phục vụ đúng mục tiêu — và lập tức loại ra một hạng mục "đẹp nhưng không liên quan" về giao diện màu sắc.
Giữa Sprint, khi phát sinh một yêu cầu mới chen ngang, team chỉ cần hỏi: "Việc này có giúp đạt Sprint Goal không?" Câu trả lời là không, nên họ đưa nó vào Product Backlog cho Sprint sau thay vì làm loãng Sprint hiện tại.
Bài học: Đặt Why (Sprint Goal) lên trước What và How giúp Sprint có một "ngôi sao dẫn đường". Sprint Goal tạo sự tập trung (focus) và làm cho các quyết định trong Sprint trở nên dễ dàng. Đây cũng chính là thứ tự ba topic mà Scrum Guide gợi ý.
Ví dụ 3 — Team ở Hà Nội ép Planning thành "ước lượng chính xác từng giờ"
Một nhóm phát triển nội bộ tại một ngân hàng ở Hà Nội (Sprint 4 tuần) từng dành gần trọn 8 giờ Sprint Planning để cãi nhau về việc một task tốn 6 giờ hay 8 giờ, rồi cộng tổng số giờ sao cho khớp y hệt capacity. Họ tin rằng kế hoạch càng chi tiết, càng chính xác thì Sprint càng chắc thắng.
Thực tế ngược lại: họ kiệt sức trước cả khi Sprint bắt đầu, và những con số "chính xác" đó vẫn sai bét khi gặp thực tế. Tệ hơn, vì đã "khóa cứng" kế hoạch How đến từng giờ, họ ngại điều chỉnh khi tình hình thay đổi giữa Sprint.
Bài học: Mục tiêu của Sprint Planning là tạo ra một kế hoạch đủ tốt để bắt đầu, không phải kế hoạch hoàn hảo bất biến. Scrum dùng tư duy thực nghiệm (empiricism): kế hoạch How chỉ là dự kiến và sẽ được điều chỉnh hằng ngày. Timebox 8 giờ là trần để ngăn lãng phí, không phải hạn mức cần lấp đầy. Và Sprint Backlog là một bức tranh đủ chi tiết để team inspect & adapt mỗi ngày, chứ không phải bản hợp đồng đóng băng.
Hướng dẫn từng bước
Dưới đây là một dòng chảy mẫu cho một buổi Sprint Planning hiệu quả (giả định Sprint 2 tuần, timebox khoảng 4 giờ):
- Chuẩn bị trước buổi họp. Scrum Master đảm bảo Product Backlog đã được refinement, Definition of Done rõ ràng, và mọi người biết capacity (ai nghỉ phép trong Sprint). PO nắm rõ thứ tự ưu tiên và giá trị mong muốn.
- Mở đầu — nhắc lại Product Goal. Cả team cùng nhìn lại Product Goal để đặt Sprint này trong bối cảnh lớn hơn. Điều này giúp Sprint Goal sau đó gắn kết với hướng đi dài hạn của sản phẩm.
- Topic Why — Chốt Sprint Goal. PO đề xuất giá trị có thể tạo ra trong Sprint. Cả Scrum Team thảo luận và cùng nhau định nghĩa một Sprint Goal duy nhất, súc tích. Đừng vội sang bước sau khi chưa có sự đồng thuận về "vì sao Sprint này đáng làm".
- Topic What — Developers chọn hạng mục. Dựa trên Sprint Goal, năng lực quá khứ và capacity, Developers (trao đổi với PO) chọn các Product Backlog Item phù hợp. Số lượng do Developers quyết. Nếu một hạng mục còn mơ hồ, tinh chỉnh tại chỗ để hiểu rõ hơn.
- Topic How — Lập kế hoạch thực thi. Với từng hạng mục đã chọn, Developers chia nhỏ thành các đầu việc (lý tưởng cỡ một ngày hoặc nhỏ hơn), xác định cách phối hợp để đạt Definition of Done. Cách tổ chức hoàn toàn do Developers tự quyết.
- Kiểm tra tính khả thi và sự đồng thuận. Cả team nhìn lại: lượng việc đã chọn có thực tế với Sprint Goal và capacity không? Nếu thấy quá nhiều, thương lượng với PO để điều chỉnh phạm vi (scope), không phải để "cam kết liều".
- Kết thúc — xác nhận Sprint Backlog. Khi đã có đủ Sprint Goal + hạng mục được chọn + kế hoạch, Sprint Backlog hình thành. Sprint Planning kết thúc (có thể sớm hơn timebox) và Sprint chính thức bắt đầu.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi Sprint Planning là buổi sếp/PO giao việc. Sai bản chất tự quản. Developers phải tự chọn lượng việc (What) và tự lập kế hoạch (How). PO cung cấp giá trị và độ ưu tiên, không áp đặt khối lượng.
Lỗi 2 — Bỏ qua hoặc xem nhẹ Sprint Goal. Nhiều team nhảy thẳng vào chọn task mà không chốt Why. Hệ quả là Sprint thiếu tập trung, dễ bị xao nhãng. Nhớ: Sprint Goal phải được hoàn tất trước khi Planning kết thúc.
Lỗi 3 — Hiểu timebox là thời lượng cố định. 8 giờ (cho Sprint 1 tháng) là trần. Xong sớm thì kết thúc sớm. Đừng "ngồi cho hết giờ".
Lỗi 4 — Cố ước lượng "chính xác tuyệt đối". Kế hoạch How là dự kiến, sẽ được điều chỉnh mỗi ngày. Mục tiêu là đủ tốt để bắt đầu, không phải hoàn hảo.
Lỗi 5 — Lẫn lộn "cam kết" (commit) với "dự báo" (forecast). Trong Scrum 2020, lượng việc Developers chọn là một dự báo (forecast), không phải lời hứa cứng. Đề thi rất hay bẫy ở từ ngữ này — chọn đáp án dùng "forecast/select", tránh đáp án nói team "commit to deliver all items".
Mẹo ghi nhớ cho PSM I:
- Ba topic: Why → What → How (Sprint Goal → chọn hạng mục → lập kế hoạch).
- Ai sở hữu gì: Why là của cả Team; What do Developers chọn (cùng PO); How do Developers tự quyết.
- Đầu ra: Sprint Backlog = Sprint Goal + items được chọn + kế hoạch.
- Timebox: tối đa 8 giờ cho Sprint 1 tháng, ngắn hơn cho Sprint ngắn hơn.
- Người dự: toàn bộ Scrum Team; có thể mời khách tư vấn.
Bài tập thực hành
- Nhận diện ba topic. Lấy một sản phẩm bạn quen thuộc (ví dụ app gọi xe, app đặt đồ ăn). Viết ra: một Sprint Goal khả dĩ (Why), ba hạng mục backlog phục vụ mục tiêu đó (What), và với một trong ba hạng mục, chia nó thành các đầu việc nhỏ cỡ một ngày (How).
- Sửa lỗi tình huống. Đọc lại Ví dụ 1 (Checkout Squad). Hãy viết lại kịch bản buổi Sprint Planning cho đúng Scrum: ai làm gì, theo thứ tự nào, và chỉ rõ chỗ nào trước đây làm sai.
- Phân biệt commit vs forecast. Tự đặt một câu hỏi trắc nghiệm: "Khi kết thúc Sprint Planning, Developers ____ các hạng mục đã chọn." Liệt kê hai phương án — một đúng (forecast/select), một sai (commit to deliver 100%) — và giải thích vì sao.
- Tính timebox. Nếu Sprint của team bạn dài 3 tuần, theo nguyên tắc tỷ lệ, Sprint Planning nên không vượt quá khoảng bao nhiêu giờ? Giải thích cách bạn suy ra con số đó từ chuẩn 8 giờ cho 4 tuần.
- Tự kiểm. Viết ra ba thành phần của Sprint Backlog mà không nhìn lại bài. Sau đó đối chiếu.
Tóm tắt
Sprint Planning là event mở màn mỗi Sprint, được thực hiện bởi sự cộng tác của toàn bộ Scrum Team, với timebox tối đa 8 giờ cho Sprint một tháng (ngắn hơn cho Sprint ngắn hơn). Buổi họp giải quyết ba topic theo thứ tự: Why (cả team chốt Sprint Goal), What (Developers chọn các Product Backlog Item, cùng trao đổi với PO), và How (Developers tự lập kế hoạch để đạt Definition of Done). Đầu ra là Sprint Backlog gồm Sprint Goal, các hạng mục được chọn, và kế hoạch giao Increment.
Những điểm dễ sai mà bạn phải khắc cốt: timebox là trần chứ không phải sàn; Developers — chứ không phải sếp hay PO — quyết định lượng việc và cách làm; lượng việc là dự báo (forecast), không phải cam kết cứng; và Sprint Goal phải được chốt trước khi Planning kết thúc. Nắm vững những chi tiết "by the book" này, bạn vừa làm Scrum đúng trong thực tế, vừa tránh được hầu hết bẫy mà PSM I giăng ra quanh chủ đề Sprint Planning.