Mở đầu — vì sao bài này quan trọng
Nếu Sprint Planning là lúc đội bóng bàn kế hoạch tác chiến, thì Sprint Review và Retrospective là hai buổi "xem lại băng ghi hình" sau trận đấu. Một buổi để trình bày kết quả cho khán giả (Sprint Review), một buổi để đội ngồi lại với nhau tự soi mình và tìm cách chơi hay hơn (Retrospective). Rất nhiều PM ở Việt Nam làm việc với Jira đã bỏ qua hoặc làm cho có hai buổi này — và đó là lý do đội của họ chạy sprint hết tháng này sang tháng khác nhưng không tiến bộ, còn stakeholder thì luôn cảm thấy "sản phẩm đi đâu mất rồi".
Sự thật là: một sprint kết thúc mà không có Review đúng nghĩa thì bạn đã đánh mất cơ hội quý giá nhất để lấy feedback thật từ người dùng và người quyết định. Một sprint kết thúc mà không có Retrospective thì bạn đang lặp lại cùng những sai lầm mỗi hai tuần mà không ai chịu trách nhiệm sửa. Đây chính là hai "sự kiện" (ceremony) khép lại chu trình sprint mà chúng ta đã bắt đầu ở Bài 11 (Planning) và duy trì ở Bài 12 (Daily Stand-up). Bài này sẽ giúp bạn tổ chức, dẫn dắt và ghi nhận kết quả của cả hai buổi này một cách chuyên nghiệp — kèm cách phản ánh chúng vào Jira để dữ liệu không bị lãng phí.
Khái niệm cốt lõi
Hai sự kiện này thường bị gộp chung trong đầu người mới, nhưng chúng phục vụ hai mục đích hoàn toàn khác nhau. Hiểu rõ sự khác biệt là bước đầu tiên để làm đúng.
Sprint Review — buổi "demo" hướng ra ngoài
Sprint Review là buổi họp cuối sprint, nơi đội trình diễn phần sản phẩm đã hoàn thành (working software) cho các bên liên quan (stakeholder) và thu thập phản hồi. Đây là sự kiện hướng ra ngoài — mục tiêu chính là kiểm tra xem sản phẩm có đang đi đúng hướng với kỳ vọng của người dùng, khách hàng, lãnh đạo hay không.
- Cadence (nhịp): diễn ra vào cuối mỗi sprint, thường kéo dài 60–90 phút cho sprint 2 tuần.
- Người tham dự: toàn bộ đội phát triển (dev, QA, designer), Product Owner/PM, Scrum Master, và quan trọng nhất là stakeholder — có thể là sếp, đại diện khách hàng, phòng kinh doanh, phòng marketing.
- Định dạng: demo phần mềm chạy thật, KHÔNG dùng slide. Đây là nguyên tắc vàng. Nếu bạn đứng trình bày một bộ slide đẹp về "những gì chúng tôi đã làm", bạn đang bán ý tưởng chứ không phải cho stakeholder thấy giá trị thật. Hãy mở sản phẩm lên, bấm vào tính năng, cho họ thấy nó hoạt động.
- Kết quả đầu ra: phản hồi từ stakeholder, các điều chỉnh cho backlog, và quyết định về hướng đi tiếp theo.
Sprint Retrospective — buổi "soi gương" hướng vào trong
Sprint Retrospective (gọi tắt là Retro) là buổi họp chỉ dành cho nội bộ đội, diễn ra sau Review và trước khi bắt đầu Planning cho sprint kế tiếp. Mục tiêu là nhìn lại cách đội đã làm việc (process, con người, công cụ, giao tiếp) — chứ không phải nhìn lại sản phẩm.
- Cadence: cuối sprint, sau Review, thường 45–60 phút.
- Người tham dự: chỉ đội — dev, QA, designer, PM, Scrum Master. Không mời stakeholder, vì đây là không gian an toàn để đội nói thật.
- Định dạng phổ biến: các mô hình như "Start / Stop / Continue", "Mad / Sad / Glad", hoặc "4Ls: Liked / Learned / Lacked / Longed for".
- Kết quả đầu ra: một danh sách ngắn các hành động cải tiến (action items) cụ thể, có người chịu trách nhiệm, để áp dụng ngay sprint tới.
Sự khác biệt cần nhớ
| Tiêu chí | Sprint Review | Retrospective |
|---|---|---|
| Đối tượng | Sản phẩm | Cách làm việc của đội |
| Người tham dự | Đội + stakeholder | Chỉ đội |
| Hướng | Ra ngoài | Vào trong |
| Đầu ra | Feedback + điều chỉnh backlog | Action items cải tiến quy trình |
Tình huống thực tế
Ví dụ 1: Startup fintech ở TP.HCM — khi demo cứu cả một tính năng
Một startup fintech tại Quận 1, TP.HCM (khoảng 25 người, đội sản phẩm 8 người) đang xây tính năng "chuyển tiền theo lịch định kỳ". Suốt 3 sprint, PM chỉ báo cáo tiến độ cho CEO bằng file Excel và ảnh chụp màn hình. Đến Sprint Review thứ 4, PM quyết định làm đúng chuẩn: mở app lên demo trực tiếp trên môi trường staging cho CEO và trưởng phòng vận hành cùng xem.
Ngay khi demo bước "chọn ngày chuyển tiền", trưởng phòng vận hành phát hiện: luồng đang cho phép người dùng chọn ngày 29, 30, 31 hằng tháng — nhưng tháng 2 không có những ngày đó, và hệ thống ngân hàng đối tác sẽ từ chối giao dịch, gây lỗi hàng loạt. Đây là chi tiết mà không ai trong đội dev nghĩ tới vì họ không hiểu nghiệp vụ ngân hàng.
Bài học: nếu PM tiếp tục báo cáo bằng slide và ảnh chụp, lỗi này sẽ chỉ lộ ra khi đã lên production và có thể gây thiệt hại tiền thật. Demo phần mềm chạy thật với đúng người có kiến thức nghiệp vụ đã cứu tính năng. Sau buổi Review, PM tạo ngay một Story mới trong backlog: "Xử lý ngày không tồn tại trong tháng cho lịch chuyển tiền" và đưa lên đầu sprint sau.
Ví dụ 2: Công ty outsource ở Đà Nẵng — Retro biến "than phiền" thành hành động
Một công ty gia công phần mềm ở Đà Nẵng có đội 6 người làm cho khách hàng Nhật. Ba sprint liên tiếp, velocity tụt từ 34 điểm xuống 21 điểm. Trong Retro, thay vì để mọi người nói chung chung "dạo này mệt quá", Scrum Master dùng mô hình Start / Stop / Continue và yêu cầu mỗi người viết ít nhất 2 note vào bảng Miro.
Kết quả lộ ra vấn đề thật: khách hàng Nhật gửi yêu cầu làm rõ (clarification) qua email lúc 4h chiều giờ Nhật — tức đội Đà Nẵng chỉ đọc được vào sáng hôm sau, làm mỗi câu hỏi trễ mất gần một ngày. Ba dev đều "chặn" (blocked) vì cùng lý do này nhưng chưa ai nói ra thành hệ thống.
Đội thống nhất 1 action item duy nhất, cụ thể: "Anh Minh (dev lead) sẽ đề xuất với khách hàng lịch overlap 30 phút mỗi ngày lúc 3h chiều giờ VN để hỏi đáp trực tiếp qua Slack huddle." Họ tạo một task trong Jira gắn label retro-action, giao cho anh Minh, đưa vào sprint sau. Hai sprint sau đó velocity phục hồi lên 30 điểm.
Bài học: Retro chỉ có giá trị khi biến cảm giác mơ hồ thành một hành động cụ thể có chủ + có deadline. Đừng ra về với 10 action items — không ai làm nổi. Một hành động được thực thi hơn mười hành động bị lãng quên.
Ví dụ 3: Đội agency ở Hà Nội — cái bẫy "Review thành buổi báo cáo tiến độ"
Một agency ở Hà Nội có PM trẻ tổ chức Sprint Review nhưng vô tình biến nó thành buổi báo cáo: PM đứng nói suốt 40 phút về "đã hoàn thành 18/20 story", chiếu biểu đồ burndown, và... không demo gì cả. Stakeholder ngồi nghe, gật đầu, rồi về. Sau ba sprint như vậy, giám đốc dự án phàn nàn: "Tôi chẳng biết sản phẩm thực sự thế nào."
Vấn đề: PM đã nhầm Sprint Review với việc trình bày số liệu Jira. Các con số (bao nhiêu story done, burndown ra sao) là thứ đội tự theo dõi trong Daily và Planning, không phải nội dung chính của Review. Stakeholder cần nhìn thấy và chạm vào giá trị, không cần nghe thống kê.
Bài học: Sprint Review lấy demo làm trung tâm, số liệu chỉ là phần phụ (tối đa 5 phút đầu để đặt bối cảnh). Nếu bạn thấy mình đang chiếu nhiều slide hơn là mở sản phẩm, bạn đang làm sai.
Hướng dẫn từng bước
Phần A — Tổ chức Sprint Review
- Chuẩn bị trước buổi họp (1–2 ngày trước). Trong Jira, lọc các issue của sprint theo trạng thái Done (dùng board hoặc JQL
sprint in openSprints() AND status = Done). Chỉ demo những gì đạt Definition of Done — không demo thứ còn dở dang, vì nó sẽ gây hiểu nhầm về tiến độ. Chuẩn bị môi trường staging sạch với dữ liệu mẫu hợp lý.
- Phân công người demo. Lý tưởng nhất là để chính dev hoặc QA đã làm tính năng demo phần của mình — họ hiểu sâu nhất và tự tin trả lời câu hỏi. PM đóng vai người dẫn dắt, kết nối các phần thành một câu chuyện về giá trị người dùng.
- Mở đầu bằng Sprint Goal. Dành 3–5 phút nhắc lại mục tiêu sprint đã đặt ra ở Planning, để stakeholder có khung tham chiếu: "Sprint này chúng ta cam kết cho phép người dùng đặt lịch chuyển tiền định kỳ — đây là kết quả."
- Demo theo luồng người dùng (user journey), không theo danh sách task. Thay vì "story 1, story 2, story 3", hãy kể: "Một khách hàng mở app, vào mục chuyển tiền, chọn định kỳ, đặt ngày..." Điều này giúp stakeholder cảm nhận được giá trị thật.
- Thu thập feedback ngay tại chỗ. Ghi lại mọi phản hồi. PM (hoặc Scrum Master) nên có sẵn Jira mở để tạo issue mới ngay khi có yêu cầu thay đổi, gắn label
from-reviewđể dễ truy vết nguồn gốc.
- Cập nhật backlog sau buổi họp. Chuyển feedback thành các Story/Task cụ thể, sắp xếp lại độ ưu tiên. Đây là cầu nối tự nhiên tới Backlog Refinement của sprint sau.
Phần B — Tổ chức Retrospective
- Tạo không gian an toàn. Mở đầu bằng cách nhắc Prime Directive: chúng ta ở đây để cải thiện quy trình, không đổ lỗi cá nhân. Với đội Việt Nam vốn ngại nói thẳng, bước này cực kỳ quan trọng.
- Thu thập dữ liệu. Cho mỗi người 5–7 phút viết note im lặng (dùng Miro, Metroretro, hoặc giấy note dán tường) theo mô hình đã chọn — ví dụ Start/Stop/Continue. Viết im lặng trước giúp mọi ý kiến được ghi nhận, tránh việc chỉ người nói to át người trầm tính.
- Nhóm và bàn luận (grouping). Gom các note giống nhau thành cụm, cho cả đội bỏ phiếu (dot voting) chọn 2–3 chủ đề nóng nhất để đào sâu. Đừng cố bàn hết mọi note.
- Đào gốc rễ. Với mỗi chủ đề, hỏi "tại sao" vài lần (kỹ thuật 5 Whys) để chạm tới nguyên nhân thật, thay vì dừng ở triệu chứng bề mặt.
- Chốt action items — ít mà chất. Chọn tối đa 1–3 hành động, mỗi hành động có một người chịu trách nhiệm rõ ràng và thời hạn. Đưa các action này vào sprint kế tiếp như task thật trong Jira (label
retro-action), để chúng được theo dõi chứ không trôi vào quên lãng.
- Đầu Retro kỳ sau, review action cũ. Luôn bắt đầu buổi Retro tiếp theo bằng việc kiểm tra các action item của kỳ trước đã làm chưa. Đây là điều tạo nên vòng lặp cải tiến liên tục (continuous improvement) thật sự.
Lỗi thường gặp & mẹo
- Biến Review thành báo cáo tiến độ. Như ví dụ 3: nếu bạn chiếu slide thay vì demo sản phẩm chạy, bạn đang lãng phí buổi họp. Mẹo: đặt quy tắc "no slide, chỉ mở app".
- Demo cả những thứ chưa Done. Điều này gây ảo giác tiến độ và tạo kỳ vọng sai. Chỉ demo thứ đạt Definition of Done.
- Mời stakeholder vào Retro. Sự có mặt của sếp hay khách hàng sẽ khiến đội không dám nói thật. Retro là không gian nội bộ, tuyệt đối giữ kín.
- Retro thành phiên đổ lỗi. Nếu buổi họp biến thành "tại anh A code chậm", nó sẽ giết chết sự an toàn tâm lý và không ai còn muốn nói thật. Luôn quay về quy trình.
- Ra về với 10 action items. Đội sẽ không làm nổi và mất niềm tin vào Retro. Mẹo: giới hạn cứng 1–3 action, mỗi cái có chủ.
- Action item không vào Jira. Nếu chỉ ghi trong biên bản họp rồi cất vào Google Doc, action sẽ bị quên. Mẹo: tạo task thật trong sprint, gắn label để lọc và theo dõi.
- Bỏ Review/Retro khi "bận". Đây là dấu hiệu đội đang chạy nước rút vô định. Nghịch lý là càng bận, càng cần Retro để tìm ra vì sao bận.
- Mẹo dùng Jira: tạo một dashboard nhỏ với gadget lọc các issue label
from-reviewvàretro-actionđể lãnh đạo và đội thấy rõ feedback và cải tiến đang được xử lý ra sao — biến hai buổi họp thành dữ liệu sống chứ không phải nghi thức.
Bài tập thực hành
- Thiết kế agenda Review 60 phút. Cho một sprint 2 tuần với 5 story đã Done, hãy viết một agenda Sprint Review chi tiết theo phút (mở đầu Sprint Goal, thứ tự demo theo user journey, thời gian Q&A, thu thập feedback). Chỉ rõ ai demo phần nào.
- Chạy thử một Retro trên giấy. Lấy một sprint gần nhất của bạn (hoặc giả định). Tự viết note theo mô hình Start / Stop / Continue — ít nhất 3 note mỗi cột. Sau đó gom cụm, chọn 1 chủ đề, dùng 5 Whys đào tới gốc, và viết ra đúng 1 action item có chủ + deadline.
- Chuyển feedback thành backlog. Giả sử trong Review, stakeholder yêu cầu: "Nút thanh toán nên hiển thị phí giao dịch trước khi bấm xác nhận." Hãy viết issue này trong Jira: đặt tiêu đề, mô tả, gắn label phù hợp, ước lượng độ ưu tiên và giải thích tại sao.
- So sánh và phản biện. Viết một đoạn ngắn (150–200 từ) giải thích cho một PM mới vào nghề: vì sao không nên gộp Review và Retro thành một buổi họp duy nhất để "tiết kiệm thời gian".
Tóm tắt
Sprint Review và Retrospective là hai sự kiện khép lại chu trình sprint, nhưng phục vụ hai mục đích khác hẳn nhau. Sprint Review hướng ra ngoài — demo phần mềm chạy thật (không slide) cho stakeholder vào cuối sprint trong 60–90 phút, để thu thập feedback về sản phẩm và điều chỉnh backlog. Retrospective hướng vào trong — chỉ đội tham dự, nhìn lại cách làm việc và chốt 1–3 action item cải tiến có chủ, có deadline, đưa thẳng vào Jira.
Ba nguyên tắc cần khắc cốt: (1) Review lấy demo làm trung tâm, đừng biến thành buổi báo cáo số liệu; (2) Retro là để chữa quy trình, không đổ lỗi con người — giữ nó là không gian an toàn nội bộ; (3) mọi feedback và action item phải trở thành issue thật trong Jira, để dữ liệu không bị lãng phí và vòng lặp cải tiến thực sự vận hành. Làm đúng hai buổi này, sprint của bạn không chỉ "xong việc" mà còn tốt lên qua từng vòng lặp.