Mở đầu — vì sao bài này quan trọng
Nếu có một sự kiện Scrum bị hiểu sai nhiều nhất, đặc biệt ở Việt Nam, thì đó chính là Sprint Review. Trong rất nhiều công ty, Sprint Review bị biến thành một buổi "demo" hoành tráng: Developers trình chiếu slide, Product Owner đứng cạnh gật gù, sếp ngồi hàng đầu ghi điểm, và cuối buổi mọi người vỗ tay. Xong. Backlog không thay đổi gì, kế hoạch sản phẩm vẫn nguyên như cũ, và tuần sau lại làm tiếp những gì đã định từ ba tháng trước.
Đó không phải Sprint Review. Đó là show-and-tell — một buổi trình diễn một chiều.
Trong kỳ thi PSPO I, Scrum.org rất thích "gài" thí sinh ở đúng điểm này. Họ sẽ hỏi: "Mục đích chính của Sprint Review là gì?" và đưa ra các phương án nghe rất hợp lý như "để Product Owner phê duyệt công việc", "để demo Increment cho stakeholders", "để báo cáo tiến độ cho ban lãnh đạo". Tất cả đều SAI hoặc thiếu sót. Bản chất của Sprint Review nằm ở hai chữ: working session — một phiên làm việc cộng tác.
Với vai trò Product Owner, Sprint Review là một trong những sự kiện giá trị nhất của bạn trong cả Sprint. Đây là lúc bạn thu thập phản hồi trực tiếp từ những người thực sự dùng và trả tiền cho sản phẩm, là lúc bạn điều chỉnh Product Backlog dựa trên thực tế thị trường thay vì giả định. Nắm vững bài này, bạn vừa trả lời đúng câu hỏi thi, vừa biến Sprint Review thành công cụ tối đa hóa giá trị sản phẩm.
Khái niệm cốt lõi
Định nghĩa theo Scrum Guide 2020
Theo Scrum Guide 2020, mục đích của Sprint Review là "to inspect the outcome of the Sprint and determine future adaptations" — kiểm tra kết quả của Sprint và xác định các điều chỉnh trong tương lai. Scrum Team trình bày kết quả công việc cho các bên liên quan chính (key stakeholders), và cùng nhau thảo luận về tiến độ hướng tới Product Goal.
Câu quan trọng nhất mà bạn phải khắc cốt ghi tâm là: "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation." Sprint Review là một phiên làm việc, và Scrum Team nên tránh giới hạn nó thành một buổi thuyết trình.
Hãy để ý từ "working session". Working session nghĩa là mọi người cùng làm việc, cùng suy nghĩ, cùng đưa ra quyết định — chứ không phải ngồi nghe. Stakeholders không phải khán giả; họ là người tham gia (participants).
Sprint Review không phải là gì
Để hiểu đúng, hãy loại bỏ những hiểu lầm phổ biến:
- Không phải là cổng phê duyệt (approval gate). Product Owner không "duyệt" Increment tại Sprint Review. Việc một mục có hoàn thành hay không đã được xác định bởi Definition of Done trong suốt Sprint — chứ không phải đợi đến cuối để PO gật hay lắc đầu.
- Không phải là buổi nghiệm thu chính thức. Tâm lý "nghiệm thu cuối Sprint" rất phổ biến ở các công ty outsourcing Việt Nam, nhưng nó kéo Scrum về tư duy waterfall theo từng giai đoạn.
- Không phải là báo cáo tiến độ một chiều cho sếp. Nếu Sprint Review chỉ để báo cáo, nó đã thất bại.
- Không phải là nơi quyết định một mục "Done" hay "không Done". Increment đã phải Done trước khi vào Review.
Đầu ra của Sprint Review
Sprint Review tạo ra hai đầu ra chính:
- Product Backlog được điều chỉnh (adapted Product Backlog). Dựa trên những gì học được — phản hồi của stakeholders, thay đổi thị trường, ngân sách, công nghệ — Product Backlog có thể được cập nhật: thêm mục mới, gỡ mục cũ, sắp xếp lại thứ tự. Scrum Guide gọi đây là đầu vào (input) cho Sprint Planning kế tiếp.
- Sự cộng tác và alignment. Stakeholders và Scrum Team đạt được hiểu biết chung về tình hình sản phẩm, ngữ cảnh thị trường, và điều gì nên làm tiếp theo.
Timebox
Sprint Review có timebox tối đa 4 giờ cho Sprint một tháng. Sprint ngắn hơn thì thường ngắn hơn tương ứng (ví dụ Sprint 2 tuần thì Review thường tối đa khoảng 2 giờ). Lưu ý: timebox là giới hạn TRÊN, không phải mục tiêu phải đạt tới. Một Review hiệu quả có thể kết thúc sớm.
Ai tham gia?
Đây là phần dàn ý gốc còn để trống, và cũng là điểm thi hay hỏi. Người tham dự Sprint Review gồm:
- Toàn bộ Scrum Team: Product Owner, Scrum Master, và Developers. Đây là sự kiện của cả Scrum Team, không phải riêng PO hay riêng Developers.
- Key stakeholders (các bên liên quan chính) do Product Owner mời. Đây là điểm mấu chốt: Product Owner là người chịu trách nhiệm mời đúng stakeholders. Stakeholder có thể là khách hàng, người dùng cuối, đại diện kinh doanh, bộ phận marketing, bộ phận hỗ trợ, ban lãnh đạo — bất kỳ ai có lợi ích trong sản phẩm và có thể cung cấp phản hồi giá trị.
Vai trò cụ thể của Product Owner
Trong Sprint Review, Product Owner là người dẫn dắt về mặt giá trị và sản phẩm. Cụ thể, PO thường:
- Mời đúng stakeholders.
- Đặt bối cảnh: nhắc lại Product Goal, tình hình thị trường, mục tiêu của Sprint vừa rồi.
- Trình bày tình trạng Product Backlog và tiến độ hướng tới Product Goal.
- Dẫn dắt thảo luận về điều gì nên làm tiếp theo.
- Cập nhật Product Backlog ngay trong hoặc ngay sau buổi Review dựa trên phản hồi.
Tình huống thực tế
Tình huống 1: Tiki và buổi Review "lật ngược" backlog
Hãy hình dung một nhóm Scrum tại một sàn thương mại điện tử lớn như Tiki, đang phát triển tính năng "đặt hàng nhanh bằng giọng nói" cho ứng dụng di động. Sau Sprint thứ ba, Developers đã hoàn thành phần nhận diện giọng nói tiếng Việt với độ chính xác khoảng 85%.
Trong Sprint Review, thay vì chỉ demo, PO đã mời ba nhóm stakeholders: hai đại diện từ bộ phận chăm sóc khách hàng, một chuyên viên phân tích dữ liệu, và bốn người dùng thật được mời từ chương trình beta. Buổi Review biến thành working session: người dùng thử trực tiếp tính năng ngay tại chỗ.
Kết quả gây bất ngờ. Người dùng không hề bận tâm độ chính xác 85% — họ chấp nhận được. Nhưng họ liên tục phàn nàn rằng họ không biết khi nào nên bắt đầu nói, vì không có tín hiệu rõ ràng. Chuyên viên dữ liệu thì chỉ ra rằng chỉ 3% người dùng từng chạm vào nút micro trong các phiên bản thử nghiệm — nghĩa là vấn đề lớn nhất là khả năng được phát hiện (discoverability), không phải độ chính xác.
Diễn giải: PO ban đầu định ưu tiên các Sprint tiếp theo cho việc nâng độ chính xác từ 85% lên 95%. Nhưng sau Sprint Review, PO đã điều chỉnh Product Backlog ngay tại chỗ: hạ ưu tiên việc nâng độ chính xác, đưa lên đầu các mục về thiết kế tín hiệu trực quan và vị trí nút micro.
Bài học: Sprint Review đã thay đổi hướng đi của sản phẩm vì nó là working session với phản hồi thật, không phải buổi vỗ tay. Nếu đây chỉ là demo một chiều, PO sẽ lãng phí nhiều Sprint để giải quyết một vấn đề không quan trọng.
Tình huống 2: Công ty outsourcing và bẫy "nghiệm thu"
Một công ty gia công phần mềm tại TP.HCM (giả định tên FPT Software Lab) làm dự án cho khách hàng Nhật Bản. Văn hóa của họ là cuối mỗi Sprint, Project Manager tổ chức "buổi nghiệm thu": Developers demo từng tính năng, khách hàng tick vào checklist "đạt/không đạt", ký xác nhận, rồi tính tiền theo số mục được nghiệm thu.
Vấn đề: buổi này diễn ra rất căng thẳng. Developers thủ thế, chỉ demo những gì chắc chắn chạy được, giấu các phần còn dang dở. Khách hàng đóng vai người kiểm tra khắt khe. Không ai dám nói về rủi ro hay ý tưởng mới vì sợ ảnh hưởng tới việc thanh toán. Sau mỗi Sprint, Product Backlog gần như không đổi.
Một Agile Coach được mời vào đã chỉ ra: họ đang làm "acceptance meeting" chứ không phải Sprint Review. Anh đề xuất tách bạch: việc một mục có Done hay không được quyết định liên tục trong Sprint bằng Definition of Done rõ ràng (đã thống nhất với khách hàng từ trước), không đợi đến cuối. Sprint Review được thiết kế lại thành phiên thảo luận hai chiều: "Với những gì vừa thấy, thị trường người dùng Nhật đang phản ứng thế nào? Chúng ta nên ưu tiên gì tiếp theo?"
Bài học: Bẫy "nghiệm thu cuối Sprint" rất phổ biến trong các công ty Việt Nam làm outsourcing, một phần do mô hình thanh toán theo mục. Nó hợp đồng hóa quan hệ và giết chết tinh thần cộng tác. Sprint Review không phải cổng phê duyệt — bản chất kiểm tra "Done" thuộc về DoD, còn Review để cùng nhau quyết định tương lai sản phẩm. Đây chính xác là loại phân biệt mà PSPO I kiểm tra.
Tình huống 3: Startup fintech và stakeholder vắng mặt
Một startup fintech tại Singapore phát triển ứng dụng quản lý chi tiêu. Trong sáu Sprint đầu, Sprint Review chỉ có Scrum Team tham dự, vì PO ngại làm phiền các sếp bận rộn và nghĩ "demo nội bộ là đủ".
Kết quả: nhóm xây xong cả một module phân loại giao dịch tự động rất tinh vi. Đến Sprint thứ bảy, khi cuối cùng mời được Giám đốc Tăng trưởng và một khách hàng doanh nghiệp vào Review, họ mới ngã ngửa: khách hàng doanh nghiệp cần xuất báo cáo theo định dạng kế toán chuẩn để nộp thuế, một nhu cầu lớn hơn nhiều so với phân loại tự động. Sáu Sprint công sức đã đi lệch hướng vì thiếu vòng phản hồi với đúng stakeholders.
Diễn giải và bài học: Trách nhiệm mời đúng stakeholders thuộc về Product Owner. Một Sprint Review không có stakeholders phù hợp chỉ là buổi họp nội bộ và đánh mất toàn bộ giá trị empiricism (kiểm tra và thích nghi dựa trên thực tế). Phản hồi muộn là phản hồi đắt. Càng để lâu mới inspect với người thật, càng nhiều công sức có nguy cơ lãng phí.
Hướng dẫn từng bước
Dưới đây là cách tổ chức một Sprint Review đúng tinh thần working session, từ góc nhìn Product Owner:
- Chuẩn bị trước buổi họp. PO xác định và mời đúng key stakeholders — những người có thể cho phản hồi giá trị về phần Increment lần này. Gửi lời mời sớm, nêu rõ bối cảnh để họ chuẩn bị.
- Mở đầu bằng bối cảnh. PO nhắc lại Product Goal, tình hình thị trường, và Sprint Goal vừa qua. Điều này giúp stakeholders hiểu họ đang nhìn cái gì và vì sao nó quan trọng.
- Trình bày Increment trong môi trường thật. Để Developers trình bày phần đã hoàn thành, lý tưởng nhất là cho stakeholders tự tay dùng thử thay vì chỉ xem slide. Một Increment chạy được luôn thuyết phục hơn một bản trình chiếu.
- Thu thập phản hồi một cách chủ động. Đặt câu hỏi mở: "Điều này có giải quyết vấn đề của anh/chị không?", "Nếu thiếu, thì thiếu gì?". Khuyến khích stakeholders nói thật, kể cả lời chê.
- Thảo luận về tình hình tổng thể. PO chia sẻ trạng thái Product Backlog, tiến độ hướng tới Product Goal, các thay đổi về timeline, ngân sách, thị trường, công nghệ có thể ảnh hưởng đến kế hoạch.
- Cộng tác về điều nên làm tiếp theo. Đây là phần "working" thật sự: cả nhóm và stakeholders cùng bàn xem nên ưu tiên gì. Đây không phải lúc PO ra lệnh, mà là lúc tổng hợp đầu vào.
- Điều chỉnh Product Backlog. Dựa trên những gì học được, PO cập nhật Product Backlog ngay trong hoặc ngay sau buổi Review — thêm, bớt, hoặc sắp xếp lại. Backlog đã điều chỉnh chính là đầu vào cho Sprint Planning kế tiếp.
Lỗi thường gặp & mẹo
Lỗi 1: Biến Sprint Review thành buổi thuyết trình một chiều. Đây là lỗi số một và cũng là cái bẫy lớn nhất trong đề thi. Mẹo: hãy luôn để stakeholders tự tay tương tác với sản phẩm và luôn dành phần lớn thời gian cho thảo luận hai chiều.
Lỗi 2: Coi Sprint Review là cổng phê duyệt của PO. Việc một mục có "Done" hay không thuộc về Definition of Done trong suốt Sprint, không phải đợi PO gật đầu cuối Sprint. Mẹo nhớ: DoD quyết định "Done"; Sprint Review quyết định "tiếp theo làm gì".
Lỗi 3: Không mời stakeholders, hoặc mời sai người. Review chỉ có nội bộ Scrum Team thì mất hết giá trị phản hồi. Mẹo: PO chịu trách nhiệm mời đúng người cho từng lần Review tùy theo nội dung Increment.
Lỗi 4: Nhầm Sprint Review chỉ là việc của Product Owner. Sai. Đây là sự kiện của cả Scrum Team. Developers thường trình bày kỹ thuật, Scrum Master tạo điều kiện, PO dẫn dắt về giá trị.
Lỗi 5: Dùng hết timebox như một mục tiêu. Timebox 4 giờ (cho Sprint một tháng) là giới hạn trên. Một Review hiệu quả hoàn toàn có thể kết thúc sớm.
Lỗi 6: Coi Product Backlog đã điều chỉnh là bắt buộc thay đổi mọi lần. Backlog "có thể" được điều chỉnh — không bắt buộc phải thay đổi nếu không có gì mới đáng kể. Nhưng cơ chế thì luôn mở.
Mẹo thi PSPO I: Khi gặp câu hỏi về Sprint Review, hãy ưu tiên các phương án chứa từ khóa "working session", "collaborate", "inspect the Increment", "adapt the Product Backlog", "discuss what to do next". Hãy nghi ngờ các phương án chứa "approve", "sign-off", "report to management", "status report", "demo only".
Bài tập thực hành
- Phân biệt khái niệm: Viết ra ba điểm khác biệt cụ thể giữa "Sprint Review như một working session" và "buổi demo show-and-tell". Với mỗi điểm, nêu một hậu quả thực tế nếu làm sai.
- Tình huống ra quyết định: Sprint của bạn kết thúc, nhưng một tính năng quan trọng chưa đạt Definition of Done. Một stakeholder muốn bạn "demo và duyệt tạm" tại Sprint Review để kịp deadline. Bạn — với tư cách PO — sẽ phản hồi thế nào và vì sao? Hãy giải thích dựa trên vai trò của DoD.
- Thiết kế Review: Bạn là PO của một nhóm làm app giao đồ ăn tại Đà Nẵng. Sprint vừa rồi hoàn thành tính năng "theo dõi shipper theo thời gian thực". Hãy liệt kê: (a) ba nhóm stakeholders bạn sẽ mời và lý do, (b) ba câu hỏi mở bạn sẽ đặt để thu phản hồi, (c) một thay đổi backlog có thể xảy ra dựa trên phản hồi.
- Tự kiểm tra dạng thi: "Mục đích chính của Sprint Review là gì?" Hãy tự viết ra câu trả lời đúng bằng một câu, rồi đối chiếu với định nghĩa Scrum Guide 2020 trong bài. Bạn dùng được đúng từ "inspect" và "adapt" không?
Tóm tắt
Sprint Review là một working session — phiên làm việc cộng tác để kiểm tra (inspect) kết quả của Sprint và xác định các điều chỉnh (adapt) trong tương lai, đặc biệt là điều chỉnh Product Backlog. Nó tuyệt đối KHÔNG phải buổi demo một chiều, KHÔNG phải cổng phê duyệt của PO, và KHÔNG phải báo cáo tiến độ cho sếp.
Người tham dự gồm toàn bộ Scrum Team cùng các key stakeholders do Product Owner mời. PO chịu trách nhiệm mời đúng người, đặt bối cảnh, dẫn dắt thảo luận về giá trị, và cập nhật Product Backlog dựa trên những gì học được. Timebox tối đa 4 giờ cho Sprint một tháng, và đây là giới hạn trên chứ không phải mục tiêu.
Việc một mục có "Done" hay không thuộc về Definition of Done trong suốt Sprint — Sprint Review tập trung vào câu hỏi "chúng ta nên làm gì tiếp theo để tối đa hóa giá trị?". Với PSPO I, hãy luôn nhớ: working session, collaborate, inspect Increment, adapt Product Backlog. Đó là chìa khóa vừa để thi đậu, vừa để trở thành một Product Owner thực thụ biết biến mỗi cuối Sprint thành một bước điều chỉnh thông minh cho cả sản phẩm.