Sprint Review
Buổi cuối sprint, nơi Scrum Team và stakeholder cùng xem Increment thật rồi bàn xem nên điều chỉnh Product Backlog thế nào. Timebox tối đa 4 giờ cho sprint một tháng.
Định nghĩa
Đã bao nhiêu lần bạn ngồi trong một buổi demo mà người dùng thật không hề chạm tay vào bàn phím? Sprint Review sinh ra để chặn đúng chuyện đó: cuối sprint, Scrum Team mở Increment cho stakeholder dùng thử, nghe phản hồi, rồi cùng bàn xem Product Backlog nên đổi gì. Demo chiếm phần lớn thời lượng, nhưng giá trị nằm ở đoạn sau khi demo xong.
Scrum Guide gọi đây là buổi làm việc, chứ không phải buổi trình diễn. Có nghĩa là stakeholder phải được tự tay chạm vào sản phẩm, đừng để họ ngồi xem người khác bấm.
Sprint Review là chỗ Product Backlog bị thay đổi bởi thực tế. Nếu backlog ra khỏi buổi họp y hệt lúc vào, buổi đó chưa xong việc.
Timebox và thành phần
| Độ dài sprint | Timebox tối đa |
|---|---|
| 4 tuần | 4 giờ |
| 2 tuần | 2 giờ |
| 1 tuần | 1 giờ |
Thành phần: cả Scrum Team, cộng với stakeholder do PO mời. Ở dự án ngân hàng hoặc ERP nội bộ, danh sách này thường gồm chủ sở hữu nghiệp vụ, một vài người dùng cuối thật sự, đôi khi có cả bên vận hành và bảo mật. Người dùng cuối là thành phần hay bị quên nhất, và cũng là người cho phản hồi đáng tiền nhất.
Chạy buổi này thế nào
- PO nói ngắn gọn item nào đã Done, item nào chưa. Chưa Done thì không demo. Đây là chỗ Definition of Done phát huy tác dụng.
- Team demo trên môi trường thật, dữ liệu giống thật.
- Người dùng tự thao tác vài phút. Đừng chỉ nói, hãy đưa chuột cho họ.
- PO cập nhật tình hình sản phẩm: ngân sách, thời hạn, thị trường, những thứ đã đổi.
- Cả nhóm bàn tiếp theo nên làm gì, PO ghi nhận và chỉnh Product Backlog.
So sánh Sprint Review với UAT
Hai thứ này bị gộp làm một ở rất nhiều dự án Việt Nam, đặc biệt là các dự án có hợp đồng nghiệm thu theo giai đoạn.
| Tiêu chí | Sprint Review | User Acceptance Testing |
|---|---|---|
| Mục đích | Lấy phản hồi, chỉnh backlog | Xác nhận hệ thống đủ điều kiện đưa vào dùng |
| Tính chất | Bàn bạc, khám phá | Kiểm thử theo kịch bản, có kết quả đạt hoặc trượt |
| Đầu ra | Product Backlog được cập nhật | Biên bản nghiệm thu, danh sách lỗi |
| Nhịp | Mỗi sprint | Theo mốc release hoặc theo hợp đồng |
| Ai chủ trì | Scrum Team | Bên nghiệp vụ hoặc bên mua |
Gộp hai buổi lại thì cái mất là sự thoải mái. Khi mỗi buổi review đều đi kèm chữ ký nghiệm thu, team sẽ chỉ dám demo thứ đã chắc chắn hoàn hảo, và stakeholder cũng ngại nói ý kiến vì sợ bị hiểu là không chấp nhận.
Ví dụ thực tế
Sprint Review lần thứ tư của dự án hệ thống chấm công cho một nhà máy 1.200 công nhân. Team demo màn hình duyệt đơn xin nghỉ, mọi thứ chạy mượt trên màn hình laptop nối máy chiếu.
Một tổ trưởng dự họp mượn điện thoại thử. Màn hình vỡ bố cục, nút Duyệt nằm khuất dưới bàn phím ảo. Anh này nói một câu đáng giá cả sprint: tổ trưởng ở xưởng không ai mở máy tính, tất cả duyệt đơn bằng điện thoại trong giờ giải lao 15 phút.
Kết quả là PO thêm ngay hai item vào đầu backlog và hạ ưu tiên một tính năng báo cáo vốn được xếp trước đó. Không có buổi review với người dùng thật, chuyện này chỉ lộ ra sau khi go-live.
Lỗi hay gặp
Kiểu hỏng hay gặp nhất là demo bằng slide: chiếu ảnh chụp màn hình với gạch đầu dòng thay vì mở hệ thống lên. Gần như lần nào cũng vậy, đằng sau nó là một item chưa thật sự Done.
Mấy kiểu còn lại:
- Demo trên máy local của dev. Chạy ở đó thì được, chỗ khác chưa chắc — tối thiểu phải là staging.
- Chỉ mời quản lý cấp trên. Phản hồi thu về sẽ toàn chuyện màu sắc và bố cục.
- Không ai ghi nhận ý kiến. Stakeholder nói xong rồi thôi, sprint sau vẫn thế, tới lần thứ ba họ không dự nữa.
- Dữ liệu demo đẹp bất thường: khách hàng tên "Nguyễn Văn A", số tiền 100.000 đồng tròn trịa. Dữ liệu gần giống thật thì lỗi mới chịu lộ ra.
Trước buổi review, dành 30 phút chạy thử toàn bộ kịch bản demo trên đúng môi trường sẽ dùng. Ba mươi phút đó cứu bạn khỏi cảnh loay hoay trước mặt hai mươi người.
