Mở đầu — vì sao bài này quan trọng
Sprint Review (hay quen gọi là "demo") là sự kiện duy nhất trong Scrum mà toàn bộ stakeholder, người dùng và team ngồi chung một bàn để cùng nhìn vào sản phẩm thật. Nó đáng giá vàng. Vậy mà ở rất nhiều công ty Việt Nam, demo bị biến thành một buổi "trình diễn slide" tẻ nhạt: PO bật PowerPoint, đọc lại danh sách user story đã làm, rồi hỏi "Anh chị có ý kiến gì không ạ?" — và đáp lại là sự im lặng ngượng ngùng. Hết. Một cơ hội phản hồi quý giá trôi qua trong vô vị.
Vấn đề nằm ở chỗ: nhiều Scrum Master nghĩ demo chỉ có một cách làm duy nhất. Thực ra, định dạng (format) của buổi demo phải thay đổi theo loại sản phẩm, loại stakeholder và mục tiêu của Sprint đó. Demo một tính năng giao diện cho khách hàng cuối khác hoàn toàn demo một API backend cho team kỹ thuật khác; demo cho ban giám đốc lần đầu thấy sản phẩm khác hẳn demo định kỳ cho nhóm vận hành đã quá quen thuộc.
Bài này là một phần trong "hộp công cụ" của bạn — chuyên về các biến thể định dạng demo. Chúng ta sẽ không bàn về cách viết action item hay cách đo sức khỏe team (đó là việc của các bài khác). Ở đây, mục tiêu duy nhất: giúp bạn có sẵn 5-6 "khuôn" demo để chọn đúng khuôn cho đúng tình huống, biến Sprint Review từ thủ tục thành đòn bẩy phản hồi thật sự.
Khái niệm cốt lõi
Trước hết phải nhắc lại một nguyên tắc nền: demo là nơi để kiểm tra sản phẩm Increment trên dữ liệu/hành vi thật, không phải nơi báo cáo tiến độ. Slide báo cáo là tín hiệu xấu. Nguyên tắc vàng: "Show, don't tell" — cho thấy phần mềm chạy thật, đừng kể về nó.
Trong khuôn khổ đó, có nhiều cách tổ chức. Dưới đây là các biến thể định dạng bạn nên nắm.
1. Standard demo (demo chuẩn theo hạng mục)
Đây là khuôn mặc định, phù hợp đa số Sprint thông thường.
- PO mở đầu bằng việc nhắc lại Sprint Goal, đặt bối cảnh "Sprint này chúng ta hướng tới điều gì".
- Developer (chính người làm tính năng đó) trực tiếp thao tác trên sản phẩm, đi qua từng hạng mục đã hoàn thành.
- Stakeholder quan sát, đặt câu hỏi và đưa phản hồi ngay tại chỗ.
- Thời lượng tham khảo: 15-30 phút cho 1-2 hạng mục chính; với Sprint 2 tuần, tổng buổi review thường 45-60 phút.
2. Use-case / Scenario demo (demo theo kịch bản người dùng)
Thay vì đi theo danh sách story rời rạc, bạn kể một câu chuyện liền mạch của một người dùng thật. Ví dụ: "Chị Lan, một khách hàng mua mỹ phẩm, mở app lúc 9 giờ tối, tìm son, thêm vào giỏ, áp mã giảm giá, rồi thanh toán". Cả buổi demo đi theo hành trình đó, và các tính năng làm trong Sprint được "nhúng" tự nhiên vào câu chuyện.
Format này mạnh ở chỗ: stakeholder phi kỹ thuật hiểu ngay giá trị, vì họ thấy bối cảnh sử dụng chứ không thấy "một danh sách checkbox đã tick". Đây là lựa chọn tuyệt vời khi demo cho khách hàng, marketing, hoặc lãnh đạo.
3. Hands-on / "Try it yourself" demo (để stakeholder tự dùng)
Thay vì team thao tác, bạn đẩy con chuột (hoặc gửi link môi trường staging) cho chính stakeholder. Họ tự bấm, tự trải nghiệm. Phản hồi thu được sẽ chân thực gấp nhiều lần vì bạn quan sát được chỗ họ lúng túng, chỗ họ bấm nhầm.
Phù hợp khi sản phẩm đã đủ ổn định để người ngoài chạm vào, và khi bạn cần phản hồi về tính dễ dùng (usability).
4. Demo cho sản phẩm "vô hình" (backend, API, data)
Không phải sản phẩm nào cũng có giao diện đẹp để khoe. Nếu Sprint chỉ làm API, batch job, hay pipeline dữ liệu thì sao? Bạn vẫn phải "show, don't tell", nhưng bằng công cụ khác: gọi API live qua Postman và cho thấy response thật; chạy một query và cho thấy số liệu thay đổi trên dashboard; bấm một nút và cho thấy log/thông báo chứng minh job đã chạy. Mẹo: luôn neo phần kỹ thuật vào tác động nghiệp vụ — "nhờ API này, thời gian tải trang giảm từ 4 giây xuống 1,2 giây".
5. Multi-team / Showcase demo (nhiều team chung sản phẩm)
Khi nhiều Scrum team cùng làm một sản phẩm lớn (mô hình scaled), bạn cần một buổi "Sprint Review chung". Mỗi team có một "gian hàng" (Bazaar / Science Fair format): stakeholder đi vòng quanh, ghé từng gian, xem trực tiếp. Cách này tránh được buổi review dài 3 tiếng nhàm chán và cho phép phản hồi tập trung theo nhóm quan tâm.
Tiêu chí chọn format
Bạn chọn dựa trên ba câu hỏi: (1) Ai là khán giả? kỹ thuật hay nghiệp vụ; (2) Sản phẩm có giao diện không? có UI hay vô hình; (3) Mục tiêu phản hồi là gì? xác nhận giá trị, kiểm tra usability, hay ra quyết định backlog.
Tình huống thực tế
Ví dụ 1 — Tiki: từ demo slide sang use-case demo
Một squad thuộc mảng Seller Center của một sàn TMĐT lớn (tạm gọi bối cảnh kiểu Tiki) làm tính năng "đăng sản phẩm hàng loạt bằng file Excel" cho người bán. Suốt 4 Sprint đầu, demo của họ là PO bật slide liệt kê: "Sprint này hoàn thành: upload file, validate dữ liệu, hiển thị lỗi". Stakeholder là trưởng phòng vận hành seller gật gù rồi... không có phản hồi gì đáng giá.
Đến Sprint 5, Scrum Master đổi sang use-case demo. Họ dựng một kịch bản: "Anh Tuấn bán giày, có 200 sản phẩm trong file Excel, trong đó 12 dòng sai định dạng giá". Dev mở đúng file mẫu đó, upload thật, hệ thống bắt 12 lỗi và hiện bảng báo lỗi rõ ràng. Ngay lập tức trưởng phòng vận hành reo lên: "Khoan, seller của mình toàn copy giá từ web khác nên hay dính ký tự lạ — hệ thống có tự xóa ký tự lạ giúp không?". Một phản hồi cực kỳ giá trị xuất hiện, dẫn tới một story mới được thêm vào backlog ngay buổi đó.
Bài học: cùng một sản phẩm, đổi format từ "liệt kê" sang "kịch bản người dùng thật" đã mở khóa được phản hồi mà 4 Sprint trước không có. Bối cảnh thật kích hoạt trí nhớ và kinh nghiệm của stakeholder.
Ví dụ 2 — Ngân hàng số: demo sản phẩm vô hình
Một team backend tại một ngân hàng số ở TP.HCM dành nguyên Sprint để xây "service tính điểm tín dụng nội bộ" — hoàn toàn không có UI. Scrum Master mới vào nghề định bỏ qua demo vì "có gì đâu mà show". May là họ kịp dừng lại và thiết kế một demo cho sản phẩm vô hình.
Họ chuẩn bị 3 hồ sơ khách hàng giả lập: một người thu nhập cao nợ ít, một người thu nhập trung bình, một người có lịch sử trả chậm. Trong buổi review, dev gọi API qua Postman với từng hồ sơ, màn hình hiện điểm số trả về: 780, 620, 410. Rồi họ chiếu lên dashboard cho thấy thời gian xử lý mỗi yêu cầu chỉ 180ms. Trưởng phòng rủi ro tín dụng — vốn nghĩ buổi này sẽ "toàn thuật ngữ kỹ thuật" — lập tức hỏi: "Tại sao người trả chậm chỉ còn 410 mà không phải thấp hơn? Ngưỡng từ chối của mình là 400 đấy". Một cuộc thảo luận chỉnh trọng số mô hình diễn ra ngay.
Bài học: sản phẩm "vô hình" vẫn demo được, miễn là bạn dùng dữ liệu thật và neo vào quyết định nghiệp vụ. Đừng bao giờ bỏ demo chỉ vì không có giao diện.
Ví dụ 3 — Startup logistics: hands-on demo lật ngược giả định
Một startup giao hàng tại Hà Nội (khoảng 40 người, một sản phẩm app tài xế) làm tính năng "gợi ý lộ trình tối ưu". Team rất tự tin, demo chuẩn mượt mà, ai cũng vỗ tay. Nhưng Scrum Master quyết thử hands-on demo: đưa điện thoại cho một bác tài xế thật được mời tới dự review, nhờ bác tự dùng.
Kết quả gây sốc: bác tài loay hoay gần một phút mới tìm thấy nút "Xem lộ trình" vì nó nằm chìm trong menu, và bác phàn nàn chữ quá nhỏ khi đeo găng tay lái xe. Tính năng "tối ưu lộ trình" thì hay, nhưng trải nghiệm thật thì vướng. Hai vấn đề usability này không bao giờ lộ ra nếu chỉ để dev demo.
Bài học: khi bạn cần biết sản phẩm có thật sự dễ dùng không, hãy để chính người dùng thật chạm vào. Hands-on demo là tấm gương trung thực nhất.
Hướng dẫn từng bước
Dưới đây là quy trình chuẩn bị và chạy một buổi demo theo đúng format đã chọn.
- Trước Sprint Review vài ngày — chọn format. Hỏi ba câu: khán giả là ai, sản phẩm có UI không, mục tiêu phản hồi là gì. Từ đó chốt một (hoặc kết hợp vài) format ở trên. Đừng mặc định luôn dùng standard demo.
- Xác định ai demo phần nào. Lập danh sách hạng mục sẽ trình bày và gán cho chính dev đã làm. PO phụ trách mở đầu (nhắc Sprint Goal) và điều phối phản hồi. Tránh để một người ôm hết.
- Chuẩn bị dữ liệu demo thật. Đây là khâu hay bị bỏ. Tạo sẵn tài khoản mẫu, file mẫu, hồ sơ giả lập có ý nghĩa (như ví dụ ngân hàng). Dữ liệu "Test 123", "aaa", "xxx" làm buổi demo trông nghiệp dư và che mất giá trị thật.
- Chạy thử (dry run) một lần. Ít nhất chạy thử kịch bản 10-15 phút trước buổi chính thức, trên đúng môi trường sẽ demo. Demo "chết" giữa chừng vì môi trường staging sập là ác mộng kinh điển.
- Mở đầu bằng bối cảnh, không bằng danh sách. Câu mở đầu nên là Sprint Goal và "vì sao stakeholder nên quan tâm", không phải "hôm nay chúng ta sẽ đi qua 7 story".
- Demo — và chủ động kéo phản hồi. Sau mỗi phần, đừng hỏi câu chung chung "có ý kiến gì không". Hãy hỏi cụ thể: "Với cách hiển thị lỗi thế này, đội vận hành của anh có dùng được luôn không?". Câu hỏi cụ thể mới ra phản hồi cụ thể.
- Ghi nhận phản hồi để chuyển vào backlog sau. Trong buổi review, chỉ ghi lại; việc xử lý, sắp xếp lại backlog là bước tiếp theo do PO chủ trì. Giữ buổi demo tập trung vào sản phẩm và đối thoại.
Lỗi thường gặp & mẹo
Lỗi 1 — Demo bằng slide thay vì sản phẩm. Đây là lỗi số một. Nếu thấy mình đang làm PowerPoint cho buổi review, hãy dừng lại. Show, don't tell.
Lỗi 2 — Dùng một format cho mọi tình huống. Standard demo không sai, nhưng dùng nó cho khách hàng cuối hay cho sản phẩm backend thì lãng phí. Hãy linh hoạt chọn khuôn.
Lỗi 3 — Dữ liệu rác. "Nguyễn Văn Test", giá "999999", ảnh placeholder xám. Stakeholder không hình dung được giá trị thật. Mẹo: dùng dữ liệu phản ánh đúng nghiệp vụ, càng giống thật càng tốt.
Lỗi 4 — Không có dry run, demo sập giữa chừng. Mạng yếu, staging chưa deploy, tài khoản mẫu bị xóa. Luôn chạy thử trước.
Lỗi 5 — PO độc thoại, dev im lặng. Buổi demo thành "one-man show" của PO. Mẹo: phân vai trước, để dev tự hào khoe phần của mình.
Lỗi 6 — Demo cả những thứ chưa "Done". Chỉ demo hạng mục đã đạt Definition of Done. Demo phần dang dở tạo kỳ vọng sai và phản hồi lệch.
Lỗi 7 — Hỏi phản hồi chung chung. "Anh chị thấy sao?" thường nhận lại im lặng. Mẹo: chuẩn bị sẵn 2-3 câu hỏi cụ thể, có định hướng, cho mỗi tính năng.
Mẹo cho team phân tán: với team remote, chỉ một người chia sẻ màn hình, người demo phóng to con trỏ, và chuẩn bị sẵn link để stakeholder tự thử nếu làm hands-on. (Chi tiết công cụ cho daily/retro phân tán thuộc các bài khác, ở đây chỉ lưu ý phần demo.)
Bài tập thực hành
- Lập "thực đơn format" của riêng bạn. Viết ra một bảng nhỏ với 4 cột: tên format, khán giả phù hợp, loại sản phẩm phù hợp, một câu hỏi mở đầu mẫu. Điền tối thiểu 4 format từ bài này. Dán bảng này cạnh bàn làm việc để dùng trước mỗi Sprint Review.
- Phân tích buổi demo gần nhất của team bạn. Trả lời: format vừa dùng là gì? Có đúng với khán giả và loại sản phẩm không? Nếu được làm lại, bạn sẽ đổi sang format nào và vì sao?
- Thiết kế một use-case demo. Lấy 2-3 hạng mục dự kiến hoàn thành trong Sprint tới, viết ra một kịch bản người dùng liền mạch (đặt tên nhân vật, bối cảnh, mục tiêu) bao trùm cả 2-3 hạng mục đó. So sánh cảm giác với cách liệt kê từng story rời rạc.
- Chuẩn bị dữ liệu demo thật. Với một tính năng cụ thể, tạo trước 3 bộ dữ liệu mẫu có ý nghĩa nghiệp vụ (ví dụ: trường hợp bình thường, trường hợp biên, trường hợp lỗi). Ghi lại bạn dự đoán stakeholder sẽ phản ứng thế nào với từng bộ.
- Soạn 3 câu hỏi kéo phản hồi. Cho buổi review sắp tới, viết 3 câu hỏi cụ thể, có định hướng để thay thế câu "Anh chị có ý kiến gì không". Thử dùng và ghi lại xem chất lượng phản hồi có khác đi không.
Tóm tắt
Sprint Review không có một khuôn cố định, và đó chính là sức mạnh nếu bạn biết tận dụng. Hãy nhớ những điểm cốt lõi:
- Demo là để kiểm tra sản phẩm thật, không phải báo cáo tiến độ. Show, don't tell — slide là tín hiệu xấu.
- Có nhiều biến thể format: standard (theo hạng mục), use-case (theo kịch bản người dùng), hands-on (stakeholder tự dùng), demo cho sản phẩm vô hình (API/backend qua dữ liệu thật), và showcase/bazaar cho nhiều team.
- Chọn format theo ba câu hỏi: ai là khán giả, sản phẩm có UI không, mục tiêu phản hồi là gì.
- Chuẩn bị quyết định chất lượng: dữ liệu thật, dry run, phân vai cho dev demo, và câu hỏi kéo phản hồi cụ thể.
- Tránh các bẫy kinh điển: demo bằng slide, dữ liệu rác, demo phần chưa Done, và PO độc thoại.