Sprint Review

Nhiều nhóm sai lầm khi nghĩ đây là buổi nghiệm thu (UAT - User Acceptance Testing). Thực tế, Sprint Review tập trung vào:

Minh bạch hóa: Cho mọi người thấy "Product Increment" (phần tăng trưởng sản phẩm) đã hoàn thành.
Thu thập phản hồi: Lắng nghe khách hàng để biết tính năng đó có thực sự giải quyết được vấn đề của họ không.
Cập nhật Product Backlog: Dựa trên những gì đã làm, chúng ta sẽ làm gì tiếp theo? có yêu cầu gì thêm không?

Chỉ Demo những gì đã "Done": Tuyệt đối không demo những thứ đang làm dở hoặc còn lỗi nghiêm trọng theo Definition of Done (DoD).
Kịch bản (Script): Đừng demo theo kiểu "Click bừa". Hãy chuẩn bị một câu chuyện (user story) đi từ đầu đến cuối luồng nghiệp vụ của người dùng.
Kiểm tra môi trường: Đảm bảo mạng, dữ liệu mẫu và thiết bị trình chiếu hoạt động trơn tru.

Product Owner (PO) tóm tắt mục tiêu của Sprint vừa qua (Sprint Goal).
Scrum Master thông báo những gì nhóm đã đạt được và những gì chưa hoàn thành (nếu có).

Kể một câu chuyện: Thay vì nói "Tôi đã code xong nút A", hãy nói "Khi người dùng muốn mua hàng nhanh, họ sẽ nhấn nút A này để...".
Tập trung vào giá trị: Nhấn mạnh tính năng này giúp ích gì cho kinh doanh hoặc trải nghiệm người dùng.
Khuyến khích tương tác: Cho phép Stakeholders đặt câu hỏi ngay tại chỗ hoặc ghi chú lại.

Đây là phần quan trọng nhất. Hãy đặt các câu hỏi mở như: "Tính năng này có giống như anh/chị kỳ vọng không?" hoặc "Có điểm nào chúng tôi nên cải thiện để người dùng thấy dễ dùng hơn không?".

Nên:
- Mời đúng người: người thực sự sử dụng hoặc quyết định sản phẩm
- Timebox: 60 - 90 phút
  - 5 phút: Scrum Master nhắc lại mục tiêu Sprint (Sprint Goal) và giới thiệu thành phần tham dự
  - 10 phút: Product Owner (PO) báo cáo các hạng mục đã "Done" và các hạng mục chưa hoàn thành (dựa trên DoD).
  - 30 - 45 phút: Nhóm Phát triển demo các tính năng mới theo kịch bản trải nghiệm người dùng (User Journey)
  - 15 - 20 phút: Tất cả thành viên: Lắng nghe ý kiến từ Stakeholders. Đặt câu hỏi về giá trị sản phẩm
- Ghi lại phản hồi (đại diện 1 người ghi lại phản hồi của khách hàng)
Không nên:
- Bàn chi tiết về kĩ thuật (code, database) mà tập trung vào tính năng
- Đỗ lỗi: Nếu 1 tính năng nào đó chưa xong, hãy giải thích ngắn gọn và tập trung vào giải pháp
- Biến thành buổi tranh luận: Nếu có vấn đề phức tạp, hãy hẹn một buổi họp riêng.

Để buổi Demo không gặp sự cố, hãy rà soát theo danh sách này:

a. Trước buổi Review (Chuẩn bị)

[ ] Xác nhận danh sách "Done": Chỉ Demo những hạng mục đáp ứng 100% Definition of Done.
[ ] Môi trường Demo (Staging/Demo Environment):
- [ ] Dữ liệu mẫu (Sample data) đã được đổ vào, trông thực tế và sạch sẽ.
- [ ] Kiểm tra kết nối mạng, máy chiếu, hoặc đường link họp online.
- [ ] Tài khoản test không chứa thông tin nhạy cảm.
[ ] Kịch bản Demo: Phân công ai nói phần nào, thứ tự tính năng nào trước/sau để tạo thành một mạch truyện hoàn chỉnh.
[ ] Gửi lời mời: Đảm bảo các Stakeholders quan trọng đã nhận được lịch họp ít nhất 2 ngày trước đó.

b. Trong buổi Review (Thực hiện)

[ ] Ghi chép (Note-taking): Cử một người (không phải người đang thuyết trình) ghi lại mọi phản hồi, góp ý của khách hàng.
[ ] Tập trung vào "Tại sao": Đừng chỉ nói "Chúng tôi làm xong tính năng X", hãy nói "Tính năng X giúp khách hàng giải quyết được vấn đề Y".
[ ] Kiểm soát thời gian: Đảm bảo không sa đà quá sâu vào các chi tiết kỹ thuật hoặc tranh luận quá dài về một lỗi nhỏ.
[ ] Khơi gợi phản hồi: Nếu Stakeholders im lặng, hãy chủ động hỏi: "Anh/chị thấy tính năng này có giúp quy trình làm việc nhanh hơn không?".

c. Sau buổi Review (Theo dõi)

[ ] Cập nhật Product Backlog: Đưa các ý tưởng mới hoặc yêu cầu thay đổi (Change requests) vào Backlog để ưu tiên cho Sprint tới.
[ ] Gửi Summary: Gửi email tóm tắt các tính năng đã hoàn thành và các quyết định quan trọng cho những người vắng mặt.
[ ] Ăn mừng: Nếu Sprint thành công, hãy dành một lời khen ngợi cho cả đội trước khi bước vào buổi Sprint Retrospective.

Tham khảo:

Google Sites

Report abuse