Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười Product Owner (PO) "mới vào nghề" rằng họ làm gì trong các Sprint Event, có lẽ tám người sẽ trả lời đại loại: "Em ngồi nghe, có gì hỏi thì trả lời." Đó chính là cái bẫy lớn nhất. Trong PSPO I và trong thực tế, các Sprint Event không phải là "cuộc họp" để bạn tham dự cho có mặt — chúng là những điểm chạm (touchpoint) quan trọng nhất để PO bảo vệ giá trị (value) của sản phẩm.
Scrum chỉ có 5 sự kiện: Sprint (sự kiện bao trùm), Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective. Mỗi sự kiện được Scrum Guide thiết kế để tạo ra cơ hội inspect (thanh tra) và adapt (thích nghi). Vai trò của PO trong từng sự kiện rất khác nhau — có sự kiện bạn là người chủ động dẫn dắt câu chuyện "tại sao", có sự kiện bạn gần như chỉ là khách mời, và có sự kiện bạn thậm chí không bắt buộc tham dự.
Đề thi PSPO I cực kỳ hay "gài" thí sinh ở điểm này. Một câu hỏi kinh điển: "Ai sở hữu Daily Scrum?" — và rất nhiều người sai vì nghĩ PO phải có mặt và điều hành. Bài này sẽ giúp bạn nắm chắc vai trò của PO trong từng Sprint Event, đủ để vừa trả lời đúng đề thi vừa hành xử đúng ngoài thực tế.
Lưu ý: bài này tập trung vào góc nhìn tổng quan của PO xuyên suốt 5 sự kiện và những ranh giới vai trò. Chi tiết chuyên sâu về cơ chế từng sự kiện (3 chủ đề của Sprint Planning, cách craft Sprint Goal, cấu trúc Sprint Review...) sẽ được mổ xẻ ở các bài 16–20 và 51. Ở đây, mục tiêu là bạn hiểu được "PO đứng ở đâu, làm gì, và quan trọng nhất là KHÔNG được làm gì" trong mỗi sự kiện.
Khái niệm cốt lõi
Sprint — sự kiện bao trùm (the container)
Trước hết, đừng quên rằng Sprint chính là một sự kiện, và là sự kiện chứa tất cả các sự kiện còn lại. Sprint là một timebox cố định (tối đa 1 tháng) tạo ra sự nhất quán. Trong Sprint, có một nguyên tắc mà PO phải khắc cốt ghi tâm: không được thay đổi nào gây nguy hiểm cho Sprint Goal; phạm vi (scope) có thể được làm rõ và đàm phán lại với Developers khi hiểu biết tăng lên.
Vai trò PO ở cấp Sprint: bạn là người duy nhất có quyền hủy Sprint (cancel the Sprint) nếu Sprint Goal trở nên lỗi thời. Đây là quyền độc quyền, không chia sẻ với ai (chi tiết ở Bài 38).
Sprint Planning — nơi PO tỏa sáng
Đây là sự kiện mà PO đóng vai trò chủ động nhất. Scrum Guide 2020 chia Sprint Planning thành 3 chủ đề:
- Why (Tại sao Sprint này có giá trị?) — PO đề xuất Sprint Goal, làm rõ tại sao Sprint này đáng để team đầu tư. Đây là trách nhiệm trọng tâm của PO.
- What (Có thể hoàn thành cái gì?) — Cả Scrum Team thảo luận. PO trình bày các Product Backlog Item (PBI) ưu tiên cao nhất, trả lời câu hỏi, làm rõ. Nhưng Developers mới là người quyết định họ kéo bao nhiêu vào Sprint.
- How (Làm như thế nào?) — Hầu như thuộc về Developers. PO thường không tham gia sâu phần này, nhưng vẫn ở đó để clarify khi cần.
Daily Scrum — sự kiện của Developers
Đây là cái bẫy phổ biến nhất. Daily Scrum là sự kiện CỦA Developers, DÀNH CHO Developers. Mục đích: Developers thanh tra tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog.
Vai trò PO: PO không bắt buộc tham dự. Nếu PO (hoặc Scrum Master) có tham gia với tư cách là Developer đang làm việc trong Sprint Backlog item, họ tham gia như một Developer. Nhưng PO không điều hành, không báo cáo, không biến nó thành status update cho mình. Đây là điểm PSPO I hỏi đi hỏi lại.
Sprint Review — phiên làm việc cộng tác
Nhiều người tưởng Sprint Review là "buổi demo" để PO trình diễn cho sếp xem. Sai. Scrum Guide 2020 gọi nó là a working session — phiên làm việc cộng tác giữa Scrum Team và stakeholders.
Vai trò PO: PO là người mời và kết nối stakeholders, dẫn dắt cuộc trao đổi về Increment đã làm được, thu thập phản hồi, và cùng mọi người thảo luận xem nên làm gì tiếp theo. Kết quả của Sprint Review là Product Backlog được điều chỉnh dựa trên thực tế thị trường và phản hồi. PO là người chịu trách nhiệm cập nhật đó.
Lưu ý quan trọng: Sprint Review không phải là cổng phê duyệt (approval gate). Increment đã "Done" rồi (theo Definition of Done) trước khi vào Review. Stakeholders góp ý hướng đi, chứ không "nghiệm thu" để cho phép release.
Sprint Retrospective — PO là thành viên bình đẳng
Retrospective là nơi Scrum Team thanh tra về con người, tương tác, quy trình, công cụ và Definition of Done để cải tiến. PO tham gia với tư cách thành viên đầy đủ của Scrum Team — không phải khách mời, cũng không phải người ngoài.
Đây là điểm thay đổi quan trọng từ tư duy cũ: PO không "đứng ngoài quy trình". PO là một phần của team và cùng cải tiến cách làm việc.
Tình huống thực tế
Tình huống 1 — PO biến Sprint Planning thành "giao việc" (Tiki, fintech team)
Một team sản phẩm tại một công ty thương mại điện tử lớn ở Việt Nam (gọi là team Thanh Toán) có anh PO tên Hùng. Mỗi đầu Sprint, Hùng mang đến một danh sách 18 PBI và nói: "Sprint này mình phải xong hết 18 cái này, vì marketing đã hứa với đối tác rồi." Anh không đề xuất một Sprint Goal rõ ràng — chỉ là một đống task.
Hậu quả: Developers không có cảm giác sở hữu. Họ "đồng ý" cho qua chuyện, nhưng giữa Sprint khi gặp khó khăn kỹ thuật, không ai biết nên hy sinh cái gì vì không có Goal làm la bàn. Velocity tụt, 18 PBI chỉ xong 11, và quan trọng hơn — 11 cái xong rời rạc, không tạo thành một outcome hoàn chỉnh nào để demo.
Bài học: Vai trò PO trong Sprint Planning là làm rõ "tại sao" trước, đề xuất một Sprint Goal cô đọng — ví dụ "Cho phép khách hàng thanh toán bằng ví điện tử ở bước checkout" — rồi để Developers tự quyết kéo bao nhiêu PBI để đạt Goal đó. Sprint Goal là cam kết, danh sách PBI là forecast (dự báo), không phải hợp đồng cứng.
Tình huống 2 — PO "lái" Daily Scrum (startup logistics, Singapore)
Tại một startup logistics ở Singapore, chị Linh là PO của một team 6 Developers. Vì nhiệt tình và sốt ruột với deadline, mỗi sáng chị đứng đầu phòng, gọi tên từng Developer: "Hôm qua em làm gì? Hôm nay làm gì? Có gì kẹt không?" — đúng kiểu một quản lý điểm danh.
Kết quả: Daily Scrum kéo dài 25–30 phút (đáng lẽ chỉ 15 phút), Developers trả lời chị thay vì trao đổi với nhau, và không khí giống "báo cáo sếp" hơn là tự tổ chức (self-management). Scrum Master nhận ra vấn đề và nhẹ nhàng trao đổi riêng với Linh.
Sau khi điều chỉnh: Linh rút lui khỏi vai trò điều hành. Chị vẫn ghé qua nghe một vài hôm để nắm tình hình, nhưng để Developers tự chạy. Daily Scrum trở về 15 phút, Developers chủ động chỉ ra "chỗ này đang block Sprint Goal, ai gỡ được không?".
Bài học: Daily Scrum thuộc về Developers. PO không sở hữu, không điều hành. Sự hiện diện quá mức của PO (hoặc Scrum Master) dễ giết chết tính self-managing của team. Đề PSPO I sẽ hỏi: "Trong Daily Scrum, PO nên làm gì?" — đáp án đúng thường là "không bắt buộc có mặt; nếu có thì không can thiệp vào việc của Developers".
Tình huống 3 — Sprint Review bị biến thành buổi nghiệm thu (ngân hàng số, Việt Nam)
Một ngân hàng số tại Việt Nam triển khai tính năng mở tài khoản online. Theo văn hóa cũ, mỗi cuối Sprint, team tổ chức một buổi "demo nghiệm thu": PO trình chiếu slide, các giám đốc khối ngồi nghe và "duyệt" cho phép tính năng được release. Nếu giám đốc chưa duyệt, Increment bị treo lại, dù nó đã đạt Definition of Done.
Vấn đề: buổi này biến thành một cổng phê duyệt một chiều. Stakeholders không thực sự cộng tác, chỉ phán xét. Phản hồi giá trị về thị trường (ví dụ "tỷ lệ rớt ở bước eKYC đang cao") không bao giờ được đưa ra vì không khí quá căng thẳng.
Sau khi PO được đào tạo lại, anh tái cấu trúc Sprint Review thành working session: mời cả người từ bộ phận chăm sóc khách hàng và rủi ro, cho họ thao tác thử trên Increment thật, và cùng thảo luận "với dữ liệu hiện tại, item nào nên lên đầu Backlog cho Sprint sau?". Kết quả là Product Backlog được điều chỉnh ngay trong buổi, dựa trên empiricism (kinh nghiệm thực chứng).
Bài học: Sprint Review là phiên cộng tác để inspect Increment và adapt Product Backlog — không phải cổng phê duyệt. PO là người dẫn dắt cộng tác và cập nhật Backlog, không phải người "xin chữ ký".
Hướng dẫn từng bước
Đây là khung hành động của PO qua một vòng Sprint:
Bước 1 — Trước Sprint Planning (chuẩn bị). Đảm bảo Product Backlog đã được refine đủ: các item đầu Backlog rõ ràng, đủ nhỏ, có thứ tự (order) hợp lý. PO chuẩn bị sẵn một ý tưởng về Sprint Goal khả thi, gắn với Product Goal.
Bước 2 — Trong Sprint Planning. Mở đầu bằng "Why": trình bày bối cảnh, đề xuất Sprint Goal. Sau đó cùng team xử lý "What": trình bày các PBI ưu tiên, trả lời mọi câu hỏi để Developers hiểu đúng yêu cầu. Để Developers quyết định khối lượng. Tránh xa phần "How" trừ khi được hỏi.
Bước 3 — Mỗi ngày trong Sprint. Sẵn sàng (available) để Developers hỏi khi cần làm rõ một PBI — nhưng đừng "đứng canh" Daily Scrum. Nếu tham gia, hãy giữ vai trò người cung cấp thông tin, không phải người điều hành. Song song, PO tiếp tục refine Backlog cho các Sprint tới.
Bước 4 — Chuẩn bị Sprint Review. Xác định stakeholders phù hợp cần mời (người dùng, khách hàng, bộ phận liên quan). Nắm rõ Increment đã đạt Done những gì, và những gì chưa.
Bước 5 — Trong Sprint Review. Dẫn dắt trao đổi về Increment, khuyến khích stakeholders thao tác và phản hồi thật. Thu thập insight về thị trường, ngân sách, thời gian. Cập nhật Product Backlog ngay tại chỗ nếu có thể.
Bước 6 — Trong Sprint Retrospective. Tham gia như một thành viên bình đẳng. Cởi mở (openness) chia sẻ những gì PO có thể làm tốt hơn, và lắng nghe phản hồi về cách cộng tác với team. Cam kết ít nhất một cải tiến cho Sprint sau.
Lỗi thường gặp & mẹo
Lỗi 1: Coi Sprint Planning là buổi giao việc. PO đẩy một danh sách task và yêu cầu "làm cho xong". Mẹo: luôn bắt đầu bằng Sprint Goal (Why), để Developers tự pull khối lượng.
Lỗi 2: Điều hành hoặc bắt Developers báo cáo trong Daily Scrum. Mẹo: nhớ câu thần chú "Daily Scrum là of/for/by Developers". PO không bắt buộc dự.
Lỗi 3: Biến Sprint Review thành demo một chiều hoặc cổng phê duyệt. Mẹo: gọi nó là working session. Cho stakeholders dùng thật, và rời buổi họp với Product Backlog đã được cập nhật.
Lỗi 4: PO vắng mặt ở Retrospective vì nghĩ "đó là việc quy trình của team". Sai — PO là thành viên đầy đủ. Mẹo: luôn tham dự, đóng góp thành thật.
Lỗi 5: Nhầm forecast với commitment. Số lượng PBI kéo vào Sprint là dự báo; Sprint Goal mới là cam kết. Đừng "chốt" cứng số PBI rồi đổ lỗi khi không xong (xem sâu hơn ở Bài 34).
Mẹo thi PSPO I: Khi gặp câu hỏi về Sprint Event, hãy tự hỏi ba điều: (1) Sự kiện này CỦA AI? (2) PO có BẮT BUỘC tham dự không? (3) Đầu ra (output) của sự kiện là gì? Trả lời được ba câu này, bạn loại được hầu hết đáp án sai.
Bài tập thực hành
- Phân loại quyền sở hữu. Lập một bảng 5 hàng (5 sự kiện) × 3 cột: "Ai sở hữu", "PO có bắt buộc dự không", "Đầu ra của sự kiện". Tự điền rồi đối chiếu Scrum Guide 2020.
- Viết lại Sprint Goal. Lấy danh sách 18 PBI rời rạc trong Tình huống 1, và tự viết một Sprint Goal duy nhất, cô đọng, thể hiện rõ "tại sao Sprint này có giá trị".
- Đóng vai sửa lỗi. Đọc lại Tình huống 2 (chị Linh lái Daily Scrum). Viết 3–4 câu bạn — với vai Scrum Master — sẽ nói riêng với PO để giúp họ điều chỉnh mà không làm tổn thương.
- Thiết kế Sprint Review. Bạn là PO của một app gọi xe. Liệt kê: ai bạn sẽ mời tham dự Sprint Review, bạn cho họ trải nghiệm Increment thế nào, và 3 câu hỏi mở bạn sẽ đặt để thu thập phản hồi giá trị.
- Câu hỏi tự kiểm tra (chọn đúng/sai): "PO phải phê duyệt từng item trong Daily Scrum trước khi Developers tiếp tục." — Giải thích vì sao đúng hoặc sai.
Tóm tắt
- Scrum có 5 sự kiện, mỗi sự kiện tạo cơ hội inspect & adapt; vai trò PO khác nhau ở mỗi sự kiện.
- Sprint Planning: PO chủ động nhất — đề xuất Sprint Goal (Why), trình bày và làm rõ PBI (What), nhưng Developers quyết khối lượng.
- Daily Scrum: của/cho/bởi Developers. PO không bắt buộc dự, không điều hành, không bắt báo cáo.
- Sprint Review: working session cộng tác với stakeholders, không phải demo hay cổng phê duyệt; đầu ra là Product Backlog được cập nhật — trách nhiệm của PO.
- Sprint Retrospective: PO tham gia bình đẳng như thành viên đầy đủ của Scrum Team.
- Sprint (sự kiện bao trùm): PO là người duy nhất có quyền hủy Sprint.
- Mẹo thi: với mỗi câu hỏi về sự kiện, xác định CỦA AI, PO có bắt buộc dự không, và ĐẦU RA là gì.