Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa kết thúc hai tuần làm việc cật lực. Team đã code, test, fix bug, viết tài liệu. Nhưng câu hỏi quan trọng nhất vẫn chưa được trả lời: Liệu những gì chúng ta làm có thật sự đúng hướng không? Sprint Review chính là thời điểm để trả lời câu hỏi đó.
Trong số 5 sự kiện của Scrum, Sprint Review là nơi duy nhất Scrum Team chủ động ngồi cùng với key stakeholders (các bên liên quan chính như khách hàng, người dùng, ban lãnh đạo, đại diện kinh doanh) để inspect (kiểm tra) kết quả của Sprint và cùng nhau xác định những điều chỉnh cho tương lai. Đây không phải là một buổi "báo cáo" hay "nghiệm thu" theo kiểu truyền thống — đó là một buổi làm việc cộng tác (working session) để định hình lại hướng đi của sản phẩm.
Với kỳ thi PSM I, Sprint Review là một trong những chủ đề bị hiểu sai nhiều nhất. Rất nhiều người tưởng nó chỉ là buổi "demo cho sếp xem", hoặc là cánh cửa "phê duyệt/từ chối" sản phẩm. Nếu bạn giữ những hiểu lầm này, bạn sẽ trả lời sai một loạt câu hỏi. Bài học này sẽ giúp bạn nắm chắc đúng bản chất của Sprint Review theo Scrum Guide 2020 — vừa để thi đậu, vừa để áp dụng đúng trong công việc thực tế.
Khái niệm cốt lõi
Mục đích thật sự của Sprint Review
Theo Scrum Guide 2020, mục đích của Sprint Review là "inspect the outcome of the Sprint and determine future adaptations" — kiểm tra kết quả (outcome) của Sprint và xác định những điều chỉnh cho tương lai. Hãy chú ý từ "outcome" chứ không phải "output". Đây không chỉ là kiểm tra "chúng ta đã làm xong những tính năng gì", mà là "những tính năng đó tạo ra giá trị gì, và bối cảnh xung quanh sản phẩm đã thay đổi ra sao".
Trong buổi này, Scrum Team trình bày kết quả công việc cho key stakeholders, và tiến độ hướng tới Product Goal được thảo luận (progress toward the Product Goal is discussed). Dựa trên những thông tin mới — từ chính Increment được trình bày, từ phản hồi của stakeholders, từ thay đổi của thị trường — cả nhóm cùng nhau quyết định những việc cần làm tiếp theo. Kết quả của buổi này thường là Product Backlog được điều chỉnh, bổ sung những cơ hội mới phát sinh.
Sprint Review là một WORKING SESSION, không phải buổi demo một chiều
Đây là điểm mấu chốt mà Scrum Guide nhấn mạnh rõ: "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation." Sprint Review là một buổi làm việc cộng tác, và Scrum Team nên tránh giới hạn nó thành một bài thuyết trình.
Nghĩa là gì? Một buổi demo thuần túy là: Team trình chiếu màn hình, stakeholders ngồi xem, vỗ tay, ra về. Một Sprint Review đúng nghĩa là: Team trình bày Increment, stakeholders dùng thử, đặt câu hỏi, nêu phản hồi, thảo luận về thay đổi của thị trường, về ngân sách, về timeline — và tất cả cùng nhau điều chỉnh Product Backlog ngay tại chỗ để chuẩn bị cho Sprint tiếp theo. Demo có thể là một phần của Sprint Review, nhưng nó không phải toàn bộ.
Ai tham dự?
Toàn bộ Scrum Team (Product Owner, Scrum Master, Developers) tham dự, và mời key stakeholders. Lưu ý từ "invite" — Scrum Team mời các bên liên quan đến cộng tác. Product Owner thường là người chủ trì việc thảo luận về sản phẩm và Product Backlog, vì PO là người chịu trách nhiệm về giá trị sản phẩm (value). Tuy nhiên, đây là buổi của cả Team, không phải buổi "PO báo cáo".
Timebox
Sprint Review được giới hạn thời gian (timebox) tối đa 4 giờ cho một Sprint kéo dài 1 tháng. Với Sprint ngắn hơn, sự kiện thường ngắn hơn tương ứng. Ví dụ, Sprint 2 tuần thì Sprint Review thường không quá 2 giờ. Đây là con số bạn cần nhớ chính xác cho kỳ thi: 4 giờ / Sprint 1 tháng.
Vị trí trong Sprint
Sprint Review diễn ra gần cuối Sprint, sau khi công việc đã hoàn thành nhưng trước Sprint Retrospective. Thứ tự này rất quan trọng: Sprint Review (kiểm tra sản phẩm) → Sprint Retrospective (kiểm tra quy trình và cách làm việc). Lý do logic: phản hồi và những phát hiện từ Sprint Review (ví dụ stakeholders không hài lòng vì Increment thiếu chất lượng) có thể trở thành đầu vào quý giá cho Retrospective.
Sprint Review KHÔNG phải là cổng phê duyệt (gate)
Một hiểu lầm tai hại: nhiều người nghĩ Sprint Review là nơi stakeholders "duyệt" hoặc "từ chối" công việc, kiểu như một cổng kiểm soát chất lượng cuối cùng. Sai. Increment phải đã đạt Definition of Done (DoD) trước khi được trình bày ở Sprint Review. Một công việc chưa đạt DoD thì không được tính là hoàn thành, và không nên được trình bày như thể nó đã xong. Sprint Review không "biến" công việc dở dang thành hoàn thành. Nó cũng không phải nơi để "ký nghiệm thu" theo kiểu hợp đồng. Đây là điểm phân biệt rất tinh tế mà đề thi PSM I rất hay khai thác.
Tình huống thực tế
Tình huống 1 — Sàn TMĐT tại TP.HCM: từ "demo" sang "working session"
Công ty Shopnow (giả định) là một sàn thương mại điện tử có trụ sở tại Quận 1, TP.HCM, với khoảng 120 nhân sự công nghệ chia thành 8 Scrum Team. Trước đây, Sprint Review của họ chỉ là buổi demo 30 phút: mỗi Developer lần lượt chiếu màn hình tính năng mình làm, Giám đốc Sản phẩm gật gù, rồi giải tán. Stakeholders gần như không nói gì.
Sau một Sprint xây tính năng "thanh toán trả góp", team trình bày như thường lệ. Nhưng vì đó chỉ là demo một chiều, không ai hỏi sâu. Mãi đến tuần sau, đại diện phòng Kinh doanh mới phát hiện luồng trả góp không hỗ trợ thẻ của 2 ngân hàng lớn nhất mà khách hàng Việt Nam hay dùng — một thông tin lẽ ra phải xuất hiện ngay tại Sprint Review.
Scrum Master nhận ra vấn đề và thay đổi cách tổ chức. Ở Sprint Review tiếp theo, thay vì chiếu slide, Scrum Master mời đại diện Kinh doanh và 2 nhân viên Chăm sóc khách hàng trực tiếp dùng thử tính năng trên môi trường thật. Trong 15 phút thao tác, họ phát hiện ngay 3 vấn đề về trải nghiệm và 1 cơ hội mới: khách hàng muốn xem trước lịch trả góp. Product Owner ghi nhận và thêm ngay 4 mục mới vào Product Backlog tại chỗ.
Bài học: Sprint Review là working session. Khi bạn để stakeholders chủ động tương tác với Increment thay vì chỉ ngồi xem, bạn thu được phản hồi thật, sớm và rẻ. Phản hồi muộn luôn đắt hơn nhiều.
Tình huống 2 — Fintech tại Singapore: thảo luận tiến độ hướng tới Product Goal
PayLink (giả định) là một startup fintech tại Singapore, đang xây sản phẩm ví điện tử với Product Goal: "Ra mắt ví điện tử hỗ trợ thanh toán xuyên biên giới cho 3 nước ASEAN vào Q4". Mỗi Sprint kéo dài 2 tuần, và Sprint Review của họ luôn bắt đầu bằng việc Product Owner chiếu một bảng trực quan thể hiện: đã hoàn thành bao nhiêu phần trăm các hạng mục dẫn tới Product Goal, còn lại những gì.
Trong một Sprint Review, sau khi trình bày Increment cho phép chuyển tiền nội địa, PO mở phần thảo luận về tiến độ hướng tới Product Goal. Một stakeholder từ ban lãnh đạo nêu thông tin mới: một đối thủ vừa ra mắt tính năng tương tự, và ngân hàng trung ương một nước trong khu vực vừa thay đổi quy định về giới hạn giao dịch. Đây là thông tin thị trường (market context) thay đổi.
Cả nhóm cùng phân tích: với quy định mới, việc hỗ trợ nước đó sẽ cần thêm 3 tuần xử lý pháp lý. Họ cùng nhau quyết định điều chỉnh Product Backlog: ưu tiên 2 nước ít rủi ro pháp lý trước, dời nước thứ ba sang sau. Product Goal vẫn giữ, nhưng đường đi tới đó được điều chỉnh.
Bài học: Sprint Review không chỉ nhìn lại Increment vừa làm, mà còn nhìn về phía trước. Thông tin về thị trường, ngân sách, timeline được mang vào để cả nhóm cùng xác định adaptations — điều chỉnh Product Backlog cho phù hợp. Đây chính là Empiricism (kinh nghiệm thực chứng) trong hành động: Inspect (kiểm tra) rồi Adapt (thích nghi).
Tình huống 3 — Outsourcing tại Đà Nẵng: hiểu nhầm Sprint Review là "cổng nghiệm thu"
Một công ty gia công phần mềm tại Đà Nẵng nhận dự án cho khách hàng Nhật. Họ tổ chức Sprint Review như một buổi nghiệm thu: cuối Sprint, team trình bày tất cả công việc — kể cả những tính năng còn dang dở "chỉ thiếu chút nữa là xong" — với hy vọng khách hàng "duyệt" để được thanh toán.
Hậu quả: khách hàng nhìn thấy tính năng trông có vẻ chạy được, tưởng đã xong, lên kế hoạch dựa trên đó. Nhưng những tính năng "gần xong" ấy chưa qua kiểm thử, chưa đạt Definition of Done. Sang Sprint sau, bug nổ ra hàng loạt, niềm tin của khách hàng sụt giảm nghiêm trọng.
Scrum Master mới về đã chỉnh đốn: chỉ những công việc đã đạt Definition of Done mới được trình bày tại Sprint Review. Phần dang dở được đưa trở lại Product Backlog một cách minh bạch. Ban đầu khách hàng hơi sốc vì "thấy ít hơn", nhưng sau vài Sprint, độ tin cậy của những gì được trình bày tăng vọt, và khách hàng tin tưởng team hơn hẳn.
Bài học: Sprint Review không phải cổng phê duyệt biến công việc dang dở thành hoàn thành. Minh bạch (Transparency) là điều kiện sống còn — chỉ trình bày những gì thật sự "Done". Trình bày công việc chưa đạt DoD là phá hủy tính minh bạch và đánh lừa stakeholders.
Hướng dẫn từng bước
Dưới đây là một cách tổ chức Sprint Review hiệu quả. Lưu ý: Scrum không quy định một "công thức" bắt buộc, đây là gợi ý thực hành tốt, không phải luật trong Scrum Guide.
- Chuẩn bị trước buổi (trong Sprint). Đảm bảo Increment đã đạt Definition of Done. Product Owner mời đúng các key stakeholders cần thiết — đúng người sẽ cho phản hồi giá trị. Đừng mời cho có, cũng đừng quên ai quan trọng.
- Mở đầu: nhắc lại Sprint Goal và Product Goal. Bắt đầu bằng việc nhắc cả phòng nhớ Sprint Goal của Sprint này và Product Goal dài hạn. Điều này đặt mọi thảo luận vào đúng bối cảnh.
- Product Owner trình bày tiến độ hướng tới Product Goal. Cho thấy bức tranh lớn: chúng ta đang ở đâu trên hành trình tới mục tiêu sản phẩm, những mục nào đã hoàn thành.
- Trình bày và để stakeholders TƯƠNG TÁC với Increment. Thay vì chỉ chiếu màn hình, hãy để stakeholders tự dùng thử khi có thể. Khuyến khích họ đặt câu hỏi, nêu phản hồi. Đây là phần "working" của working session.
- Thảo luận bối cảnh đã thay đổi. Cùng nhau bàn về những thay đổi của thị trường, đối thủ, ngân sách, timeline, quy định pháp lý, ưu tiên kinh doanh. Những yếu tố này ảnh hưởng đến việc nên làm gì tiếp theo.
- Cùng nhau xác định những việc nên làm tiếp theo (adaptations). Dựa trên tất cả thông tin vừa thu được, cả nhóm cùng điều chỉnh Product Backlog: thêm mục mới, sắp xếp lại thứ tự ưu tiên, loại bỏ mục không còn cần thiết. Product Backlog có thể được điều chỉnh ngay trong buổi này.
- Chốt lại đầu ra. Sprint Review kết thúc với một Product Backlog đã được cập nhật — đầu vào quý giá cho buổi Sprint Planning của Sprint tiếp theo.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến Sprint Review thành demo một chiều. Đây là lỗi phổ biến nhất. Hãy nhớ: Scrum Guide nói rõ phải avoid limiting it to a presentation. Mẹo: luôn dành thời gian cho stakeholders tương tác và thảo luận, không chỉ ngồi xem.
Lỗi 2 — Trình bày công việc chưa đạt Definition of Done. Chỉ những gì "Done" mới được trình bày. Trình bày công việc dang dở phá hủy tính minh bạch. Mẹo: trước buổi, kiểm tra từng hạng mục đối chiếu với DoD.
Lỗi 3 — Coi Sprint Review là cổng phê duyệt/nghiệm thu. Sprint Review không phải nơi stakeholders "ký duyệt" để công việc được tính là xong. Việc đạt DoD đã xác định công việc hoàn thành rồi. Sprint Review là để inspect và adapt, không phải để gate.
Lỗi 4 — Quên thảo luận tiến độ hướng tới Product Goal. Nhiều team chỉ demo tính năng mà quên nhìn bức tranh lớn. Scrum Guide 2020 nhấn mạnh rõ progress toward the Product Goal phải được thảo luận. Mẹo: luôn mở đầu bằng Product Goal.
Lỗi 5 — Nhầm Sprint Review với Sprint Retrospective. Sprint Review kiểm tra sản phẩm và Increment (với stakeholders). Sprint Retrospective kiểm tra quy trình, con người, cách làm việc (chỉ trong nội bộ Scrum Team). Hai sự kiện khác nhau, mục đích khác nhau, người tham dự khác nhau. Mẹo nhớ: Review = sản Phẩm, Retro = quy tRình.
Lỗi 6 — Không mời đúng stakeholders. Nếu không có người cho được phản hồi giá trị trong phòng, buổi Review trở nên vô nghĩa. Mẹo: PO chủ động xác định và mời đúng người.
Mẹo cho phòng thi: Khi gặp câu hỏi về "ai phê duyệt Increment", "Sprint Review có phải quality gate không", hay "có nên trình bày công việc gần xong không" — hãy nhớ nguyên tắc "by the book": Increment phải Done trước; Sprint Review là working session để inspect & adapt, không phải cổng duyệt.
Bài tập thực hành
Bài tập 1 — Phân biệt đúng/sai. Với mỗi phát biểu sau, xác định Đúng hay Sai theo Scrum Guide 2020, và giải thích ngắn:
- a) Sprint Review chỉ nên là một bài thuyết trình của team cho stakeholders.
- b) Tiến độ hướng tới Product Goal được thảo luận trong Sprint Review.
- c) Stakeholders phải phê duyệt thì công việc mới được tính là hoàn thành.
- d) Sprint Review diễn ra sau Sprint Retrospective.
- e) Sprint Review tối đa 4 giờ cho Sprint 1 tháng.
Bài tập 3 — Tình huống ra quyết định. Trong Sprint Review, một Developer muốn trình bày tính năng "đã code xong 95%, chỉ còn thiếu test cuối". Bạn là Scrum Master, bạn xử lý thế nào và giải thích lý do dựa trên Definition of Done và tính minh bạch?
Gợi ý đáp án Bài tập 1: a) Sai — phải tránh giới hạn thành thuyết trình. b) Đúng. c) Sai — DoD xác định hoàn thành, không phải sự phê duyệt của stakeholders. d) Sai — Review diễn ra TRƯỚC Retrospective. e) Đúng.
Tóm tắt
- Mục đích: Inspect kết quả (outcome) của Sprint và xác định adaptations cho tương lai. Scrum Team trình bày kết quả cho key stakeholders, và tiến độ hướng tới Product Goal được thảo luận.
- Bản chất: Là một working session (buổi làm việc cộng tác), KHÔNG phải demo một chiều. Scrum Team phải tránh giới hạn nó thành một bài thuyết trình.
- Người tham dự: Toàn bộ Scrum Team + key stakeholders được mời.
- Timebox: Tối đa 4 giờ cho Sprint 1 tháng (ngắn hơn cho Sprint ngắn hơn).
- Vị trí: Gần cuối Sprint, trước Sprint Retrospective.
- Điều kiện: Chỉ trình bày công việc đã đạt Definition of Done. Sprint Review KHÔNG phải cổng phê duyệt/nghiệm thu.
- Đầu ra: Product Backlog được điều chỉnh — đầu vào cho Sprint Planning tiếp theo.