Mở đầu — vì sao bài này quan trọng
Nếu bạn đang ôn thi PSPO I, hãy ghi nhớ điều này: Sprint Planning là sự kiện mà Product Owner (PO) "tỏa sáng" nhiều nhất trong cả Sprint. Đây là nơi PO không chỉ ngồi nghe Developers ước lượng, mà chủ động đặt ra câu hỏi định hướng cho cả Sprint: "Sprint này sẽ tạo ra giá trị gì cho sản phẩm và cho người dùng?"
Scrum Guide 2020 đã tái cấu trúc Sprint Planning thành 3 chủ đề (topics) rõ ràng — và đây là một trong những phần được hỏi nhiều nhất trong đề thi PSPO I. Rất nhiều thí sinh trượt câu hỏi về Sprint Planning không phải vì không thuộc lý thuyết, mà vì hiểu sai ai chịu trách nhiệm topic nào, và nhầm lẫn giữa "ai quyết định khối lượng công việc" với "ai quyết định giá trị".
Trong bài này, chúng ta sẽ đi sâu vào 3 topics của Sprint Planning từ góc nhìn của PO: Why (vì sao Sprint này có giá trị), What (chọn những gì vào Sprint), và How (làm như thế nào). Tôi sẽ làm rõ ranh giới accountability cực kỳ tinh tế giữa PO và Developers — thứ mà đề thi rất thích "gài bẫy". Lưu ý: bài này tập trung riêng vào cấu trúc và 3 topics của Sprint Planning; các sự kiện khác như Daily Scrum, Sprint Review hay cách craft Sprint Goal sẽ được bàn ở những bài riêng.
Khái niệm cốt lõi
Sprint Planning là sự kiện khởi đầu cho mỗi Sprint, nơi cả Scrum Team cùng nhau xác định công việc cần làm. Theo Scrum Guide 2020, sự kiện này có timebox tối đa 8 giờ cho Sprint một tháng, và ngắn hơn tương ứng với Sprint ngắn hơn (ví dụ Sprint 2 tuần thường lên kế hoạch trong khoảng 4 giờ).
Người tham gia bắt buộc là toàn bộ Scrum Team: Product Owner, Scrum Master và Developers. PO có thể mời thêm người khác để tư vấn nếu cần (ví dụ chuyên gia kỹ thuật, đại diện khách hàng), nhưng đây không phải sự kiện của riêng ai — đó là công việc tập thể.
Đầu vào (input) của Sprint Planning gồm: Product Backlog đã được refine, Increment gần nhất, năng lực (capacity) dự kiến của Developers trong Sprint, và hiệu suất quá khứ. Đầu ra là Sprint Backlog, bao gồm: Sprint Goal (mục tiêu Sprint — why), tập hợp các Product Backlog Item được chọn (what), và kế hoạch để hoàn thành chúng (how).
Topic 1 — Why is this Sprint valuable? (Vì sao Sprint này có giá trị?)
Đây là topic mở màn và là nơi PO giữ vai trò trung tâm. PO đề xuất (propose) cách mà sản phẩm có thể tăng giá trị và tính hữu ích (value and utility) trong Sprint này. Sau đó, cả Scrum Team cùng hợp tác để định nghĩa một Sprint Goal — mục tiêu truyền đạt vì sao Sprint này đáng giá đối với các bên liên quan.
Điểm mấu chốt cần nhớ cho kỳ thi: Sprint Goal phải được hoàn thiện (finalized) trước khi kết thúc Sprint Planning, và đó là sản phẩm của sự hợp tác — PO khởi xướng, nhưng cả team cùng định hình. 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, cô đọng, tạo sự gắn kết và tập trung cho cả Sprint.
Topic 2 — What can be Done this Sprint? (Có thể hoàn thành những gì?)
Qua thảo luận với PO, Developers chọn các item từ Product Backlog để đưa vào Sprint hiện tại. Đây là điểm cực kỳ hay bị nhầm trong đề thi: PO sắp xếp thứ tự (ordering) Product Backlog và làm rõ giá trị của từng item, nhưng chính Developers — chứ không phải PO hay Scrum Master — là người quyết định bao nhiêu công việc họ có thể đưa vào Sprint.
PO không được "nhồi" thêm việc, không được ra lệnh "phải làm xong cả 12 item này". Developers dựa trên năng lực, hiệu suất quá khứ, Definition of Done và độ phức tạp để cam kết một khối lượng hợp lý. Càng hiểu rõ về sản phẩm và Sprint trước, dự báo (forecast) của họ càng chính xác.
Topic 3 — How will the chosen work get done? (Làm như thế nào?)
Với mỗi Product Backlog Item đã chọn, Developers lên kế hoạch về cách biến nó thành một Increment đạt chuẩn Definition of Done. Họ thường phân rã (decompose) các item thành các đơn vị công việc nhỏ hơn, lý tưởng là nhỏ tới mức có thể hoàn thành trong một ngày hoặc ít hơn.
Topic này hoàn toàn thuộc về Developers. Cách họ tự tổ chức và phân chia công việc là quyền của họ — không ai khác trong Scrum Team được áp đặt. PO và Scrum Master không cần (và không nên) chỉ đạo từng task kỹ thuật. Tuy nhiên PO vẫn ngồi đó để trả lời câu hỏi làm rõ về phạm vi và giá trị nếu Developers cần.
Ba topic kết hợp tạo ra Sprint Backlog
Khi kết thúc, ba topic này gộp lại thành Sprint Backlog: Sprint Goal (cam kết — commitment của Sprint Backlog) + các item được chọn + kế hoạch thực thi. Một mẹo nhớ đơn giản: Why → What → How, tương ứng Goal → Selected Items → Plan.
Tình huống thực tế
Ví dụ 1 — Tiki và bài học "PO không quyết định khối lượng"
Hãy tưởng tượng 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ử như Tiki, gồm 1 PO, 1 Scrum Master và 5 Developers, làm Sprint 2 tuần (timebox Sprint Planning khoảng 4 giờ).
Trong Topic 1, PO đề xuất: "Sprint này tôi muốn tăng tỷ lệ hoàn tất thanh toán bằng cách hỗ trợ thêm ví điện tử MoMo, vì 30% giỏ hàng bị bỏ dở do thiếu phương thức thanh toán quen thuộc." Cả team thảo luận và chốt Sprint Goal: "Người dùng có thể thanh toán bằng MoMo end-to-end trên app."
Sang Topic 2, PO mang vào 9 item đã refine. PO rất muốn làm hết cả 9 để "ra mắt cho hoành tráng". Nhưng Developers, nhìn vào năng lực thực tế (một thành viên nghỉ phép 3 ngày) và độ phức tạp tích hợp API MoMo, chỉ cam kết 5 item cốt lõi đủ để đạt Sprint Goal. PO ban đầu hơi khó chịu, nhưng Scrum Master nhắc lại: quyết định khối lượng là của Developers.
Bài học: PO định hướng giá trị và thứ tự ưu tiên, nhưng dung lượng cam kết là quyền của Developers. Nếu PO ép thêm việc, Sprint sẽ rủi ro không đạt được cả Sprint Goal lẫn các item phụ. Trong đề thi PSPO I, đáp án đúng luôn là: "Developers select how many items."
Ví dụ 2 — Startup fintech ở Singapore và Topic 1 bị bỏ quên
Một startup fintech tại Singapore có đội Scrum mới chuyển từ "chạy task" sang Scrum thực thụ. Trong vài Sprint đầu, họ làm Sprint Planning theo kiểu cũ: PO đọc danh sách backlog, Developers nhận task, rồi giải tán. Họ bỏ qua hoàn toàn Topic 1 — không bao giờ đặt câu hỏi "Why is this Sprint valuable?".
Hậu quả: sau 3 Sprint, đội giao đủ feature nhưng stakeholder phàn nàn "chẳng thấy sản phẩm tiến đến đâu". Lý do là mỗi Sprint là một mớ task rời rạc, không có Sprint Goal gắn kết. Khi giữa Sprint phát sinh sự cố (một API đối tác đổi spec), team không biết phải hy sinh task nào vì không có mục tiêu chung để bám vào.
Scrum Master can thiệp: từ Sprint kế tiếp, họ luôn bắt đầu Sprint Planning bằng việc PO trình bày đề xuất giá trị và cả team cùng craft một Sprint Goal duy nhất. Ngay lập tức, các cuộc thảo luận giữa Sprint trở nên dễ dàng — khi có sự cố, team hỏi "việc này có giúp đạt Sprint Goal không?" và ra quyết định nhanh chóng.
Bài học: Topic 1 không phải thủ tục hình thức. Sprint Goal là "kim chỉ nam" giúp team đưa ra quyết định đánh đổi (trade-off) trong suốt Sprint, và giúp stakeholder hiểu được Sprint này hướng tới điều gì.
Ví dụ 3 — Đội outsourcing tại TP.HCM và ranh giới Topic 3
Một công ty gia công phần mềm ở TP.HCM nhận dự án cho khách hàng Nhật. PO (đại diện phía khách) có thói quen chỉ đạo rất chi tiết: trong Sprint Planning, anh ấy yêu cầu "task này dùng thư viện X", "module kia phải tách thành 3 file".
Developers cảm thấy bị tước quyền tự quản (self-management). Scrum Master tổ chức một buổi trao đổi để làm rõ: trong Topic 3 — How — cách thực hiện công việc kỹ thuật là quyền của Developers. PO hoàn toàn được quyền làm rõ yêu cầu và acceptance criteria (giá trị, đầu ra mong đợi), nhưng không được áp đặt cách triển khai.
Sau khi điều chỉnh, PO tập trung mạnh vào Topic 1 và Topic 2 (giá trị, ưu tiên, làm rõ phạm vi), nhường Topic 3 cho Developers. Chất lượng kế hoạch tăng lên vì Developers, là người trực tiếp code, hiểu rõ nhất cách phân rã công việc.
Bài học: Ranh giới giữa "what/why" (PO) và "how" (Developers) là một chủ đề kinh điển trong PSPO I. PO định nghĩa giá trị và đầu ra; Developers quyết định cách đạt được.
Hướng dẫn từng bước
Dưới đây là cách một PO nên chuẩn bị và tham gia Sprint Planning hiệu quả:
- Trước buổi họp — chuẩn bị backlog. Đảm bảo các item ở đầu Product Backlog đã được refine đủ rõ: có mô tả, giá trị, acceptance criteria, và đủ nhỏ để Developers có thể đưa vào Sprint. Việc refine này diễn ra liên tục, không nên dồn vào Sprint Planning.
- Trước buổi họp — hình thành giả thuyết về giá trị. PO suy nghĩ trước: "Nếu Sprint này thành công, sản phẩm sẽ tăng giá trị ở điểm nào?" Đây là nguyên liệu cho Topic 1. Đừng chờ đến lúc họp mới nghĩ.
- Topic 1 — đề xuất và cùng craft Sprint Goal. Trình bày đề xuất giá trị, rồi cùng cả team biến nó thành một Sprint Goal cô đọng. Nhớ: PO đề xuất, cả team định hình, và phải chốt trước khi tan họp.
- Topic 2 — làm rõ giá trị và thứ tự, để Developers chọn khối lượng. PO giải thích vì sao item nào quan trọng, trả lời câu hỏi, nhưng tuyệt đối không quyết định "phải làm bao nhiêu". Đó là việc của Developers.
- Topic 3 — sẵn sàng giải đáp, không chỉ đạo. Khi Developers lập kế hoạch thực thi, PO ngồi cùng để làm rõ phạm vi nếu được hỏi, nhưng để Developers tự tổ chức công việc kỹ thuật.
- Kết thúc — xác nhận Sprint Backlog. Đảm bảo có đủ ba thành phần: Sprint Goal + item được chọn + kế hoạch. Cả team đồng thuận rằng họ có thể đạt Sprint Goal.
Lỗi thường gặp & mẹo
- Lỗi: PO ép khối lượng công việc. Đây là sai lầm phổ biến nhất và là cái bẫy kinh điển trong PSPO I. Hãy nhớ tuyệt đối: Developers quyết định bao nhiêu việc vào Sprint.
- Lỗi: Bỏ qua Topic 1. Lập kế hoạch mà không có Sprint Goal khiến Sprint trở thành danh sách task rời rạc. Luôn bắt đầu bằng "Why".
- Lỗi: PO chỉ đạo cách làm (Topic 3). PO định nghĩa what/why; cách thực hiện kỹ thuật thuộc về Developers. Vi phạm điều này là phá vỡ tính self-managing của team.
- Lỗi: Coi Sprint Planning là nơi refine backlog. Nếu đến lúc họp mà item vẫn mơ hồ, buổi planning sẽ kéo dài và kém hiệu quả. Refine phải diễn ra trước đó, liên tục trong Sprint.
- Mẹo nhớ cho kỳ thi: Three topics = Why (PO đề xuất, team craft Sprint Goal) → What (Developers chọn item) → How (Developers lập kế hoạch). Đầu ra = Sprint Backlog (Goal + Items + Plan).
- Mẹo về timebox: Tối đa 8 giờ cho Sprint 1 tháng, ngắn hơn cho Sprint ngắn hơn. Đây là giới hạn trên, không phải thời lượng bắt buộc — nếu xong sớm thì kết thúc sớm.
Bài tập thực hành
- Phân vai accountability: Với mỗi tình huống sau, xác định ai chịu trách nhiệm chính: (a) đề xuất giá trị Sprint, (b) chốt số lượng item đưa vào Sprint, (c) quyết định kiến trúc code để hoàn thành một item, (d) hoàn thiện Sprint Goal. (Gợi ý: a → PO đề xuất; b → Developers; c → Developers; d → cả team.)
- Viết một Sprint Goal: Cho bối cảnh: sản phẩm là app giao đồ ăn, dữ liệu cho thấy 25% người dùng bỏ giữa chừng vì thời gian giao hàng không rõ ràng. Hãy viết một đề xuất giá trị (Topic 1) và một Sprint Goal cô đọng (một câu).
- Nhận diện anti-pattern: Trong một buổi Sprint Planning, PO nói: "Sprint này cả team phải làm xong 15 item này, tôi đã hứa với sếp rồi." Hãy chỉ ra (a) PO đã vi phạm topic nào, (b) cách Scrum Master nên can thiệp.
- Tự kiểm tra timebox: Đội của bạn chạy Sprint 3 tuần. Theo Scrum Guide, timebox tối đa cho Sprint Planning là bao nhiêu? (Gợi ý: 8 giờ tỷ lệ cho 1 tháng → khoảng 6 giờ cho 3 tuần.)
Tóm tắt
Sprint Planning trong Scrum Guide 2020 được cấu trúc thành 3 topics: Why (vì sao Sprint này có giá trị), What (chọn gì vào Sprint), và How (làm như thế nào). Từ góc nhìn PO, điều quan trọng nhất cần khắc cốt ghi tâm:
- Topic 1 (Why): PO đề xuất cách sản phẩm tăng giá trị; cả Scrum Team cùng craft Sprint Goal, và nó phải được chốt trước khi kết thúc planning.
- Topic 2 (What): PO làm rõ giá trị và thứ tự; Developers quyết định khối lượng công việc đưa vào Sprint.
- Topic 3 (How): Developers tự lập kế hoạch thực thi và phân rã công việc; PO làm rõ phạm vi khi được hỏi, không áp đặt.