Mở đầu — vì sao bài này quan trọng
Nếu bạn coi Scrum như một cỗ máy, thì năm sự kiện (Scrum Events) chính là những bánh răng tạo nên nhịp đập của cả khung làm việc. Không có chúng, Scrum chỉ còn là một danh sách công việc với vài cái tên vai trò nghe sang trọng. Có chúng, nhưng dùng sai, bạn lại rơi vào cái bẫy "Zombie Scrum" — vẫn họp đầy đủ nhưng chẳng có sự thanh tra (inspection) và thích ứng (adaptation) thực sự nào diễn ra.
Với một Product Owner (PO), năm sự kiện này đặc biệt quan trọng vì hai lý do. Thứ nhất, đây là những điểm chạm chính thức nơi PO bảo vệ giá trị (value) của sản phẩm — bạn không thể "tối đa hóa giá trị" từ phòng làm việc riêng, bạn làm điều đó tại những cuộc gặp này. Thứ hai, đề thi PSPO I rất hay đặt câu hỏi xoáy vào việc "PO làm gì, không làm gì, được quyền gì tại từng sự kiện". Rất nhiều thí sinh mất điểm oan vì lẫn lộn: tưởng PO chủ trì Daily Scrum, tưởng PO là người duy nhất quyết định độ dài Sprint, tưởng Sprint Review là buổi nghiệm thu để "duyệt" sản phẩm.
Bài này sẽ giúp bạn nhìn năm sự kiện như một hệ thống các vòng lặp thanh tra — thích ứng, và hiểu rõ vai trò của PO trong từng vòng lặp đó. Lưu ý: bài này tập trung vào bức tranh tổng thể năm sự kiện và vị trí của PO. Chi tiết sâu của từng sự kiện (Sprint Planning, Daily, Review, Retrospective) sẽ được mổ xẻ riêng ở các bài sau, nên ở đây tôi sẽ đi vào tư duy và mối liên kết giữa chúng.
Khái niệm cốt lõi
Scrum Guide 2020 định nghĩa đúng 5 sự kiện, và điều quan trọng đầu tiên cần nhớ: Sprint là một sự kiện, đồng thời là cái chứa (container) cho bốn sự kiện còn lại. Đây là điểm gây nhầm lẫn kinh điển. Nhiều người chỉ kể bốn "buổi họp" (Planning, Daily, Review, Retro) và quên mất Sprint. Trong bài thi, nếu câu hỏi là "Scrum có bao nhiêu sự kiện?", đáp án là 5, không phải 4.
1. Sprint — container của mọi thứ
Sprint là một khoảng thời gian cố định, kéo dài một tháng hoặc ngắn hơn (thường 1–4 tuần), trong đó mọi công việc để tạo ra giá trị diễn ra. Đặc tính then chốt:
- Sprint mới bắt đầu ngay khi Sprint trước kết thúc — không có khoảng trống.
- Trong Sprint: không thay đổi nào làm tổn hại Sprint Goal; chất lượng không bị giảm; Product Backlog được làm mịn (refine) khi cần; phạm vi (scope) có thể được làm rõ và đàm phán lại giữa PO và Developers khi đã học hỏi thêm.
- Sprint giới hạn rủi ro chi phí ở mức một khoảng thời gian — nếu đi sai hướng, bạn chỉ mất tối đa độ dài một Sprint.
2. Sprint Planning — mở màn Sprint
Sprint Planning khởi động Sprint bằng cách trả lời ba câu hỏi (3 topics): Tại sao Sprint này có giá trị? (Why), Có thể làm được gì? (What), và Công việc sẽ được hoàn thành thế nào? (How). Sản phẩm đầu ra là Sprint Goal và Sprint Backlog.
Vai trò PO: PO mang đến mục tiêu sản phẩm và các hạng mục Product Backlog quan trọng nhất, giải thích chúng phục vụ Product Goal ra sao, và cùng cả nhóm "đề xuất" Sprint Goal (Sprint Goal là cam kết của cả Scrum Team, không phải PO áp đặt). PO làm rõ phạm vi, đàm phán với Developers về việc đưa cái gì vào. Nhưng Developers mới là người quyết định họ có thể đưa bao nhiêu việc vào Sprint — PO không được ép số lượng.
3. Daily Scrum — sự kiện của Developers
Daily Scrum là buổi 15 phút mỗi ngày, dành cho Developers để thanh tra tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog. Đây là điểm dễ sai nhất trong nhận thức của PO Việt Nam.
Vai trò PO: Daily Scrum là sự kiện của Developers, cho Developers. PO không bắt buộc tham dự, không chủ trì, không dùng nó như buổi báo cáo tiến độ cho mình. Nếu PO (hoặc người ngoài) có mặt, họ chỉ là khách, không được biến nó thành cuộc "kiểm điểm". Nếu Developers cần làm rõ một hạng mục backlog, họ có thể trao đổi với PO — nhưng ngoài khung 15 phút đó.
4. Sprint Review — phiên làm việc cộng tác
Sprint Review diễn ra cuối Sprint để thanh tra Increment (kết quả) và điều chỉnh Product Backlog. Quan trọng: đây không phải buổi nghiệm thu/duyệt sản phẩm hay buổi demo một chiều. Scrum Guide 2020 gọi đây là một working session — phiên làm việc cộng tác giữa Scrum Team và các bên liên quan (stakeholders).
Vai trò PO: Đây là sự kiện "sân nhà" của PO. PO mời và làm việc với stakeholders, thu thập phản hồi về thị trường và nhu cầu thay đổi, từ đó điều chỉnh Product Backlog cho Sprint tiếp theo. PO dùng buổi này để kết nối những gì nhóm vừa làm với hướng đi sản phẩm. Lưu ý: PO không "phê duyệt" hay "nghiệm thu" từng hạng mục tại đây như một người gác cổng — chất lượng "Done" đã được định nghĩa bởi Definition of Done.
5. Sprint Retrospective — đóng Sprint
Retrospective khép lại Sprint, là nơi Scrum Team thanh tra chính cách mình làm việc (con người, tương tác, quy trình, công cụ, Definition of Done) và lập kế hoạch cải tiến.
Vai trò PO: PO là một thành viên đầy đủ của Scrum Team, nên tham gia Retrospective. Đây không phải sự kiện chỉ dành cho Developers. PO đóng góp góc nhìn về cách cộng tác với Developers, cách refinement diễn ra, cách quản lý backlog có thể tốt hơn.
Sợi dây xuyên suốt: empiricism
Cả năm sự kiện tồn tại để tạo ra các vòng lặp thanh tra (inspect) và thích ứng (adapt) đều đặn — nền tảng của thực nghiệm (empiricism). Sprint Planning tạo cam kết, Daily Scrum thanh tra hàng ngày, Sprint Review thanh tra sản phẩm với thị trường, Retrospective thanh tra quy trình. Mỗi sự kiện được đóng khung trong một timebox (giới hạn thời gian) để tránh lãng phí. Khi bạn cắt bỏ hay làm hời hợt một sự kiện, bạn đang đục thủng một vòng lặp phản hồi và làm mù khung thực nghiệm.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "Daily Scrum là buổi báo cáo cho PO"
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ử lớn ở TP.HCM (gọi là đội "Checkout"). Anh Phong là PO. Mỗi sáng 9h, anh đứng đầu phòng, gọi tên từng developer hỏi "Hôm qua làm gì, hôm nay làm gì, có chậm không?". Buổi Daily kéo dài 35 phút, các bạn dev trả lời như đang bị kiểm tra bài, không khí căng thẳng.
Diễn giải: Anh Phong đã biến Daily Scrum thành buổi báo cáo tiến độ cho PO — sai hoàn toàn với tinh thần Scrum. Daily là sự kiện của Developers để họ tự thanh tra tiến độ hướng tới Sprint Goal và tự lập kế hoạch ngày, không phải để PO giám sát. Hệ quả: Developers mất tính tự quản (self-managing), thông tin chỉ chảy một chiều lên PO, và không ai thực sự cộng tác để vượt qua trở ngại.
Bài học: PO nên rút lui khỏi vai trò chủ trì Daily. Nếu cần cập nhật, anh Phong có thể nhìn vào bảng Sprint Backlog hoặc trao đổi riêng với Developers khi họ cần làm rõ backlog. Khi đội Checkout thử bỏ vai trò "điểm danh" của PO, các bạn dev bắt đầu tự nói chuyện với nhau, thời gian họp giảm còn 12 phút, và số việc bị "kẹt" được phát hiện sớm hơn vì chính người trong cuộc nêu ra.
Tình huống 2 — Một startup fintech ở Singapore và Sprint Review biến thành buổi nghiệm thu
Một startup fintech (gọi là PayLah-clone) có Sprint 2 tuần. Cuối mỗi Sprint, họ tổ chức Sprint Review nhưng thực chất là buổi để Giám đốc sản phẩm "duyệt" từng tính năng: bật từng màn hình lên, sếp gật đầu thì "pass", lắc đầu thì "reject" và yêu cầu sửa. Stakeholders ngồi im lặng quan sát, gần như không ai cho ý kiến về thị trường hay hướng đi.
Diễn giải: Họ đã hiểu sai Sprint Review thành một cổng phê duyệt (approval gate). Theo Scrum Guide 2020, Sprint Review là phiên làm việc cộng tác để thanh tra Increment và điều chỉnh Product Backlog dựa trên phản hồi về thị trường và tiến triển kinh doanh. Việc một tính năng có "Done" hay không lẽ ra phải dựa trên Definition of Done được thống nhất từ trước, chứ không phải cảm tính của sếp tại buổi họp. Cách làm này khiến chất lượng trở nên tùy hứng và stakeholders bị động.
Bài học: PO cần tái thiết kế buổi này thành nơi đối thoại hai chiều: trình bày Increment đã đạt DoD, rồi mời stakeholders thảo luận "Với những gì vừa thấy, thị trường đang đòi hỏi gì? Ta nên ưu tiên gì tiếp theo?". Đầu ra là một Product Backlog được điều chỉnh, không phải một danh sách "pass/reject". Sau khi đổi cách, đội này phát hiện một tính năng họ định làm tiếp đã không còn cần thiết vì stakeholder bên vận hành nêu một thay đổi về quy định — họ tiết kiệm được gần một Sprint công sức.
Tình huống 3 — Sản phẩm SaaS nội bộ và quyền hủy Sprint của PO
Một công ty phần mềm ở Hà Nội đang xây một module CRM cho khách hàng lớn. Đầu Sprint, Sprint Goal là "Cho phép khách đồng bộ danh bạ từ hệ thống cũ sang module mới". Đến ngày thứ 3 của Sprint 2 tuần, khách hàng lớn nhất đột ngột hủy yêu cầu đồng bộ vì họ đổi chiến lược, khiến toàn bộ Sprint Goal mất ý nghĩa kinh doanh.
Diễn giải: Đây chính xác là tình huống mà quyền Cancel Sprint của PO được thiết kế cho. Khi Sprint Goal trở nên lỗi thời, tiếp tục làm chỉ là lãng phí. PO — và chỉ PO — có thẩm quyền hủy Sprint. Nhiều PO Việt Nam ngại dùng quyền này vì sợ "mất mặt" hay nghĩ hủy Sprint là thất bại. Thực ra, không hủy mới là lãng phí.
Bài học: Hủy Sprint là một công cụ hợp lệ, hiếm dùng nhưng quan trọng. Sau khi hủy, các hạng mục đã "Done" vẫn được xem xét, phần còn lại quay về Product Backlog, và nhóm bước vào một Sprint Planning mới. Trong tình huống này, PO đã hủy Sprint, đề xuất Sprint Goal mới hướng tới một nhu cầu khác đã được xác thực, và tránh được hai tuần làm việc vô ích.
Hướng dẫn từng bước
Dưới đây là cách một PO định vị bản thân qua một vòng Sprint hoàn chỉnh:
- Trước/đầu Sprint — chuẩn bị cho Sprint Planning. Đảm bảo Product Backlog đã được làm mịn đủ để đỉnh backlog rõ ràng. Mang đến một mục tiêu kinh doanh khả thi cho Sprint, gắn với Product Goal.
- Tại Sprint Planning — đồng kiến tạo Sprint Goal. Giải thích "tại sao" (Why), đề xuất các hạng mục giá trị nhất, đàm phán phạm vi. Để Developers quyết định khối lượng họ nhận. Đừng áp số liệu.
- Trong Sprint — sẵn sàng hỗ trợ, không micromanage. Không chủ trì Daily Scrum. Khi Developers cần làm rõ một hạng mục, hãy có mặt và trả lời nhanh. Tiếp tục refine backlog cho Sprint sau (dưới 10% sức nhóm là một mốc tham khảo). Theo dõi xem Sprint Goal còn ý nghĩa không.
- Cuối Sprint — chủ trì tinh thần Sprint Review. Mời đúng stakeholders. Trình bày Increment đã đạt DoD. Khơi gợi đối thoại về thị trường. Cập nhật Product Backlog ngay dựa trên phản hồi.
- Đóng Sprint — tham gia Retrospective như thành viên đầy đủ. Đóng góp góc nhìn về cộng tác và quản lý backlog. Cam kết một cải tiến cụ thể cho Sprint tới.
- Khi Sprint Goal lỗi thời — cân nhắc quyền Cancel Sprint. Đây là quyết định của riêng PO, dùng khi và chỉ khi mục tiêu thực sự không còn giá trị.
Lỗi thường gặp & mẹo
- Đếm thiếu sự kiện. Nhớ chắc: có 5 sự kiện, và Sprint là một sự kiện kiêm container. Đề thi rất thích bẫy chỗ này.
- Tưởng PO chủ trì Daily Scrum. Sai. Daily là của Developers. PO không bắt buộc dự, không được biến nó thành buổi báo cáo.
- Coi Sprint Review là buổi nghiệm thu/demo một chiều. Sai. Đó là phiên làm việc cộng tác để điều chỉnh Product Backlog dựa trên phản hồi thị trường.
- Bỏ Sprint Retrospective vì "PO không liên quan". Sai. PO là thành viên Scrum Team, tham gia đầy đủ.
- Nghĩ rằng ai cũng có quyền hủy Sprint. Sai. Chỉ PO có quyền Cancel Sprint.
- Lẫn lộn "ai quyết khối lượng công việc trong Sprint". Developers quyết, không phải PO. PO quyết cái gì quan trọng nhất, Developers quyết làm được bao nhiêu.
- Mẹo timebox: Sprint Planning tối đa 8 giờ cho Sprint một tháng; Daily 15 phút; Sprint Review tối đa 4 giờ; Retrospective tối đa 3 giờ — đều cho Sprint một tháng và rút ngắn tương ứng với Sprint ngắn hơn. Nhớ "đây là giới hạn tối đa, không phải thời lượng cố định".
- Mẹo tư duy: Với mỗi sự kiện, tự hỏi "Sự kiện này thanh tra cái gì, và thích ứng cái gì?". Nếu trả lời được, bạn đã nắm được linh hồn của nó.
Bài tập thực hành
- Lập bảng inspect–adapt. Vẽ một bảng 5 dòng (5 sự kiện). Với mỗi sự kiện, điền: (a) thanh tra cái gì, (b) thích ứng cái gì, (c) vai trò cụ thể của PO. So sánh với phần Khái niệm cốt lõi.
- Tự kiểm tra với 5 câu đúng/sai:
- Phân tích đội của bạn. Quan sát một Sprint thật (hoặc tưởng tượng một đội bạn từng thấy). Chỉ ra một sự kiện đang bị làm sai tinh thần Scrum, mô tả triệu chứng, và đề xuất một thay đổi cụ thể PO có thể làm.
- Đóng vai. Viết 3 câu PO sẽ nói ở đầu Sprint Review để biến nó từ buổi demo một chiều thành phiên đối thoại cộng tác.
Tóm tắt
Scrum có 5 sự kiện: Sprint (container), Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Tất cả tồn tại để tạo các vòng lặp thanh tra — thích ứng đều đặn, phục vụ khung thực nghiệm. Với PO, hãy ghi nhớ định vị riêng ở từng sự kiện: tại Sprint bạn nắm quyền hủy Sprint và bảo vệ giá trị; tại Sprint Planning bạn đồng kiến tạo Sprint Goal nhưng để Developers quyết khối lượng; Daily Scrum là của Developers, bạn không chủ trì; Sprint Review là sân nhà của bạn — một phiên làm việc cộng tác để điều chỉnh Product Backlog, không phải buổi nghiệm thu; Retrospective bạn tham gia đầy đủ như một thành viên Scrum Team. Nắm vững năm vị trí này, bạn vừa làm PO hiệu quả hơn, vừa né được hàng loạt câu bẫy kinh điển của kỳ thi PSPO I.